Creating combat classes

You mean all the time? Existing unit or new unit? Since day 1 I've had trouble with imported units that their move- and attack-animations doesn't always start or don't start right away. At first I thought it got better when I shorted down the idle-animation but I'm not so sure.

Otherwise some days ago when I accidentally removed the FXSXML-file reference from the unitmember-file the unit simply wouldn't animate. When I clicked a hex it stood still at the originating hex for a few seconds and teleported to the destination.
 
Is it possible that it uses the combatclass name to pick animations from the FXSXML file listings (or elsewhere)?
 
All the time. If I create a new class and give it to an existing unit, that unit does not have an attack animation. It does the other animations fine. There's no reference to the combat class that I could find in the fxsxml or artdefines files...
 
Some combat classes CAN be changed, and still have animations. This primarily occurs with air units; you can create a new air-based combat class and everything will still animate just fine. I've found a few other specific cases where it all still works, but yes, generally speaking you'll lose the combat animations if you change classes around.

The problem seems to be within the unit's own fxsxml files, probably within the StateMachine files:
1_OMNI_MOUNTED_STATE_01.fsmxml
and
1_OMNI_STATE_01.fsmxml
Airplanes use
AIRPLANE_STATE_01.fsmxml
instead, so I'm trying right now to see what could explain the difference.
 
Hmm... so now I'm somewhat puzzled! :crazyeye: Are either of these possible with our current tools:

  • Create a "Mounted Archer" unit class for keshiks, camel archers, etc.
  • Create a "Submarine" unit class for subs.
 
You can create them, they just won't have attack animations until we figure out the state files I mentioned. To me, the animations are far less important than the mechanics, so I'd say to go ahead and make those classes anyway. (This is why my mod still uses a lot of placeholder graphics for its units; while custom 3D graphics would be nice, and I'm still working on them, it's more important that the underlying game balance correctly. Aesthetics are a secondary concern.)

One other thing I thought of: it could be purely internal to the engine. The determination of where the units stand when the combat animation starts could easily depend on the combat classes of the two units involved; if you go into the artdefines_unitmembers file you'll notice that many units have two weapon definitions, one for normal combat and one when defending from air units, so if the "normal" one leads to some internal table lookup that keys off of combat class then there's nothing we can do about it. (This'd also explain why the air units still work.)
If this is true, then we'll have to wait for the DLL to even have a chance to change it.

Side note: In my mod I had no need for a separate submarine combat class, because both subs and destroyers upgraded to a single vessel in the future eras. So while land promotions on a sub might be useless at first, once you upgraded the unit they'd be very handy. But in a vanilla environment you don't really have that option.
 
An interesting note is even though no combat animation plays, the "end combat sim" event still runs. Normally in situations without a combat animation that event does not fire.
 
An interesting note is even though no combat animation plays, the "end combat sim" event still runs.

Correct. RunCombatSim and EndCombatSim both still work; it's not that it's skipping an animation, it seems to be that it's trying to run an invalid one somewhere and immediately ending. That's why the post-combat animations (moving into the target's hex, for instance) still run correctly. I make extensive use of those two events in my mod, so this was something I looked into a long time ago.
 
This can actually be seen as an advantage... the attack speed of chariots and keshiks can be insanely slow, requiring 5-6 seconds per attack. This will easily chop 60+ seconds per turn from my Mongolia games.

It might be an interesting way to work around the problem with Quick Combat. Could eliminate the combat animations from all units yet still use the end combat event...
 
It'd be easier if Firaxis provided more support for mods, in general. It had a great start when Civ 5 was released, but we haven't seen many improvements since then, often going backwards (in the case of combat detection). :)
 
Back
Top Bottom