FSMXML and the omnistate

[Skajaquada]

I'm working on getting a otherwise normal melee-unit (real melee, like the warrior) to also be able to use a real ranged attack. I've tried different combinations of the attributes in the unitmember-file and it really seem like if bHasLongRangedAttack is not set the "ranged" attack is that the unit walks up and does a real melee-attack. On the other hand if it's set there doesn't seem to be a way the unit can make a real melee attack. It seem to just default to the short-range attack.

Now I'm trying to figure out if the FSMXML-file have anything to do with anything. The structure doesn't seem to be too complicated, as can be seen in the Nexus-tool at the top of the file a lot of nodes are defined from the DGE-files. Then there are socket-sets that define the line between the nodes like "from 1 to 2". In those sets there are mostly conditions, like "if action is 1100 then set beta or gamma".

The "actions" seem to be mostly the ec-values that we've linked to animation-files in the FSXML-file and effects in the FTXML-file. For example "12 to 14", which are the nodes for combat-ready to attack, looks like this:

<socket from="12" too="14" bidirectional="0" order="0" conditions="12">
      <conditions>
        <condition type="FFSMConditionCheckPathOption" order="0.14196901" desc="" method="1" path="4" value="1100" />
        <condition type="FFSMConditionEventRandomPathOption" order="0.220375016" desc="" path="2" value="0" useweights="1">
          <weights>
            <weight v="0" w="0.5" />
            <weight v="1" w="0.5" />
          </weights>
        </condition>
        <condition type="FFSMConditionEventSetPathOption" order="0.286206" desc="" path="1" value="0" />
        <condition type="FFSMConditionEventSetPathOption" order="0.344739" desc="" path="4" value="0" />
        <condition type="FFSMConditionOrOperator" order="0.420351028" desc="" />
        <condition type="FFSMConditionCheckPathOption" order="0.489442021" desc="" method="1" path="4" value="1160" />
        <condition type="FFSMConditionEventSetPathOption" order="0.537419" desc="" path="1" value="1" />
        <condition type="FFSMConditionEventSetPathOption" order="0.6011897" desc="" path="4" value="0" />
        <condition type="FFSMConditionOrOperator" order="0.693456" desc="" />
        <condition type="FFSMConditionCheckPathOption" order="0.749970853" desc="" method="1" path="4" value="1180" />
        <condition type="FFSMConditionEventSetPathOption" order="0.801983" desc="" path="1" value="3" />
        <condition type="FFSMConditionEventSetPathOption" order="0.867700458" desc="" path="4" value="0" />
      </conditions>
    </socket>

1100 always linked to the normal attack in the original FSXML-files and 1140 and 1180 are bombard and city-attack. This is probably why we linked them in the first place. Perhaps the game sends out a signal 1100 and you want to pick both the right animation and the unit will want to move up to another unit.

I really want this piece of code and file to take care of the latter though I don't think it actually does that as I'll soon explain. In Nexus it says this under the input-folder for the attack-node:

if Action = 1100 then md (weighted) -> Gamma; set 0 -> Beta; set 0 -> Action
if Action = 1160 then set 1 -> Beta; set 0 -> Action
if Action = 1180 then set 3 -> Beta; set 0 -> Action

It should be that first piece of code they've explained there. Since it says "random" there it's likely about choosing the attack on 1100 or 2100. Commenting out that random to weight also causes my unit to just use one of it's melee-animations so I guess that confirms that.

Also in the Unit Viewer you can see states for each unit and "Path option" with values Alpha, Beta Gamma that are different for each separate model inside the unit, so I think it's just that. It generates some path how the unit should switch between the ec-values.

Any comments? I'm not sure if this file gets the ec-values or what's really happening. Though since most lines are about "check path option" and "set path option" I think it does just that, it decides what animations the unit should use. If we wanted to we could probably add more idle-animations and fortify-animations to randomly choose between.

Anyone seen anything similar in some other game or Civ 4 perhaps? Any idea where I can look now about my melee-problem? It's really starting to seem like a bugg to me though. I mean without a short-range attack, and you click the attack-icon it really seem like the unit should use the real-melee, right?

 

[Sneaks]

This is beyond anything I have attempted thus far, but I am eagerly watching for any progress you can make.

 

[Skajaquada]

I think I've actually got something to add. It's pretty good help you get by Nexus if you open the various viewers and see what it says in the settings fields when you click on things. For instance I learnt that the order-attribute in the FSMXML-file is the execution-order, whatever that means. If you look in the file at-least they were decent enough to have a top-down approach to execution-order for the rows, though entire sets come at different times.

The EC-values also stand for EventCode. I'm trying to figure out what level this FSMXML is on. There are no LUA-events that fire these codes? It can't be so transparent, like you click the Fortify-button and EC 1500 is sent? I really don't think so, but I hope. Then it might be something here that controls the real melee attacks. Though I assume there're some internal processes that send out these codes when they need the animations.

I also made some real head-way on the DGE-files. It's the first button to the left in Nexus that opens them... I remember I had seen that interface before, but there was a time I thought everything in nexus was broken and there was nothing to see or do. Anyway, you can open the DGE-files, edit and save them. They're linked to the nodes like "attack" and in them you can create additional nodes. I really don't understand why the DGE-files aren't XML-types like the rest though and unreadable on the outside.

Then the real confusion starts. There are some nodes like "sequence" that allows you to sequence animations. They're easy enough to understand. Then there are lots of animation-files linked to nodes that are linked together like the state-graph. It's also very hard to understand if the FSMXML-file generates the DGE-files or if it's the other way around. Some node in the DGE-file was referring to the weight-property, where it said something about random-choice, but that part was also in the FSMXML.

I guess this is mostly about blending together animations. There are some blend-nodes in the DGE-files. If you search on the Granny SDK there are some mention of a graph-tool that allows that. Did they use that making Civ 5 or what? What's up with all the GR2-files? Though my units switching between animations are as choppy as ever it might have something to do with the DGE-files, like this is part of the real generation of the GR2-files. Maybe the GR2-animation files are even generated based on this graph.