Wpis z mikrobloga

@Noct:

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
@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
Pobierz Noct - @mojnowynick: właśnie brudzi to kod strasznie, bo np. (pic), więc szukam czego...
źródło: comment_1589059151JWEWt48Hf89jH4Of0PUEKq.jpg
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 ( ͡° ͜ʖ ͡° )*: