Document Object Class 14 (Critters)

[dertseha]

Document the Critter objects:

• Level entry
• Class & Subclass info

[dertseha]

I've finally started to have a look on the critter data. The level entry is quite big and seems to hold several fields. Though, only a few seem to be necessary as a minimum to get a critter going.

The primary field, the critter's state, is identified, and there's even a state "confused" :) I wonder what kind of effect causes that.

There are also some fields that appear to be map coordinates. I'd guess them to be the roaming range, though so far I couldn't get my test critter to walk. They are kind of tricky to to test since they become hostile so quickly.

[dertseha]

The fields around offsets 0018-001B (and possibly two before and after) appear to specify something like a roaming range, with X and Y coordinates. Though, this doesn't seem to work.
Watching a cyborg in the real archive, this one walks around, completely ignoring the three tiles it would have assigned. (Though, it also went into them, so it's not an ignore pattern)

Still, although (apparently) properly setup up, critters I place in a construct level don't roam. At all.

[dertseha]

Using a spawned critter for testing, I've copied the entire level entry of a roaming critter from the archive, including the state of the object, as well as the entire level variables entry. The critter wouldn't roam.

I also tried to meddle with the byte at offset 0x13 in the master object table, which was cautiously called "AI index" in TSSHP. Still nothing.

What is missing? What makes them tick?

[dertseha]

Finally some progress. I tried modifying critters from the main game, to see whether they also wouldn't move on their own when set up similar to other roaming critters. I tested with the first Serv-Bot you encounter. And: it didn't move. Checking back with the reference bot, I realized this one only started to move when it came into visual range. So I rearranged the test setup to modify the Serv-Bot before seeing it the first time - and finally it moved after seeing it the first time.

So far I haven't figured out how this information (whether the critter had been seen) is stored. Still, just the little change of having the critter roam had several of the bytes light up in the class data.
I am starting to believe that these bytes are some sort of AI scratchpad. This would explain why the bytes of which I thought they'd be the roaming range aren't considered. They could be some area the AI peeks in or something.

Either way, if that's the case, then it wouldn't make much point to decode the bytes in total. Trying to reverse-engineer the AI logic just from its state snapshots would be too much - and unnecessary. What I do want to figure out is how to set up the critter so it roams without having to spot it first.

[dertseha]

I managed to isolate most of the critters' bytes and even uncovered some funny details as well (they can be made quicker for instance :) ) Some bytes as were marked as AI-scratchpad data now. I don't think it's that much important to know the exact AI state from an editing standpoint; It's enough to know a setting how to get it roaming.

Still, a few bytes might uncover special behaviour, though it's tricky. For the most part, I could only analyse the data on combat level 0 - otherwise critters immediately jump to be hostile and doesn't get me anywhere.

[dertseha]

The critters stay illusive, also with their generic object properties.
I believe to have found most of the meaningful bytes now, though it feels a bit weird to have so many bytes to appear without any effect.