[VXAce] Sprawdzenie możliwości ruchu?

[Ayene]

Odsyłam http://www.ultimateam.pl/files/Pathfind_Ace.rar
Wykorzystałam skrypt Jeta (bazujący na A*).

[Yoroiookami]

Działa świetnie. O wiele lepiej, niż sobie wyobrażałem. Dziękuję ci Ayun.

[X-Tech]

Czasochłonne ? Dla mnie to jakieś 30 sekund - 1 minuta XD
2 zestawy x i y porównywane o czas powyżej gęstości kroków typa (lub co kazdy krok sprawdzanie uruchamiane switceh w zasadach ruszania typem)
Jeśli po czasie pary koordynat są zgodne to znak, że blokowanie
Koniec bajki.



Jeśli chodzi o szukanie drogi możesz skorzystać z gotowca tym razem polecam jak napisała Ayene na szukanie drogi z a-b. Ten gotowiec rozszerza opcje ruchu zdarzeń o znalezienie ścieżki z a-b bez względu na przeszkody. Tego gotowca polecam, ale on będzie brał sporo cpu więc około 1 max na raz użycie w wypadkach kiedy cel jest blisko najlepiej polecam.

Ten gotowiec jest dobry, ale on będzie obrabiał setki zmiennnych w tle aby wyliczyć koordynaty, ale nic lepszego na perfekcyjne znajdywanie z a-b drogi nie ma.

Można napisać coś podobnego samemu na zdarzeniach, ale nawet w obrębie paru pól będzie to wymagało kilkudziesięciu zmiennych na większe obszary setki zmiennych.
Jeśli nie chodzi o szukanie ścieżki tylko samo blokowanie to co ci wymysliłem lepsze.
5 zmiennych i koniec zamiast chorych skryptow ruby na pierdyliardl inijek


W każdym razie szukanie drogi z A-B metoda A* to jeden z przykladow dla ktorych powstalo rgss i ruby w rmie. Popieram

[Ayene]

Wyszukiwanie można zoptymalizować, aby nowe koordynaty ustalane były tylko w przypadku ruchu celu, itd. Domyślny skrypt na zbliżanie się do gracza jest uwarunkowany tym, jak blisko dane zdarzenie się znajduje. On również jest na bieżąco aktualizowany, więc i "path_find" nie powoduje nagłego wzrostu złożoności obliczeniowej.