Movespeed 2DA randomization results in softlocks when affecting story-critical custcene characters

[TheBeardOfTruth]

For example what I ran into on my current seed:

The unavoidable encounter with Commander Grann (Sith Embassy/Manaan), his movement speed is 0 due to movement speed rando and he will therefore never successfully leave the elevator, this softlocks the cutscene (and by extension the rest of the game since this is a mandatory part of progression).

There are a few obvious solutions, as far as I see it anyway. A few of the simpler solutions:

1. Disallow a movespeed of 0 entirely
2. Modify the cutscenes so that if an NPC takes too long to reach their trigger we just proceed anyway or teleport them to the trigger
3. Flag certain NPCs as disallowing a movespeed of 0 (and probably flag things like turrets to only allow a movespeed of 0)
4. Allow the user to select a movespeed range and warn them if 0 is an option.

There are other solutions as well, but those are the obvious and trivial ones.

Spoiler log

[LaneDibello]

Yeah we've encountered this before... Usually we've advised others to avoid movement speed randomization for this reason.

Your first solution is the simplest patch by far, and would be as simple as adding a special case for this 2DA that omits the stationary movement speed.

Modifying cut scenes like this wouldn't be feasible programmatically, though I do know how I could do it by hand. However, such a patch would be large and time consuming.

Similarly, preventing NPCs from gaining this adjusted movement speed would not only require us to crawl every single NPC, in every RIM and Template (runtime consuming) but also to keep track of what the adjusted movement speeds map to.

The movespeed range selection isn't actually a bad idea. It could be quite fun to let the user just set some bounds and we'll randomly grab numbers between there. The only draw back being is this would be more than just a special case for this particular randomization category, and would instead warrant an additional feature (not out of the question, especially in our future plans for 2DAs).

Unfortunately, neither Glasnonck, nor myself are actively maintaining this project. Though, we do plan to return to it at some point. Feel free to branch and mess with it yourself in the meantime. And I'll be happy to answer any questions in the interim.

[TheBeardOfTruth]

Yeah, in my case I unsoftlocked it by manually editing the 2da and setting any 0 movespeed to a nonzero value.

Similarly, preventing NPCs from gaining this adjusted movement speed would not only require us to crawl every single NPC, in every RIM and Template (runtime consuming) but also to keep track of what the adjusted movement speeds map to.

Arguably this should only need to be done once, unless the rando also supports any arbitrary set of mods. At least for vanilla it'd be simple enough to just hardcode the relevant NPCs, no?

Admittedly that's an at best uneducated guess, I'm somewhat unfamiliar with the aurora toolset (in so far that I've never dealt with it programmatically, I have made modules for NWN but that's at best mildly relevant)

Unfortunately, neither Glasnonck, nor myself are actively maintaining this project. Though, we do plan to return to it at some point. Feel free to branch and mess with it yourself in the meantime. And I'll be happy to answer any questions in the interim.

I may, though I'm not particularly experienced with C# so it'd probably be faster for me to just reimplement it in C or C++ (especially since the WPF GUI doesn't work under wine or dotnet core (or mono) outside of windows due to licensing issues and that seems to be the direction this repo is going).

Neither here nor there, but it does vaguely relate to movespeed -- character movespeed will drop to a crawl after going through a loadzone. I'm unsure if this is related to 2DA randomization since I'd have to do some probing, but it's worth noting anyway. It's also probably known, the fix is easy enough (just swap armour on/off and you're good 'til the next area load).