I took a look at AHuman issues; lack of speed on the ground, generally getting stuck a lot, getting into death-cycles with their jets, silly spin behaviors, the whole slew of things that I think most of us agree aren't right.

I really didn't think I could fix this very easily, but it turns out that the behavioral constraints in that ACrab script provided most of what was needed.

As proof that it works... here's a screen showing a Heavy Dummy from the Dummy Expansion mod just after finishing off the base in Assault:
56K-unfriendly.

I figure that's reasonable proof, we all know what a pain it is to get actors down there.

Anyhow, here's the code, with notes / caveats at the end, like the ACrab. I'm probably premature in terms of releasing this; I just thought that it was pretty cool to finally be able to move my guy around without too much weirdness, and by gum, it seems to work; hope others have good results. If you test it with a stock guy, make sure to change the height distance check, or you will not see the desired behaviors. License is CC-NC, use for whatever you want, so long as it's free. Don't worry about crediting me.


Notes and Caveats:

1. Unresolved bug: unlike ACrabs, it is quite easy to cause insta-death to oneself by colliding one's head with terrain, which happened a couple of times to me while in tunnels (poor Heavy Dummy, too tall for tunnel!). If people's results with this are as good as mine were, I suspect people will do yeehaw behavior, then be annoyed when they gib themselves. Sorry, it's a character issue; make head joints stronger maybe?

2. Unresolved bug: Just like the ACrab, wall-climbing can occur due to lift affect and sensor results. However, with tighter footprints, this happens less often and is less remarkable. And heck, we always wanted the ladders to actually be useful instead of being frustrating obstacles, right?

3. You can move pretty swiftly and the leg motions will be ragdolling in silly ways. No easy fix for that; needs engine-side fix, better constraint system.

4. You can move fairly swiftly while ducking by releasing duck and pushing forwards. I don't really regard this as a bug, more of an unintentional feature, but a really easy fix if you want duck to not allow it is:



... or for slower movement, just use a branch. Do bear in mind that speeds < 4 and accelerations < 0.5 or thereabouts probably will not work, due to friction.

5. This is even cheaper than the ACrab script. Compared to the stock script, it's practically free.

6. This script does not have any AI code; ACrabs still do things with the other script, and in general seem to behave better in combat, so I presume a lot of that is engine-side. But mining and other special behaviors are not in this code, so it will probably require a port.

7. Due to the forced rotation of the actor, it is no longer possible to induce crazy whirling motions in your characters. This isn't ideal; it removes some of the sim stuff that people think is cute. The best solution for people who care about that stuff (which I don't, frankly- gameplay is always my primary consideration) is to apply a damping rotation until rotational speeds steady, then return the Actor to its normal state. I'm not writing that but it should be a simple check of rotational speed and then applying a braking force. That would let AHumans do crazy spins if shot with something unpleasant but eventually right themselves again. Personally, I never liked that, because it almost always happened due to getting hit while using a jetpack and always felt wrong, but like I said, no biggie. This script, like the previous one, does allow for full normal simulation of impact velocities; if you get pushed, you stay pushed until your acceleration in the opposite direction and other forces cancel it out.

8. Leg motions will not conform to speeds, and sometimes one leg will flop behind the character while the other one behaves normally. There is no easy fix for that; the best that can be done is to adjust the height check and keep the character high enough that it doesn't get impacted in ways resulting in crazy behaviors. But CC characters have always faked that to some degree anyhow, and have always had issues, so I don't think anybody will care too much.

9. There are probably other problems that I didn't see because I didn't test this enough. I had an idea, made some edits and ran it and it seemed to work well enough that I thought it was worth sharing, is all. Caveat emptor.

Well, this doesn't do anything fancy; it doesn't handle any actual AI behaviors, it's strictly concerned with making movement less funky.

Anyhow, found a bug in the released version (ironically added while cleaning it up for release), fixed it. I'll edit the first post.



Oh, and I'll try to get a version for regular-sized AHumans done, but not tonight.

Maybe, instead of trying lua fixes, which are perfectly valid and all that thing, you could try to understand and explain walkpaths.

I have the wierd feeling that that part works almost by chance and magic, since there aren't any kind of documentation about it (or at least I haven't ever found one), most of modded actors use vanilla walkpaths.

I'm pretty sure that a good combination between improved walkpaths and a lua script like this would return a very good result.

Well, this may be wrong, but this is what I think is going on. I apologize for the TL:DNR

All a Walkpath appears to be... is the position of a pixel over time where the "ankle" is, in relation to the "hips".

This creates a vector with an angle and a length. The point where the vector terminates is the position of the "ankle". You do not change the "ankle" angle at all; this is done by the engine, apparently. That's why there's only one vector- it changes the angle of the thigh while at the same time providing for the new position of the ankle- pretty sweet, really.

What makes it confusing is that it looks totally different graphically. The characters have "knees" "bending" and suchlike. But note how the "hips" pretty much stay in the same position, for AHumans. If you draw a line between the "hip" and ankle, you get an angle; if you turn the bitmap to that angle, you'll start to see the walkpath emerge.

ACrabs do the same stuff, they just use a mix of animation frames, creating the illusion of a lot more complexity going on.

Finally, the engine appears to try and find the best match between the sim vector and the defined vector, if dealing with novel positions, such as when a character is climbing something, to find the best bitmap to use. Foot collisions can result in a change there, same with forces acting on the thigh.

Things like body lean are controlled by the engine.

The "foot" is not even necessary. IDK whether the engine crashes if you don't define a foot, but if so, it can just be an Atom of air, offset out of the ground.

The "thigh" does not actually have to change angles. You can just make a bitmap animation, use 0,0 for each frame. If you're trying to do anything really complex, like a mechanical robot with lots of pistons, and complicated joints, etc., that's how to do it. I don't know if that will hose the leg moving according to other forces, but probably not.

However if you're really in love with having feet that sort of half-heartedly act like they're interacting with the terrain, you'll need to do the entire animation sans the feet, then for each frame get the pixel values of the "ankle" position; this gives you your offset. But it will also change the angle of the "thigh", so that's a double-edged sword, to say the least.