Open Xadras opened 11 years ago
Original comment by Anon X (Bitbucket: Anonx, GitHub: Anonx):
Ich löse es mittlerweile so, dass Ich die AI aller mit Event AI gesteuerten NPCs umschreibe um diesem Übel Herr zu werden.
Alternativer Lösungsansatz: https://bitbucket.org/Caboon/playcore-official/commits/60f6a18c22272ca63e5be298d2205504f11697b7
https://bitbucket.org/Caboon/playcore-official/commits/37121f48a6600527582553939d7fb0dfd9fe67ba
Original comment by Micha2903 (Bitbucket: Micha2903, GitHub: Micha2903):
if (!m_creature->IsWithinLOSInMap(Target)) return false;
dem einfach ein else verpassen, und innerhalb dessen über die ai des mobs wieder los casten. Ich hab mir noch nix vom Code angeschaut, weil ich noch halbkrank die meiste Zeit des Tages im Bett verbringe und da nur mal nen paar Gedankenspiele gemacht habe.
Original comment by robinsch (Bitbucket: robinsch, GitHub: robinsch):
Das Problem ist einfach das du halt einen Punkt gesetzt bekommst wo der NPC hinlaufen soll, bei UNIT_STATE_CASTING läuft er natürlich nicht, da aber nach Casten eines Spells dieser State entfernt wird greif der Update der Movement Funktion.
Zu fixen ist das ganze das er diese Update funktion nur alle 100ms called, dann hat der Server genug Zeit UNIT_STATE_CASTING zu clearen und bei erneuten cast wieder zu adden.
Original comment by Areradon (Bitbucket: Areradon, GitHub: Unknown):
//Target is not within los with caster if (!m_creature->IsWithinLOSInMap(Target)) return false;
Das bei CreatureEventAI.cpp dann sollte das schonma gefixxt sein. Problem wird dann sein, sobald du sie einma LoS brichst, das sie immer versuchen werden in melee range zu kommen.
Ich bin der Meinung das eine Mob AI eig. oberste Prio hat, vorallem weils laut Corecraft Devs schnell geht. Ich könnte es mal Detailiert ins Forum schreiben.
[22:21:14] robin: Neee du kannst das einfach im chase movement handler fixen [22:21:22] robin: das hab ich auch gemacht aber halt nur für water elemental [22:21:33] robin: das hat sich zwischen den waterbolt casten auch immer bewegt
Mal so als denk ansatz
Original comment by Micha2903 (Bitbucket: Micha2903, GitHub: Micha2903):
Also die Geschichte mit dem LOS dürfte nicht all zu schwer umzusetzen sein. Schwieriger wirds aber mit den Castern die zwischen den Casts stehen bleiben sollen. Die Core müsste das ja irgendwie unterscheiden können. Derweil könnte Sie das nur anhand des Zaubers der gewirkt wird. Aber auch die können gemischt sein. Es bräuchte da also, um zuverlässig (und generisch) zu funktionieren eine neue Eintragung in der DB, die festlegt, ob ein Mob ein Range DD oder ein Melee DD ist. Abhängig davon ließe sich dann wiederum recht einfach ein entsprechendes Movement realisieren. Aber wer sollte sowas machen? Da hockste ja allein Monate dran, bis man sowas allein in der Datenbank umgesetzt hat.
Da steht meiner Meinung nach der Nutzen in keinem Verhältnis mit dem Aufwand. Denn so tragisch ist das nun auch nicht.
Was man sich aber durchaus anschaun kann ist die LoS Sache.
Allerdings wäre dafür ein ordentlich strukturierter Report wünschenswert. Der hier ist n bissi durcheinander.
Originally reported by: Areradon (Bitbucket: Areradon, GitHub: Unknown)
ein problem was vielen wahrscheinlich nicht bekannt ist, jedoch ist die Mob AI an sich relativ fehlerhaft.
Es gibt Mobs die auf Range Casten und welche die Melee angreifen. Mobs die auf Range casten sollten LoS gebrochen werden können, sobald sie aber wieder LoS sind sollten sie weiter casten und dabei stehen bleiben. Hier casten sie und laufen dann zwischenzeitlich immer ein stück näher zum gegner.
Ein Video zur Mob AI gibts von einem anderen Server, es ist aber Defenitiv auch so auf Blizzard Servern.
http://www.youtube.com/watch?v=gXn7HRgYe1c&feature=c4-overview&list=UUdmaHMrCGtvGSj3AOXmmlrw
Was hier nicht funktioniert sind: Line of Sight Pulling - 0:30 Range and Melee Switching - 1:05 Scatter and Run - 3:53 Trap and Run - 4:15
Es wird wahrscheinlich noch mehr buggen.