What happens is that one of the 4 ettins gets blocked by personal space of others and then decides to take a long way around the map as shown on minimap. Sometimes in the middle of that path when the previously blocking ettins are dead he decides to return back, sometimes he just comes from behind.
I fail to see how is this better behavior than the vanillaâs doing nothing and standing behind the others waiting for space to be created. This happens frequently on any area which has more than one entry point. This is also explaining what I saw in my earlier gameplay with this character when my summoned skeleton was taking a trip all around the area - I was unfortunately not able to reproduce that, I suppose it was a specific position of my character in corridor that somehow made him think he cannot fit there anymore (although he should have been) or maybe it was related to the fact that his AI chosen a target that was behind the npcs that were blocking the corridor, that would make sense.
Today I played a few hours on my PW and I stumbled upon pathfinding regression several times in that area on screenshot. But It was the same bug as in the pathfinding4 module I posted. So overall there is not that many bugs, it just plagues dozens of various tiles - basically all that have niches inside the corridor walls.
Combining twitchy pathfinding with the retarded vanilla AI (semi-retarded in the case of CPP) is bound to produce less than stellar movement choices on the part of AI controlled creatures.
Now that I have a clearer picture of what youâre describing, it sounds to me like the pathfinding algorithm needs to be choosing the shortest route from point A to point B, ignoring living objects that would obstruct the route. If such a thing is possible, it should restore the original behavior of âwaiting your turnâ rather than going halfway east around the world to get to a point 2m to the west.
This will happen with any AI though. This is fully hardcoded behavior. AI is just telling the creature (or summon) to attack target, nothing more and there is not more an AI can do there. Casters are a chapter of its own - no AI can handle spellcasting summons well - and that is also related to pathfinding, but I suppose this could be handled in NWScript. AI can tell the summon to cast a spell on target, but if that target is behind wall, then npc just gives up the spellcasting wasting full round. If the AI tries to solve this it leads to the caster NPC running into target face before casting a spell, but well as I said, this is solveable I guess. I am not aware of any custom AI solving this though, but maybe I am just clueless.
Iâm really liking the TonyK AI. It can be aggressive at times, sluggish at others but overall, it outperforms the vanilla AI - better decision targeting choice, use of abilities and spells, etc.
I was talking about the developers changing the pathfinding in the game itself to ignore âlivingâ barriers to a creatureâs pathing. In theory, the creature trying to get from point A to point B through a blocking creature will engage that creature if its an enemy or move past it if not an enemy. Or at least that behavior could be coded into the engine.
As for AI cast summons - cast at nearest location within LOS drawing a straight line from the caster to the target chosen?
Yeah absolutely. I just wanted to make it clear that NPCs running into this issue is not caused by the softcoded AI and will happen with both vanilla and custom AI like Tonyâs.
That being said, your suggestion is not perfect either. There might be a similar scenario where the path would be just 1 more tile and then I would expect the NPC to run around and flank the player from behind. I donât remember if that happened in vanilla - were they stuck when the very next tile had another entry point?, what I am sure is that the above case is new in EE.
We are talking here about corridors. If you donât control the summon manually, he will always lag behind you. If it is a corridor then you see the enemy and he can be 2 tiles behind you. When you tell the summon to attack nearest, then he will get stuck because AI will use that nearest enemy you see as intruder and wonât check LoS and he is so far behind so that there is no location in his sight where he could hit the target with AoE (and scripter doesnât have spellsâ aoe ranges to his disposal either - must have been manually inputted per each spell). Well try it under Tony K AI and tell me result how it behaves in such scenario.
The only solution to this problem is to check LoS and if the spell or special ability is chosen by AI and if the LoS is not there substitute that with ActionMoveToObject or Location and then try to stop the summon when OnPerceived is fired and then re-initiate AI. But this should all be doable, so maybe I add this to CPP AI someday.
So, the problem is that pathfinding is too good now? Thatâs certainly an unorthodox meaning of âregressionâ. Hey, I have one too!
Regression: Area loads too fast now. I put key plot information in loadscreen tips, but the areas load too fast for players to read it.
IIUC youâd have gotten the same behavior in 1.69 eventually as your CPU got more powerful, so maybe try running your server on a raspberry pi zero?
Jokes aside, I do understand how having the Ettin not do that can be desirable in some circumstances. I think something like this would be useful:
void SetPathfindingLimits(object oCreature, float fMaxPathLength = -1.0f, int nMaxTime=-1);
certainly something to consider for .36
btw, I think you might be able to get close to old behavior with NWNX by just hooking PlotPath() and related functions and reducing the nTimeSlice value until it becomes sufficiently dumb.
Yeah, improving areas loading was also something that EE messed up completely. In .34 it is actually worse than in vanilla. So .35 is just fixing a regression. But that wouldnât look as good in patch notes
And no. You call it better, I argue that being able to calculate paths like above is not making it better, but dumber.
Well I donât really care what you call it, in the end it seems you do agree that the above case is not very good.
You should try .35 in singleplayer before making these statements. It really is up to 100x faster than 1.69 in some cases (e.g. if thereâs thousands of placeables), and more than 10x faster in all cases. In multiplayer itâs slightly different due to tradeoffs, but thereâs a couple of settings you can use to make it just as fast as SP (though I wouldnât recommend it for a PW).
As for pathfinding, the goal of the pathfinding code is to find a path. It found a path. Previously it couldnât find a path. Thatâs objectively an improvement. The problem is that modules might have made implicit assumptions about CPU speeds and timings and such and were designed assuming pathfinding fails. This is kinda like those old games that tie logic to framerate and then everything happens super fast on modern PCs.
Much as I claim that a patch must have zero regressions, some things are just not reasonable to accommodate. I mean, what if someone made their scripts lag the whole module on purpose to make a fight harder - should we just say âoh, we must not make nwscript fasterâ?
I do understand wanting to make some creatures dumb at pathfinding though. An insect wouldnât know to take a 300m detour to sneak up behind you (though really, an Ettin that lives in that cave would), so it would be nice if you could limit their skill specifically without affecting everyone else. Hence the proposed function above. But I just do not accept it as a regression. Otherwise every change ever is a regression: âGame regressed because they fixed the exploit I was using!â
Alright lets put it this way. Smarter pathfinding does lead to NPCs being dumber. Maybe you can argue the case above with ettins is not that case. Fine, lets say the Ettin is just super smart and takes that long way to flank player from behind.
But the another case that happened to me with the skeleton summon is definitely NPC being dumber than in vanilla. â Skeleton was behind me, there is bombardier beetle in my vision as closes target, I tell skeleton to attack nearest. But because he is far behind me and other normal beetles see me, the fire beetles without any spellcast will (together with a model of my PC) block the corridor - and the bombardier beetle stays further inside the room as he is casting acid cone. By this time my skeleton decide to take a 15 tiles long trip to enter the room from the other side (room has two entry points) potentially even spawning more monsters (if custom spawns that reacts on summons (mine does not and vanilla either, but it is not unheard of)). That I call stupid behavior - in vanilla he would just try to squeeze through the corridor - that would fail, he would get flatfooted for few seconds and then the heartbeat script would trigger his AI and chosen new closer target and he would start fighting the fire beetles.
Would you agree about my statement in such case then?
I agree that is very unfortunate behavior. I believe AI should account for this. If thereâs missing nwscript functions that are necessary for AI to make this decision (such as e.g. one I proposed above), we should add them so that AI can be smarter.
I think we can also add a global slider for pathfinding time slice for quick and easy adjustment.
But I donât think the code changes so far are in the wrong. They did nothing but speed up existing behavior. Youâd have seen the same in 1.69 if you paid $1M for a supercomputer. Or just waited another 10 years for personal computers to become fast enough.
Pathfinding actually already tries to just move as close as possible in a fairly straightforward manner if the path is only blocked by other creatures or if moving to engage in a melee attack. Sometimes, thereâll just be other things in the way, which - partially affected by the improved performance - may cause the issue you observed. Or it may have been caused by you having a faster CPU now, who knows.
Either way, I do agree that itâs not always the ideal behaviour, but weâve actually been pretty careful not changing the core pathfinding algorithm to prevent unforeseen sideeffects, so I think that - as @clippy suggested - the best approach for changing this aspect is to open up for more customization to cater your preference rather than revising the core functionality itself.
Thatâs certainly an unorthodox meaning of âregressionâ. Hey, I have one too!