Feature Request #1900

Take action 6 into account when checking sprites (e.g. disable range checks)

Added by George almost 9 years ago. Updated about 6 years ago.

Status:NewStart date:2010-11-23
Priority:LowDue date:
Assignee:-% Done:

0%

Category:nforenum
Target version:-

Description

NFORenum does not allow to access 1-st sprite defined with GRM

5067 * 5     06 11 82 12 FF
//!!Error (133): Offset 18: Building sprites may not be null.
5068 * 25 02 09 02 02 01 80 00 80 06 80 00 80 08 02 10 03 03 3C 00 00 00 00 03 01 80

the next sprite works fine
5069 * 5 06 11 82 12 FF
5070 * 25 02 09 03 02 01 80 00 80 06 80 00 80 08 02 10 03 03 3C 01 00 00 00 03 01 80

Associated revisions

Revision 939:4fb07ab76a28
Added by Rubidium about 7 years ago

-Fix [#1900]: do not truncate U32-ish values to U16

History

#1 Updated by frosch almost 9 years ago

In the first case the building sprite is 0, in the second case it is 1. That is why nforenum does not complain on the second.

It is beyond nforenum capabilities to detect action 6 overwriting certain parts of the following sprite and concluding that the buildingsprite may not be 0 in that case.

#2 Updated by frosch almost 9 years ago

  • Tracker changed from Bug to Feature Request

#3 Updated by frosch almost 9 years ago

  • Subject changed from GRM allocation problem (unexpected error 133) to Take action 6 into account when checking sprites (e.g. disable range checks)

#4 Updated by Ammler about 7 years ago

  • Project changed from NFORenum to GRFCodec / NFORenum

#5 Updated by Rubidium about 7 years ago

The only solution I see here is that nforenum completely skips checking sprites after an action 6. As anything might have changed, e.g. changing the property in an action0 from a 1 byte to a 2 byte property in which case everything after it is misinterpreted.

Is that what you are asking for? Is that what we actually want?

#6 Updated by yexo about 7 years ago

In my opinion it's definitely not something we actually want.

#7 Updated by Rubidium about 6 years ago

  • Priority changed from High to Low

As per docs/nforenum.txt, this issue is low priority at best and likely to never fixed 100% correctly.

#8 Updated by Rubidium about 6 years ago

  • Category set to nforenum

Also available in: Atom PDF