Proof of concept: Large, non standard characters.

[Macser 776]

A small video showing a "race" between a default character and a custom one. Despite the default character getting a large head start, the custom one catches up and even overtakes it. There are no scripts running on the custom unit.

Just in case it's not obvious from the video here's a size comparison.

The main reason you never see any large sci-fi/fantasy oriented characters, is because of the instant death effect. Creating the model is easy enough. But once you get it in game it will fall flat on it's face, dead after a few steps. You can increase the armour value and even use a health check script, but usually to no avail.

It seems there's a relationship between a couple of aspects. I don't know the technical reasons. Only what I've observed. They would seem to make some sense. The rtm definitions in the config have two settings called duty and speed. These obviously affect the outcome. Duty is how tired the character becomes as a result of the animation being played. And speed is the playback speed of the file. A faster playback might be multiplied by the duty to get a result. The higher the speed the faster the accumulated "fatigue" builds up. A large character might appear to move slower, relative to their size. So if you increase the playback to compensate you're likely hastening the "fatigue" effect of the animation. Thus killing them.

I can't prove that of course. But I did observe that a speed value over 3.5 on my own character always resulted in death. Regardless of duty, or distance travelled. So I zero out duty,(If it's a sci-fi project it's not that unusual), and keep the playback speed under 3.5 for all animations. From there I achieve the results I want with the actual animation itself.

The speed value can still be used to fine tune the results of course.

Edited May 2, 2015 by Maczer

[kenoxite 156]

Excellent stuff, Maczer. Thanks for the explanation.

[Macser 776]

No problem. It does open things up a bit creatively. But there's still some drawbacks. One being the fact that mass is not a global attribute. It can be affected by class type. What the logic behind that was, I don't know. So some scripting is still needed for anything more mechanical. Like big walker type units. Otherwise your 30 foot tall "mech",weighing 100s of tons, gets pushed around by a 6 foot tall man. As if it was a beach ball. Funny for a few seconds only........ :)

[Lenyoga 326]

Impressive, most impressive. Now I may make Shodan a hunter-killer type.

[Macser 776]

Sounds good. If the unit is supposed to be quite large it might require a script to "barge" nearby smaller units out of the way. Particularly if they're other man class types. It's really nonsensical.

If you increase the mass of a man class unit to something huge it will stop tanks and cars in their tracks. It will even damage car type vehicles if they impact at speed.

But here's the silly stuff. If a tank is stationary when the unit walks into it, it won't move the tank.But if the tank was moving slightly, even just a little, at the point of contact, the tank will be kicked around like a football.

As I mentioned in my previous post:

Your new monster machine of death may stand 100ft tall and weigh a bazillion tons. But ANY other man class unit, even if they weigh 2Lbs and could literally blow away in the wind, can push that Monstrous creation around like a giant beach-ball.

And explosions/bullet impacts have the same frustrating aspect. Bullet strikes impart a flinching movement to the unit. Although this can be countered somewhat by using custom bone names. While explosions will make the unit jump vertically. That could be a geometry issue, as well as class eccentricities.

I'm not trying to put people off. I just think it's best to have no illusions about the limits. It still looks really impressive to see something huge like that on a map.Especially if it's animated well.

Mass should always be a consistent attribute. Regardless of the object. Unfortunately, in OFP/CWA it isn't. :)

[kenoxite 156]

Your new monster machine of death may stand 100ft tall and weigh a bazillion tons. But ANY other man class unit, even if they weigh 2Lbs and could literally blow away in the wind, can push that Monstrous creation around like a giant beach-ball.

Just a shot in the dark, but regarding the problem with mass: have you tried making such units inherit, say, the tank class, but use the soldier simulation? (simulation = "soldier"; )

[Macser 776]

I seem to remember trying it both ways. A tank with solider simulation and a soldier with tank simulation. It was quite a while ago. The end result was the same if memory serves, the unit just stood there.

The tank class has it's own limitations anyway. Although mostly visual. Config based animations have never appealed to me. :)

[kenoxite 156]

The tank class has it's own limitations anyway. Although mostly visual. Config based animations have never appealed to me. :)

Well, an inherited tank (or any other armor type class) with a soldier simulation should move as a soldier, not as a tank. But, by inheriting the class of an armored vehicle it might solve the problem with mass. The only drawback is all the hassle of creating this new hybrid class, but you could just copy/paste the BIS Man class and change the appropriate parameters.

[Macser 776]

I'll definitely have another look at it. But I doubt it'll run rtms. :)

[Macser 776]

Trying to use the soldier simulation inside a tank class caused a CTD unfortunately. Not too surprised. :)

The man, tank and car classes are all vehicles. So I assume simulation is the main factor that separates them, other than memory points and config settings.

There is only one vehicle (non man class) that can use rtm animations. The scud launcher.

[Lenyoga 326]

But here's the silly stuff. If a tank is stationary when the unit walks into it, it won't move the tank.But if the tank was moving slightly, even just a little, at the point of contact, the tank will be kicked around like a football.

I think there's a bug or "feature" for tanks - they do interact well with physics as long as they're stationary. I'm not sure if this still holds up in 1.96 and 1.99, but when I once spawned one in the air, it didn't even fall until moved (by shooting or driving.)

[kenoxite 156]

Trying to use the soldier simulation inside a tank class caused a CTD unfortunately. Not too surprised. :)

The man, tank and car classes are all vehicles. So I assume simulation is the main factor that separates them, other than memory points and config settings.

There is only one vehicle (non man class) that can use rtm animations. The scud launcher.

Oh, well.

[vran. 13]

Off-topic, but are you making some Star Wars addons? Those AT ATs with animated walking look fantastic. :)

[Macser 776]

Hello noob1, and thank you. I don't want to start making promises I can't keep. But I'd like to release a couple of addons at least. The At-At being one. I'm not a great scripter, and obviously there are always limitations with OFP/CWA and even the newer titles. So some things I can't overcome. Having said that, in the right setting they work well. And they look and sound the part. :)

As regards the topic, and specifically the mass issue. After some experimentation and pushing the weight to ridiculous levels I managed to cure the unit being launched into the air by relatively small explosions. By "ridiculous" I mean 6 million tons. :D

Some of the other problems will still need to be sorted via script though.

@Lenyoga

I think the "feature" affects every vehicle apart from the man class. Sometimes a spawned car won't settle into it's suspension until it's hit by a bullet, or it moves. The problem is that even if the man colliding with a tank, weighs 6 million tons(proven by experiment), it won't budge unless it happens to be "active". As soon as it is, and contact is made, it's kicked the way you might expect. :)

Edited May 16, 2015 by Maczer

[Lenyoga 326]

As regards the topic, and specifically the mass issue. After some experimentation and pushing the weight to ridiculous levels I managed to cure the unit being launched into the air by relatively small explosions. By "ridiculous" I mean 6 million tons. :D

Is that how you made those wonderful AT-ATs work? 6-million ton man-class units? This is insanely awesome, I just saw the clip in the videography section! RTM handles so much better than those one dimensional object animations, I can think of future uses for environmental objects like doors and animated machinery too, the possibilities. Were I unwed, ... you know the drill.

[Macser 776]

:D

Obviously like everything in OFP/CWA there's positives and negatives. The man class is ideal from a visual point of view, for the reasons you mention. They look the part. But it comes at the cost of flexiblility in weapons and environment interaction. The At-At has no head selection. In fact it now has no recognisable named selections as far as the engine is concerned. So the hard-coded procedural animations don't affect it. These are the non-keyframed animations that are played when a round hits a unit. Or when the unit looks around,up and down.

I just tried 6 million tons to see what would happen. And noticed that explosions no longer affected it. I wrongly assumed that this was responsible for the lack of flinching though. The lack of any selections is the more sensible conclusion. I haven't done extensive testing to prove this.

So it looks good stomping around.There's no flinching, or going airborne if a handgrenade,or tank shell hits it. It sounds decent too. That's the good stuff.

Now for some balance. :)

Cargo ability:

You can't carry cargo. Although you could fake that to a degree with some clever scripting. Ie, spawned troops and vehicles.

Class restriction with mass:

Regardless of how much it weighs it's still bound by the unfathomable class restriction regarding mass. So as I said earlier, any other man class unit can push it around as if it weighed nothing. The only way I've managed to combat that is with a looping script that uses setpos'd geometry to keep other units at a distance. This aspect actually works fairly consistently. Multiplay might be an issue though.

The mass problem also affects interaction with stationary objects and entities. This means that a moving (active) vehicle will be barged aside or kicked in the case of the at-at. Even a 60 ton tank. However. If the tank is inactive when contacted, it will halt the unit. This applies to anything. Even a small plant. If it has geometry and it's not active the unit will get caught on it. The ai will of course atttempt to navigate around it. But it doesn't always work. But that's something you would expect of a soldier. It doesn't know it weighs 6 million tons and the engine doesn't recognise that in a logical way. Perhaps the same script that keeps units away, could be used to predestroy certain items. Plants would be the major concern. Buildings are big enough that going around them would be logical anyway.

One other thing. That scripted geometry still won't push a stationary object aside. It's simply there to keep man class units from making contact.

Land contact:

In OFP/CWA there is no provision for quadrapeds. So it doesn't matter how many points you put in, it only takes the position of two of them. On rolling terrain or steep inclines this becomes very clear. I don't know how that could be combatted. Although for me it's still not a deal breaker.Typically this means the back legs will be in mid-air when walking up a hill. The steeper the hill. The more obvious the effect.

Geometry issue with dead units:

I need to do a little more testing with this. But it seems the geometry becomes inactive after the unit dies. I didn't notice this before. This might be more of a problem to combat.

No pilots, drivers or gunners:

Obviously, it's a man. So no crew positions. Although you can see from the head because of the memory points. But it won't match up with weapon movement, as I set the dexterity so that the head(weapon) moves more slowly and smoothly. Personally this doesn't bother me much, as it's more fun running alongside or having to face-off against the machine.

Now. That might sound all doom and gloom. But not to me. The video shows that the right setting and mission approach can make the unit work. Even with the limitations I prefer this method to config based animations on a tank. :)

Edited May 21, 2015 by Maczer
Additional information

[kenoxite 156]

> Cargo ability

You might be able to bypass this by creating a vehicle with only a cargo LOD and move it along with the AT-AT via a setpos loop. This might cause other problems, but should theorically work quite fine.

> Class restriction with mass

Similarly, maybe you could just keep the geometry LOD of the AT-AT empty and use another, invisible, vehicle with proper mass and inheritance just for collisions. That vehicle would be setposed along the AT and would work as an external geometry LOD. The problem is this might and probably will create problems with AI pathfinding, as the AT will always be "stuck" inside that vehicle. This is a similar problem found in, for example, grass addons. In that case destroying the grass on spawn seems to fix it, but I'm not sure this trick would work with the proposed invisible vehicle/geo LOD companion.

> Land contact:

Have you tried setting the vertices of the feet and legs to "Keep height (fence)"? AFAIK this only works on static objects but, hey.

> Geometry issue with dead units

This is probably the easiest to solve. You can just delete the vehicle when destroyed and replace it with a destroyed model. As long as the dead animation is always the same noone would ever notice.

[ProfTournesol 956]

You could also do what i've done with horses. Put your AT-AT in the cargo (or driver) position of an invisible vehicle, and animate it with scripts. Not perfect either though.

[Macser 776]

Hey Prof, Kenoxite. All suggestions are welcome, no matter how unorthodox. :)

I'll give them all a try and see what happens. Although I hate using scripts excessively, a couple may well

be necessary in this case. And the fact there should be fewer of the units in a mission is a plus.

Edited May 22, 2015 by Maczer

[vran. 13]

Trying to use the soldier simulation inside a tank class caused a CTD unfortunately. Not too surprised. :)

The man, tank and car classes are all vehicles. So I assume simulation is the main factor that separates them, other than memory points and config settings.

There is only one vehicle (non man class) that can use rtm animations. The scud launcher.

The GDI Juggernaut uses the tank simulation afaik, but was animated via FWatch extended scripting capabilities so I think it's possible to have nice custom animations on tank class too. By the way, are the simulations all hard-coded? I was just looking at a 'dynamic suspension' script which makes the car simulation feel better but apparently requires selections to be made in O2.

[Macser 776]

No doubt the tank class has it's advantages. I think it's down to personal preference. I don't personally mind the limits of the man class ,too much. Especially when you see it on the move. For me it wouldn't have the same impact with config based animations.

I believe the simulations are hard-coded. I think some classes can be hybridised. Like weapons. But that doesn't seem to extend to vehicles.

The script you mention sounds similar to the DKM tank suspension. That animates the land contact points. In that case there was one or two axis points as center pivot. I assume with a car it might need some extra points for each wheel. Was that from the UKF team by any chance?

[vran. 13]

Yes it's the DKM suspension script. It's not ideal for cars but it does improve the feel somewhat.

[Macser 776]

There was a script or set of scripts for a UKF land rover. Which gave the effect of independent suspension for each wheel. It may have been experimental, or it may have been released with the mod/addons. Were you thinking it could be applied to the "feet" of a walker type vehicle? Via script?

The only problem I could see with that, is the lack of IK. Characters have a simple version. But vehicles don't have any that I'm aware of.

[vran. 13]

There was a script or set of scripts for a UKF land rover. Which gave the effect of independent suspension for each wheel. It may have been experimental, or it may have been released with the mod/addons. Were you thinking it could be applied to the "feet" of a walker type vehicle? Via script?

No I just thought about using it for some car models. Although the idea for walking vehicles could be applicable too.

[faguss 65]

dead after a few steps

If a unit is going faster than 10 m/s (roughly speed=4.84 in CombatRunF) then damage is dealt. That's hardcoded.

I could add in the next Fwatch version command so that you could increase the threshold but that affects falling/ejecting from car (for all units) as well.