Pomysły na blokadę poruszania się algorytmem A* przez tego typu miejsca? Ze względu na grafikę nie może być tam przejścia - na pewno milion osób już o to pytało
Mega zwiększenie domyślnej wagi w takich "trójkach" pól nie ratuje dupki. Brak ukośnego ruchu także :P
@mojnowynick: właśnie brudzi to kod strasznie, bo np. (pic), więc szukam czegoś może ciekawszego. Ale napisałeś drugi komentarz: Używam mojej starej (xD) implementacji astara, później będą jakieś pola spowalniające itp, więc warunków już jest od cholery i staram się ominąć ile mogę - 8 warunków sprawdzanych za każdym przelotem pętli to niezbyt fajne rozwiązanie
Mega zwiększenie domyślnej wagi w takich "trójkach" pól nie ratuje dupki.
@Hauleth: to mnie także nie urządza, bo niestety nie mam jakiegoś atrybutu pola typu passable, a typów pól będzie sporo. Nie zawierają jednak tego cholernego passable xD Więc musiałbym robić ify typu if x + 1 = zielone and if y - 1 = niebieskie then idź w innym kierunku if x + 1 = zielone and if y
@Noct: zwyczajnie "pozwól wejść" na to pole, ale zaznacz, że koszt wejścia na nie to nieskończoność. Nie w polu poprzednim, a na zabronionym przypisz taki koszt.
@Hauleth: żeby przypisać coś takiego muszę przelecieć całą tablicę i wyszukać takie pola, to jest mega zajebujące, albo sprawdzać w przypadku wystąpięnia, ale to jest brudne ( ͡°ʖ̯͡°) Czy ja marudzę
@Noct: Usunięcie ruchów ukośnych powinno rozwożąc twój problem i jednocześnie zmniejszyć ilość warunków. Jeżeli zależy ci na animacji przechodzenia po ukosie czy cos takiego to potem możesz w już finalnie znalezionej ścieżce przetłumaczyć ruchy typu 'w prawo' -> 'w gore' na jeden ruch po ukosie itd.
@kywmn: działa. Zdarza się temu robić kilka dziwnych rzeczy i jakby przeskakiwać, ale narazie nie będę tego ruszał - dodałem trigger allowDiagonals i push ( ͡°͜ʖ͡° )つ──☆*:・゚
Mega zwiększenie domyślnej wagi w takich "trójkach" pól nie ratuje dupki.
Brak ukośnego ruchu także :P
#programowanie
Komentarz usunięty przez autora
if x + 1 = czarne and if y - 1 = czarne then idź w innym kierunku
else x - 1 = czarne and if y - 1 = czarne then idź w innym kierunku
I tak dla każdej opcji związanej z ruchem ukośnym
Ale napisałeś drugi komentarz:
Używam mojej starej (xD) implementacji astara, później będą jakieś pola spowalniające itp, więc warunków już jest od cholery i staram się ominąć ile mogę - 8 warunków sprawdzanych za każdym przelotem pętli to niezbyt fajne rozwiązanie
Dlaczego nie? Przecież tu właśnie to jest problemem.
@Hauleth: to mnie także nie urządza, bo niestety nie mam jakiegoś atrybutu pola typu
passable
, a typów pól będzie sporo. Nie zawierają jednak tego cholernegopassable
xD Więc musiałbym robić ify typuif x + 1 = zielone and if y - 1 = niebieskie then idź w innym kierunku
if x + 1 = zielone and if y
Czy ja marudzę