Transport Tycoon Forums

make a "clean tile" at the top of the grf' and use it whenever you need a "default" that is never gonna be reached anyway?

Well that's a non-solution IMO. I much rather accept the warnings being there than implement code that is never used.

FooBar wrote:Well that's a non-solution IMO. I much rather accept the warnings being there than implement code that is never used.

Yet you implement a default that is never used.

FooBar wrote:I tried using renum -w 100,141,144 but ... this silences warnings 141 and 144 just fine, it doesn't silence this warning 100.

On a more serious note, are you quite sure that's what it does? Debugging suggests to me that it doesn't do anything at all. (Please don't ask me how I pulled that stunt.)

FooBar wrote:Well that's a non-solution IMO. I much rather accept the warnings being there than implement code that is never used.

oki, i see that, but then;

FooBar wrote:

Code: Select all

-1 * 0 02 09 B3 //layout 3 
	85 43 //check relative position (00yx[YYXX])
	00 FF FF //don't shift, don't mask
	\b3 //number of ranges to check (number of tiles)
	//pit
	\wx00  01 02  01 02
	\wx01  00 02  00 02
	\wx02  01 00  01 00
	\wx00 //<default> (first sprite available)

Why not:

Code: Select all

-1 * 0 02 09 B3 //layout 3 
	85 43 //check relative position (00yx[YYXX])
	00 FF FF //don't shift, don't mask
	\b2 //number of ranges to check (number of tiles)
	//pit
   \wx00  01 02  01 02
   \wx01  00 02  00 02
   \wx02  //<default> (first sprite available)

or similar then?

Leaving one variation out and use the default for that is duly noted

DaleStan wrote:On a more serious note, are you quite sure that's what it does? Debugging suggests to me that it doesn't do anything at all. (Please don't ask me how I pulled that stunt.)

That's how -? told me how to use it:

-w and -W (and their long counterparts) also accept a comma-separated list of messages, all of which will be ENABLEd or DISABLEd.

It might be that I don't have any warnings 141 and 144 any more...

/me goes testing...

EDIT: It seems that I don't have warnings 141 and 144 any more (probably due to renum update), but -w 100 doesn't do anything either...

FooBar wrote:It seems that I don't have warnings 141 and 144 any more (probably due to renum update), but -w 100 doesn't do anything either...

Now this I can't reproduce; -w 100 works for me. Anyway, hopefully 2127 will fix the issues.

DaleStan wrote:

FooBar wrote:It seems that I don't have warnings 141 and 144 any more (probably due to renum update), but -w 100 doesn't do anything either...

Now this I can't reproduce; -w 100 works for me. Anyway, hopefully 2127 will fix the issues.

How about putting the latest prebuild win executable at http://users.tt-forums.net/dalestan/nforenum/ ?
r2100 is the latest one I see there

@DaleStan: thanks again for the quick fix! Indeed that has -w100 working here now, again, too.

@George: Currently I try to keep available the latest binaries at http://dev.openttdcoop.org/bundles/grfdev
I still hope that we manage to get the OpenTTD compile farm providing latest binaries automatically

DaleStan wrote:Anyway, hopefully 2127 will fix the issues.

Thanks for fixing something that wasn't broke in the first place, so I think an apology is in order...

I had -w 144,141 specified in my Makefile.local all the time, so changing the renum flags Makefile.config to -w 100,144,141 or even -w 100 didn't have any effect at all, as Makefile.local overruled those.
So next time I can't get something to work, ask me about my makefile.local...

But then you're commit isn't completely useless, as now there's a check to detect faulty command line arguments.

planetmaker wrote:@DaleStan: thanks again for the quick fix! Indeed that has -w100 working here now, again, too.

@George: Currently I try to keep available the latest binaries at http://dev.openttdcoop.org/bundles/grfdev
I still hope that we manage to get the OpenTTD compile farm providing latest binaries automatically

Thank you!

With nforenum r2166 I have problems to use target "bundle_zip" under MinGW, as MinGW isn't recognized as a windows environment and thus the target "release" searches for renum instead of renum.exe. The attached diff amends Makefile such, that a MinGW environment is detected and the correct binary name assigned.

Btw: Thanks for fixing the random bits for canals. New versions, using the new bundle_zip target are uploaded to http://mz.openttdcoop.org/bundles/grfdev/nforenum/

Does diff work for you too? I like it better, but if it doesn't work, we can go back to using uname and cut.

Thanks, that diff works for me, too.

Two things I wonder about:

- when you terminate a comment line in NFO with \ the subsequent sprite is ignored. Is that intended (escaping the line break)?
- when you add colour codes (e.g. 8E) to action 08, nforenum complains with warning 144 about the use there, indicating that that is a mis-use of the colour codes. I don't see why they must not be used there...

1) Are you running the code through the C preprocessor? If so, then that is to blame, and not NFORenum; renum can't help you if CPP has already eaten the newline.
2) I went conservative there, obviously. I can make it more permissive pretty easily.

DaleStan wrote:1) Are you running the code through the C preprocessor? If so, then that is to blame, and not NFORenum; renum can't help you if CPP has already eaten the newline.
2) I went conservative there, obviously. I can make it more permissive pretty easily.

ad 1) Yes, I do. That then seems to be the cause, thanks.
ad 2) I would appreciate it as it's in the newgrfs I'm involved right now a warning which is not necessary as it also seems nicely supported by the programmes.

I've finally compiled nforenum myself. I noticed an odd thing in the Makefile: Is before the lines setting CFLAGS/CXXFLAGS, so changing CFLAGS in Makefile.local has no effect. You can argue that CFLAGS shouldn't be changed in Makefile.local but if that's the case they shouldn't be included in Makefile.local.sample either.

And my compliments about the config data format. It really shows how much information you can pack in only a few bytes

The following code is wrong, so the error is correct but not really helpful. "sound import sprites", how many is that?

Hmm...
That could be considered somewhat incorrect. Fixed in 2198.

nforenum r2198 has a compile warning (gcc 4.0.1 on mac): The attached diff should fix that, given indentation in the original source is right