PyDAT correction: portdata.dat fidget animation fields are mislabeled

While investigating why the Dropship portrait would only ever play fid00 and fid01, I traced the portrait-selection code in StarCraft 1.16.1.

The result is that this is primarily a PyDAT field-labeling problem.

PyDAT currently presents the portrait entry approximately as:



The last four fields are misleadingly named.

They are not separate "idle change", "talking change", and unknown parameters.

For the portrait fidget selector, StarCraft reads all four of those byte fields consecutively as the probability weights for:



In other words, the current PyDAT labels:



A more accurate PyDAT representation would therefore be something like:



or:



This distinction is important because the existing labels strongly suggest that:

• "Idle SMK Change" controls idle portrait changes.
  
• "Talking SMK Change" controls talking portrait changes.
  
• The last two bytes are unidentified values.
  

That is not how StarCraft actually uses them.

The executable's portrait fidget routine is around 0x44EB90.

It obtains a random value, then processes these four portdata.dat bytes cumulatively. Each byte contributes the probability range belonging to one of the four possible fidget animations.

Conceptually, the logic is approximately:



The corresponding runtime portdata.dat arrays are at:



So the ordering in the DAT is unambiguously:



This explains the Dropship behavior.

If one edits the portrait in PyDAT according to the current field descriptions, it is natural to modify only "Idle SMK Change" and perhaps "Talking SMK Change".

Doing that only gives probability to:



If the two "Unknown" values remain zero, then:



and those animations will consequently never be selected.

This can easily look like a StarCraft hardcoded limitation to two fidget animations, but it is not.

StarCraft 1.16.1 explicitly supports four portrait fidget animations:



The filename-generation/loading code is also capable of requesting all four.

There is additionally a fallback mechanism: if a requested fidXX file cannot be opened, StarCraft tries lower-numbered fidget files. So a missing fid02/fid03 can also make the problem less obvious by causing an earlier animation to appear instead.

For example, to give all four fidget animations approximately equal probability, the portdata.dat entry can use:



Which, using PyDAT's current labels, means:



The important correction for PyDAT is therefore:

Current:



Should represent:



The words "Idle" and "Talking" in the current four field names are especially problematic, because all four values participate in selection of the idle/fidget fidXX portrait animations.

The talking portrait SMKs are handled separately and should not be inferred from these labels.

So this is not merely a case where two fields are still unknown: all four fields have a coherent known function, and PyDAT's current descriptions are incorrect.

PyDAT audit: the "Unknown Flags" field in units.dat is not behaving as eight independent flags

As part of the ongoing effort to audit, improve, and where necessary correct PyDAT's representation of StarCraft's DAT files, I traced the field PyDAT currently exposes as:



This is the byte called unknown_flags in PyMS/PyDAT's units.dat implementation.

The important finding is that, at least in StarCraft 1.16.1, the executable does not appear to treat these as eight independently meaningful boolean properties.

Instead, this is fundamentally a single 8-bit unit property, and the confirmed engine code compares the entire byte against the specific value 0xC1.

That makes the current PyDAT UI somewhat misleading.

1. Where the field actually exists in units.dat

The units.dat loader uses a descriptor table beginning around:



The relevant entries are:



Therefore, for unit ID n:



The field is exactly one byte per unit.

The generic DAT loader does not interpret that byte. It simply copies it into the runtime array.

Relevant loader code:



Inside the generic DAT loader:



So there is no bit interpretation during loading.

2. The important part: how the game actually reads it

Searching the executable for runtime accesses to:



produces two especially important gameplay consumers.

In both cases, StarCraft compares the whole byte against:



It does not test the supposed 0x01, 0x40, or 0x80 properties independently.

3. Spider Mine targeting

One consumer appears in the Spider Mine target-selection predicate.

Relevant code:



The important instruction is:



Not:



Not:



Not:



The value must equal 0xC1 exactly.

Tracing the caller shows this routine is used as a nearby-unit search predicate:



This eventually leads into the Spider Mine's main order routine.

Therefore one confirmed meaning of this units.dat byte is:


This appears to be the real implementation behind the traditional "hovering / mine-safe" interpretation associated with this field.

It is worth being precise here: this prevents the unit from satisfying the mine's target acquisition test. It does not necessarily imply immunity to damage from a mine that was triggered by something else.

4. Zerg Birth also checks exactly 0xC1

The other direct consumer occurs in the Zerg Birth positioning logic:



This logic is effectively:



Again:



The engine is recognizing a specific class/value, not independently checking the bits that happen to compose that value.

5. Why this matters for PyDAT's checkbox representation

PyDAT currently exposes the byte as:



That is technically a valid way of editing an arbitrary byte.

However, it visually suggests something much stronger:


The disassembly does not support that interpretation for the confirmed consumers.

For example:



So checking:



produces the recognized value:



But checking only:



produces:



And 0x41 does not pass either of the confirmed 0xC1 tests.

Likewise:



There is an especially important consequence for experimentation with the currently "unknown" bits.

Suppose a unit currently has:



and we enable PyDAT's:



The result becomes:



The confirmed engine checks are equality comparisons, so:



That means adding 0x20 does not simply "add an unknown ability" while retaining the 0xC1 behavior.

For these code paths, it actually removes the special behavior.

This strongly argues against describing these eight bits as eight independent unit properties.

6. PyDAT itself does not currently know their semantics

This is also consistent with PyMS's implementation.

The field is effectively represented as:



with eight unnamed bits.

In other words, PyDAT is not currently claiming internally that:



The problem is primarily one of UI presentation and inherited terminology.

A checkbox-based flag editor naturally encourages users to assume that each bit is independently consumed by the game.

The executable evidence currently points instead toward a byte-sized movement/floating classification value.

7. Map unit settings can overwrite this value

Another important part of the pipeline is custom unit data embedded in maps.

The CHK parser contains handlers for:



and those handlers copy custom unit values into the same runtime array.

Relevant writes include:



The word write processes two adjacent byte entries at once.

So the actual data pipeline is:



This is important when testing the property, since a map using custom unit settings can override the value from the MPQ units.dat.

8. Suggested PyDAT correction

I think the current representation should be changed.

Instead of presenting this primarily as:



I would suggest something closer to:



The raw bit checkboxes can still be useful for research and direct DAT editing.

But they should be visually secondary to the fact that the underlying property is one byte, and that the currently confirmed engine behavior recognizes 0xC1 as a complete value.

Something like:



would probably be a better working name than:



until every possible value and consumer is fully mapped.

9. Current confirmed findings

At this point I would consider the following directly established from the executable:

• units.dat field 0x0A is one byte per unit.
  
• Its runtime array begins at 0x00660FC8.
  
• The DAT loader performs no per-bit interpretation.
  
• Spider Mine target selection compares the entire byte to 0xC1.
  
• Zerg Birth positioning also compares the entire byte to 0xC1.
  
• Those consumers do not independently test 0x01, 0x40, or 0x80.
  
• Changing any bit of 0xC1 causes those exact equality tests to stop matching.
  
• UNIS/UNIx custom unit settings can overwrite the runtime value.
  

What is not yet established is whether every theoretically possible value of the byte has some other consumer elsewhere, or whether some individual bits are interpreted indirectly by code that does not reference the array in an obvious absolute-address form. This sounds unlikely, however.

I would not go as far as declaring every other value permanently meaningless.

I would say is that the existing "eight unknown flags" model has no support from the consumers traced so far, while a single movement/floating class byte model fits the actual machine code substantially better.

This is therefore a good candidate for a PyDAT UI/documentation correction rather than simply assigning speculative names to eight checkboxes.

tlk00.smk
tlk01.smk
tlk02.smk

0044ECA3 mov ecx, 3
0044ECA8 idiv ecx

candidate = random() % 3

if candidate == previous_talking_animation:
candidate = (candidate + 2) % 3

try tlk[candidate]