Aggro Radius rant

[SKKmods]

There is an option on AI packages called "aggro radius".

When enabled, actors running that package will go hostile on NEUTRAL actors that enter the radius.

As it is not practical to query or detect if an actor is running an aggro radius enabled package, or what quest alias a particular package originates from, their posture towards the 90% of world actors that are neutral state can not be managed.

Well, it can by checking GetCurentPackage against a list of 3,000 base game aggro packages, or forcing them into a priority 99 quest with its own stack of 4,000 packages replicating all possible source packages with aggro radius unchecked and an AV that triggers the right one, but that's insanely impractical.

To avoid aggro radius triggering, an actor/faction must be a friend or ally. Since 90% of actor:actor postures are neutral, this would involve massive faction relationship re-engineering plus the complexity managing new assistance behaviors at runtime (like raiders helping gunners).

This makes the delivery of dynamic managed experiences next to impossible. Whoever specified the aggro radius function was clearly solving a problem with an extremely limited perspective on the world state. Is a nice way of describing it.

Irritatingly the exact same "attack neutrals" effect can be achieved setting Aggression Actor Value to 2 which is simple to detect and manage dynamically. And the aggro radius does not trigger consistently either.

TL;DR AI Package Aggro Radius BAD; Aggression AV GOOD.

/rant.

[Zorkaz]

Thanks this confused me always

[niston]

Creation Engine:

 

"Do less with MORE WORK, have MORE CUT CONTENT because nothing ever gets finished on time and, as a free bonus, have MORE BUGS, because complexity always spirals out of control, due to stupid design decisions made a decade ago."

 

Recommended by 10/10 lunatic asylum operators.

[SKKmods]

OK since we may have a general dev moan session going, my other "top 3" gripes:

 

(2) MoveToNearestNavmeshLocation() which is critical for truly random point spawning does not return a result, just dumps to the debug log if no navmesh can be found. Partial workaround: spawn at Z 9999 then check if z position has dropped to navmesh.

 

(3) There is no Location.GetRefType(LocationRefType akRefType) function, so using LocationRefType in script is arse. Partial workaround: start a quest that uses a LocationRefType fill, but that only returns one result which causes base game workshops like Hangman to be linked to the wrong map marker when there are multiple results.

 

(4) Function GetInventoryItems() in F4SE should be in the base game. Working on inventory without F4SE (won't someone think of the Xboxes) is impractical.