Basically, I wanted to see if my theories about walkpath that I expressed earlier were right, so I did some tests, since people find this mysterious. I figured it was the least I could do for the modders, since their projects have been what has made this game fun for me.


What I did to test what that I basically tried to set up a "car" with pixel "wheels". I gave them two frames of animation and got it all set up, then started removing junk to see how far I could push it.

First off, you can set up legs to have positions of 0,0 and you can get rid of all their walk frames without a crash. I want to confirm that this works just fine, so you can basically use as many or as few walk frames as you want, and my theory about how the vectors work appears to be true.

In theory, that would allow for static animated sprites in the traditional way, which with a bit of Lua love for the motion behaviors would probably be an improvement over the current stuff, at least for some situations.

That said, it just doesn't work correctly, due to some serious engine-side problems.

1. The biggest issue is a flat-out bug. If you use this in your leg parameters:



This should result in a leg that cannot contract or extend via interactions between ground and other actors. It doesn't; instead the legs auto-gib the movement the Actor is spawned

I presume that means the engine's trying to push it anyhow, even though those states should not allow it to move. I consider that a bug; the parameters should rule the engine, not the other way around.

2. No matter what you change, the joint remains floppy, even when stiffness is > 1.0. So, for example, if you try to do wheels this way, it won't work. Not only is it floppy, but it's arbitrarily floppy within some very weak constraints, which is one of my biggest beefs with the engine. JointStiffness doesn't seem to contribute anything to legs at all.

3. If you don't define a foot, the engine crashes. You must have one Atom defined, even if it's Air and for all purposes doesn't exist. Crazy, but that's what it wants. I haven't tested giving ACrabs less than 4 feet; I'm guessing that's OK, but they still must have feet defined. Crazy, eh?

4. Legs do not detect ground collisions at all. Their joints do, and the Atoms for the foot do. I don't think auto-generated stuff does at all, which would explain a lot about why characters can clip through terrain all the time but then suddenly lose a head or a leg or an arm- they've "caught" the joint and the resulting force was enough to break it

That's not a bug, per se, but it explains a lot about why things do what they do.



---------------------------------------------------------------
Anyhow, that's pretty much it. Legs work basically like I thought, but are very engine-bound and can't handle certain situations, nor is there any way to get rid of a lot of the stuff the engine does behind the scenes. I'm a little disappointed that I can't get rid of the floppiness somehow but ah well.

So, are there any good points from this? Sure, information is always useful.

For one thing, you can do a walk state that just has two frames (forward extended, rear bent) and build your vectors based on the positions of the "ankles". I don't think you have to even do any trig, just get the pixel offsets and plug them in. This may result in some banding when animated, but probably no worse than what already happens. So it's probably possible to make animations simpler to create, although the results may not be quite as pretty. That said, I'm fairly certain you need all 5 frames to keep it looking good in all states, at least for humans, and you'll still need to make at least the two vectors and use a defined foot.

Secondly, since the foot is the real "hitbox", even though in the case of ACrabs it's invisible, that points to ways to try and fix your characters if you don't like using Lua to just force the character to behave better. You could add more Atoms and make a line or two across the bottom of the foot for a Giant Robot, for example, to keep them from burying themselves in terrain as much. It's probably both easier and cheaper to just use Lua, though, because you're still going to have issues with mass, etc.

And this testing points towards constructive things that could be changed in the engine to make things better.

I've spoilered that, this was already TL:DNR.

This is a really well thought-out post. Thanks for taking the time to make it. I'll give you a bit of what I know from a few years of modding and working on the game. Just a note before I continue: I'm a content developer, so I don't have access to the engine's code (the only person who does is Data), but I have a basic understanding of how it works.

You're definitely right. A lot of the issues with the engine come with the fact that parts of it are over 10 years old. Modding for the game does tend to involve a lot of workarounds.

If I remember correctly, JointStiffness is a bit of a misnomer. It actually has to do with how much force is transferred from the limb to its parent object, so with a JointStiffness of 0.5, 50% of the force transfers.

As I understand it, auto-generate just means that the engine creates the atom group for you instead of you defining it yourself. I don't think that affects whether it collides with terrain, but I could be wrong. You're correct, though - the feet are the only part of the leg that collides with the terrain.

Yep, that's the way to do it. I think the main confusion for people is how the pixel offsets work (whether it's relative to the last position or not, which way is up, which way is right).

There actually is one - the Actor class. Grab the code from the Brain Case in Base.rte/Actors/Brains.

This is actually possible already. The main issue is once again that the engine was designed to do very specific things a very long time ago. There are some odd graphical effects when you've got multiple bodies like that right around each other, because there isn't really a layer system set up. The only way to guarantee one object draws in front of another is with hardcoded joints. So, like you said, that points toward a more flexible joint system being a good idea. It definitely is, but it's probably not going to happen. At this point, the game has been in development for a really long time, and I think Data wants to be able to finally say it's finished. Data's newer project (CVE) is a lot more flexible as far as physics goes, and will fix a lot of the mistakes and issues with Cortex Command. Unfortunately, I outside of a full rewrite, the RTE (CC's engine) will probably never include all the features we'd like to see.

True enough, although converting the actors to the right palette when they die would actually be more troublesome than it seems. Take a look at the palette for the game - there are a lot of colours missing. For instance, if you had a purple actor, you'd be in serious trouble.

This would actually be really nice. Like I said, the focus at the moment is on finishing the game, but I would certainly like to see something like this in the future.

Hopefully that clears a few things up for you. Again, thanks for the feedback and information. I'm sure somebody will find it useful for modding the game.

Ah... I'll try a JointStiffness of 0 then, see if that keeps the "legs" from popping off. Otherwise I'm sure it can be halfway handled via animated attachments or suchlike. The Lua I wrote means that the feet are irrelevant anyhow, other than stopping them from being collision objects.

As for this "CVE", is there any public information about it available yet? Yes.

I like a lot of things about this engine, I can see there is a lot of opportunity that could have happened. I just wish it worked a little better.

Totally understand wanting to get it "done"; my own try at such things led me to the unhappy conclusion that you just have to know when to let go. If the campaign system merely picked random locations for the A.I. to "mine" or "attack" each turn and perhaps some of the principles I've provided in that Lua were used to improve Actor behaviors a bit more (try it out, if you haven't already, it makes a considerable difference), it'd probably be "done enough" for most people.

Pity that the factions aren't totally fleshed out and that there aren't more structured campaign scenarios; I semi-seriously thought about embarking on that, but decided the last thing I need to do is take up another huge modding project, and most of my skillset other than coding is in 3D so it'd be slow going anyhow

The factions will be fleshed out more than they are at the moment, so no worries on that front. I think there are plans to include a few campaign scenarios, but it probably won't be the main game. I'll be sure to check out your Lua scripts soon, they sound really useful.

Mainly for campaign stuff, short of major rethinks about the game design, I'd just want to see stuff like having a couple of forts, unlimited guys on both sides, just to enjoy the carnage.

I really like the idea of doing big WWI-style battles where you and the AI get to do a lot of fun attrition warfare, with more structure and defenses for the AI than Skirmish- I'll have to look at the available Scenes and see if there's anything like that- the stuff I've enjoyed thus far has been those break-in missions but I would like to see stuff where it's more RTS-like, and both sides compete