Observation: RSM 1.5 files have an additional 4 bytes that are unaccounted for in the different implementations.
It seems that they're usually skipped as they can successfully be asserted to be zero bytes in every known instance, so no functional difference will be seen. My hypothesis is that these are "position animations" which are similarly unused as the "scale animations", later added in RSM2.
In the current decoder, tests and implementation ascertain that:
The bytes are always present in RSM 1.5 files, and that they're always zero (0x00000000)
They're never present in RSM 1.4 as well as all known Renewal versions (2.2 and 2.3)
There are no unaccounted bytes if these are processed as "number of position animations" (uint32_t)
Conflicting information was provided by these sources:
Observation: RSM 1.5 files have an additional 4 bytes that are unaccounted for in the different implementations.
It seems that they're usually skipped as they can successfully be asserted to be zero bytes in every known instance, so no functional difference will be seen. My hypothesis is that these are "position animations" which are similarly unused as the "scale animations", later added in RSM2.
In the current decoder, tests and implementation ascertain that:
0x00000000)uint32_t)Conflicting information was provided by these sources:
What could be done to possibly verify/disprove the hypothesis: