NFORenum v3.4.6 released (NFO renumberer and linter)

[Lakie]

For objects, each tile in an object has one byte's worth of random bits. (It is not the same bits across the object though, and I'm not 100% sure its even usable).

As for the latter, it's not really an error, buts its bad practise not to give a ground sprite, for a number of reasons.
If you just want to change the sprite used there, change the ground sprite. (Applies for slopes with show foundations off).

~ Lakie

[OzTrans]

Random bits ... yes, they do work, are set at time of construction and remain static.

Ground sprites ... not a problem, I can change that.

[DaleStan]

Wouldn't it be nice to get a compiled fully up to date NFORenum v3.4.7 ?

It would. I have to get my brain wrapped around boost::bimap[0], and then I have to fix George's issue.

[0] On that subject. NFORenum may soon require boost 1.35.0 or later to compile. Cygwin comes with 1.33.1. Or, it may compile but without some features. Depends on how robustly I write the code.

1. Fixed, finally. I'm not sure how I failed that so badly for so long.
2. Rarely do two adjacent callbacks have the same meanings for their return values. @@WARNING DISABLE is your friend, until/unless I take a closer look at the callbacks.
   You can help this by listing all sets of adjacently-numbered callbacks that you think should not cause this warning.
3. Yes, I am sure. RandomAction2 says "All features not mentioned in the list above have neither random bits nor triggers". Objects are not mentioned in said list, ergo they have no bits. If the wiki is wrong, have words with whomever added random bits and failed to modify the wiki. It was not I.
4. All house-like action 2s must contain at least one sprite that will always be drawn, even when the object is invisible. I can't test that it's an appropriately sized ground sprite, but I can object when there's nothing that could possibly be the ground sprite.

[Lakie]

I did not know I needed to alter that page, I merely implemented them because TTDpatch complains bitterly if I didn't give it a function for it whilst defining the grf feature.
I've updated the wiki for both Objects Action0 Flag 0x100 and the Random Bits to the best of my knowledge though I suspect you know more about random bits than I.

~ Lakie

[DaleStan]

I did not know I needed to alter that page

Where did you expect me to look to find that information?

(Also, another data update.)

[OzTrans]

... Rarely do two adjacent callbacks have the same meanings for their return values. ...

That is true; actually it is only 140 and 141 that I commonly use with the same return value. CB 13/14 is a rarity, as I only have them with same results during development and it is just a coincidence.

I'm aware of '@@WARNING DISABLE' and I do use it.

[DaleStan]

I have to get my brain wrapped around boost::bimap

That part is done.

NFORenum may soon require boost 1.35.0 or later to compile. Cygwin comes with 1.33.1. Or, it may compile but without some features. Depends on how robustly I write the code.

This part, however, failed. It was too much work to get std::map to duplicate the behaviour that boost::bimap has out of the box.

The big new feature here is that it is possible to specify custom one-byte escapes.
There are two easy ways to do this, and several harder ways.

1. Add a line between "// (Info version 7)" and "// Format: xpos ..." that looks like, for example "// Escapes: @12 2<=>". That particular line makes \2<=> (Note the lack of a backslash in the Escapes line.) an escape for the byte 12, which is the action 2 comparison operator. (operator borrowed from Perl)
2. Run an NFO through this version of NFORenum, or decode a GRF with grfcodec r2098 or later. Then, find the escape you want to change in the Escapes line(s), and change it to your preferred value. (e.g., find '2rst' and change it to '2ret', which will add \2ret as a synonym for \2rst and \2r.

It is not possible to redefine or remove any of the built-in escapes, but the beautifier will prefer your custom escapes over the built-in ones.

If you are using grfcodec r1854E, it will read NFOs generated by this preview NFORenum (posted on the site) INCORRECTLY. This may or may not cause broken encoding. Please update grfcodec to the version in the the grfcodec thread, or use 0.9.10, which will ignore the Escapes line and thus either encode correctly or flat-out refuse to encode.

[planetmaker]

EDIT: I found the reason for the assert described below:

Code: Select all

-1 * 0  04 00 7F \b3 5D 
	"            Double Decker 4th gen"		00 // 5D
	""										00 // 5E
	"2CC xMU Express Wagon"					00 // 5F

If you preceed accidentially one of the comments with a single slash instead of a double slash the assertion is triggered.

Now I wonder whether throwing the assertion is intended or whether it would be better to just report an error for that sprite.


### old posting
I managed to trigger an assertion with nforenum:

Code: Select all

~/ottd/grfdev/2cctrainset> renum -w 42,94,141,143,144,147,17 2ccdj.nfo | tee -a renum.log
renum: command.cpp:111: bool is_command(const std::string&): Assertion `is_comment(line)' failed.
NFORenum v3.4.6 r2111 - Copyright 2004-2009 Dale McCoy.
Processing file "2ccdj.nfo".
A portion of sprite 2426 could not be processed.

I'm not sure whether it's a renum problem or a problem of my nfo file.

[Eddi]

I'm not sure whether it's a renum problem or a problem of my nfo file.

wrong input should never trigger an assert. so even if your NFO is wrong, then renum's error handling is broken.

[DaleStan]

Indeed. I've added that to my list of things to deal with once I get back to a computer that can speak SVN.

[planetmaker]

I'd like to propose to change to nforenum such that a high ID number is not necessarily treated as an error as OpenTTD can handle higher IDs nicely.

In order to maintain backward compatibility with the -w/W 141 flag I propose to have an additional parameter like -openttd or -highID which then changes the limits of the ID check to FFFF instead of the FF(?) as now.

[DaleStan]

I have thought about that, but nothing has come of it yet.

Part of the reason I've done nothing is that (AFAIK) no one has documented OpenTTD's limits. Or if they've been documented, they're not in the appropriate places. (Various locations on wiki.ttdpatch.net.) I know the valid IDs for some features are in 00..FFFF, but other features have smaller ranges. I have pretty decent guesses on which features are not 00..FFFF, but I don't know for sure, and I definitely don't know what the real limits are for, e.g. stations or industry tiles.

[DaleStan]

In OpenTTD since r13482, extended IDs (up to 65535) can be used for vehicles as well

OK. Now what about the other features? Stations, bridges, houses, currency properties, industry tiles, and objects?

Also, what are the limitations on DCxx IDs? Is it still DCxx or is it DC00..DFFF?

[planetmaker]

It's not forgotten and not the last. I stalled a bit though as there were currently quite some modifications going on (introduction of a new pool), which might have an impact on this - thus I thought to wait for them to consolidate a bit.

[DaleStan]

EDIT: I found the reason for the assert described below:

That should be fixed, as of r2113.
I was assuming in one place that a single slash was sufficient to begin a comment, and then asserting later that two slashes were present.

[DJ Nekkid]

are there a windows binary downloadable somewhere? im still useing r1795 from about 3 years ago...

[Lakie]

Probably, although you can always download and compile a copy yourself if you want the latest version.

~ Lakie

[DaleStan]

You can Download a somewhat experimental build, but it's "hiding in the corner". (Subtle hint)

[DJ Nekkid]

oh, found the corner! Its in the middle of the wall ;p

[planetmaker]

Find attached a windows executable of nforenum which doesn't need cygwin libraries (compiled using MinGW and MSys). It's based on SVN r2114

EDIT: sorry, I was sloppy. Added license information to download