So, what's up with walking animations for the party? Setting always run=0 in toee.cfg will introduce walking as the default party movement, provided that numlock is also off. Numlock functions as a state toggle, but unfortunately it sticks to run after you set it once, requiring an area transition to reset to walk. Also, any action that causes a run animation will break the state on a per character basis (again, until after area transition). NPCs aren't affected by the key toggle, but they are by a run action. It also causes mouse click movement commands to change behavior. In walk mode, when issuing a click before a previous move order has finished, the previous order is carried out before the second begins. Essentially, it works like path with 2 waypoints... though you can't cancel if you happen to change your mind :bored: This all feels very much like a half developed feature that Troika decided not to implement. As it is, walking isn't terribly useful due to the snail's pace and the general wonkiness of how it behaves. I'm wondering though if anyone has experimented with it or has any insight on how it might be modified and made useful (speed and behavior changes). I can think of a number of scenarios (mostly indoors) where I'd much rather the whole party slowed the hell down... aside from sneaking. I presume a fix would lie on the dll side of things, and therefore not easy or likely, but I'm curious nonetheless.
In the meantime, if you wanted to permanently lower run speeds, there's a field for that in protos.tab. We adjusted those for some of the PC protos a while back to try to get them moving at more or less the same speed. (Halflings and gnomes doubletime, etc.)
Right, I remember that adjustment. 'Normal' is no value, correct? The thing that was bothering me was that I remembered PCs having a walk state at some point a while back... then it strangely vanished after taking a break from the game. I initially suspected some change to the mod, but I had either forgotten or never realized that numlock was an undocumented key. So setting 'always run' to 0 without that was causing only controlled NPCs to walk and not immediately respond to move clicks. Didn't figure it out until I came across some old posts from folks having a similar problem with Arcanum where walking is actually implemented, I gather. For me, walking is mostly an aesthetic thing, but it would be interesting to try to make it work tactically (out of combat). As for the different movement between races/sizes... I actually liked the greater distinction and generally solved the problem of characters arriving too early or too late by using groups. Might try fiddling with the proto values to bring that back.
--I've never posted on a forum before so not sure I'm using the quote right... I was toying around with the walk feature after reading your post and found a "work around" for the uninterruptible waypoints. Assign a hotkey to something like sneak, or search, or something like that and that will interrupt the waypoints. I actually like the waypoint behavior for scouting and that's how I got around that.
Haven't tried that, will take a look. If you toggle numlock back and forth, that still changes the behavior consistently from a routed path to instant move (even after it disables walking). I looked up the Arcanum key commands, and CTRL functions like it does there... ctrl click will issue a run move if you're in walk state. Unfortunately, that too breaks walking for whatever characters were selected. EDIT: I think the workaround you're describing is actually the result of hitting the CTRL key itself (not necessarily together with a hotkey) . Issuing CTRL click to move will also ignore any path from a previous order aside from making it a run move. Or maybe you mean something different?
No, the interrupt occurred when I pressed the hotkey. I think I tried the control key first to no effect, but not sure. I imagine the hockey's will override anything.
Ah, ok. Wasn't sure if you meant the hotkey itself or the process of assigning the hotkey (and thus hitting CTRL). Yeah, the hotkey does interrupt the move, but only for one character in a group (the leader, or whoever is closest). Everyone else keeps on their merry way. CTRL click will also interrupt (for everyone) but disables walking. I find the whole thing entirely too fiddly and broken to be of much use as is. Ideally, the walk/run state would return to however the numlock toggle is set after you issue a run move (e.g. CTRL click move, toggle NUMLCK and move, item interaction or combat). But it doesn't... it needs an area transition in order to reset. If the state could be reset without that, we'd be in business. I'm guessing there would need to be a conditional check inserted. So either that, or as Sitra Achara put it in the issue description over at Github, make the walk animation dependent on distance. I'm not sure which solution is more useful, but I guess it would come down to what's easier (or possible). In any case, it's technically interesting... even if a bit frustrating that it almost works
Search makes all selected PCs stop and look around canceling the waypoint and not ruining the state. It's what I use. Yeah it is annoying though. Especially since the animations look good. I have enough programming experience I might try to write a script to fix it, if I get the time... Which won't be soon. Personally I can't imagine why they left it unfinished. You can't tell me they counldnt have just written a quick script...
Oh, you're right... search can be a party action and they all stop and play the animation. They finished their old route on the next move though, when I tried it. And then there's the usual toee UI funkiness in play. I don't see mouse/KB UI or animation state anywhere in python, but then I'm not that familiar with the layout. I assumed all of that was compiled C++. I completely defer to those who have been at this for years, but I'm interested in the details, nonetheless. So please post whatever you learn.
