NFORenum v3.4.6 released (NFO renumberer and linter)

[DaleStan]

I went and forgot train variable 48, so here it is:

(234 bytes -> 236 bytes)

[DaleStan]

Code: Select all

VarAction2Houses (hist) 		 Csaboka  	 Added var. 62 
VarAction2Industr... (hist) 	Csaboka  	 Added changes of var 60 
Action0Cargos (hist) 			 Csaboka  	 Added properties 18, 19 and 1a 
Callbacks (hist v59)  	 	  Csaboka  	 Added callback 38 and 39

Looks like Csaba's done, at least for a little while, so:

(Sizes: 0.dat: 408 -> 411, 2v.dat: 234/236 -> 239, callbacks.dat: 58 -> 60)

[DaleStan]

"at least for a little while"
This time, it's callback 3A.

Size: 58/60-> 61 bytes.

[DaleStan]

I found another hang, added in 2.6.4.
I think, if you give it long enough, it'll get past it and go on its way (just subtract 2 from 0xFFFFFFFE until you get down to 0), but that takes a little while, and I'm not that patient. It may also have other undesirable side-effects. I don't care to investigate.

v2.8.0 to v2.8.1
- Up to date with 2.0.1 alpha 72 (all hotfix)
- - Train variable 48 (still undocumented)
- - House variable 62
- - Industry tile variable 60 (widened to 4 bytes)
- - Cargo properties 19..1A
- - Callbacks 38..3A
- (bugfix) Fixed hang when outputting a wider-than-specified value.

[George]

I have some problems:

Code: Select all

//!!Warning (144): Offset 50: Control character 0D should not be used in this string.
//!!Warning (144): Offset 103: Control character 0D should not be used in this string.
  187 * 151	 04 0B 81 01 E0 D0 47 6C 61 73 73 20 69 73 20 6E 6F 74 20 72 65 71 75 69 72 65 64 2C 20 62 75 74
	 20 62 6F 6F 73 74 73 20 70 72 6F 64 75 63 74 69 6F 6E 0D 54 72 61 6E 73 70 6F 72 74 20 35 30 25
	 20 61 6E 64 20 73 74 6F 72 65 20 63 61 72 67 6F 20 74 6F 20 69 6E 63 72 65 61 73 65 20 70 72 6F
	 64 75 63 74 69 6F 6E 0D 4D 61 78 20 70 72 6F 64 75 63 74 69 6F 6E 20 31 30 36 35 36 20 28 67 6C
	 61 73 73 29 20 2F 20 38 33 35 32 20 28 6E 6F 20 67 6C 61 73 73 29 00

0A does not work as intended, it does not break the line. 0D does. A patch or NFO renum and wiki should be changed

Code: Select all

//!!Fatal Error (47): Offset 82: Invalid property 22.
  196 * 84	 00 0A 1A 01 16 08 16 09 16 0B 04 0C 33 48 0D 35 48 0E 39 48 0F A0 10 05 FF 11 13 12 FF 00 12 03
	 13 00 14 0A 15 01 01 16 83 93 FF 17 02 18 01 19 D0 1A 00 00 00 00 1B 2D 48 1C 00 01 00 00 1D F0
	 00 00 00 1E 00 00 00 00 1F 5F DC 20 FF FF FF FF 21 AC 22 01

It is the callback flag, second byte. And it works

Code: Select all

//!!Warning (144): Offset 6: Control character 90 should not be used in this string.
  685 * 33	 04 0B 81 01 F0 D0 90 56 65 72 79 20 6C 6F 77 20 70 72 6F 64 75 63 74 69 6F 6E 20 6C 65 76 65 6C 00

And how can I change the text colour for industry window?

[DaleStan]

Code: Select all

//!!Warning (144): Offset 50: Control character 0D should not be used in this string.
//!!Warning (144): Offset 103: Control character 0D should not be used in this string.
  187 * 151	 04 0B 81 01 E0 D0 //...

0A does not work as intended, it does not break the line. 0D does.

Code: Select all

//!!Warning (144): Offset 6: Control character 90 should not be used in this string.
  685 * 33	 04 0B 81 01 F0 D0 //...

And how can I change the text colour for industry window?

Sorry; my TextID checker and string parsers are still rather naive. Those messages really should read "Warning: This feature has no use for class D000 texts." AFAICT, there's no reason to code a D0xx text for cargos at all. The only cargo callback is 39, which doesn't return a textID, and, unless I'm missing something, everything else text-related is a property, requiring a DCxx ID.
Both of those look to me like newindustry strings, not newcargo strings. (In my book, the feature of the string should match the feature of: the string that includes it, the action 0 that references it, or the action 2 that returns it.) Industry texts accept color codes, and, with this new 4.dat, they accept line breaks too.

If you really must have those texts be feature 0B, and not 0A, and can give a decent reason, I'll update 4.dat again.
You may also open this new 4.dat in any hex editor, and set bits 3 and 4 in the second-to-last byte.

Thanks for posting text strings instead of hex codes, BTW.

[Industry prop 22]

Right you are. Don't know how that one slipped by. Fixed.

[George]

Code: Select all

//!!Warning (144): Offset 50: Control character 0D should not be used in this string.
//!!Warning (144): Offset 103: Control character 0D should not be used in this string.
  187 * 151	 04 0B 81 01 E0 D0 //...

0A does not work as intended, it does not break the line. 0D does.

Code: Select all

//!!Warning (144): Offset 6: Control character 90 should not be used in this string.
  685 * 33	 04 0B 81 01 F0 D0 //...

And how can I change the text colour for industry window?

Sorry; my TextID checker and string parsers are still rather naive. Those messages really should read "Warning: This feature has no use for class D000 texts." AFAICT, there's no reason to code a D0xx text for cargos at all.

Yes, that's why I always used 0B for that

The only cargo callback is 39, which doesn't return a textID, and, unless I'm missing something, everything else text-related is a property, requiring a DCxx ID.

Why?

Show additional text in industry fund window (38)
This callback allows you to display extra information in the industry fund window about your industry. The return value should be the number of a D0xx text to be displayed.

as I can see, it is D0

Both of those look to me like newindustry strings, not newcargo strings. (In my book, the feature of the string should match the feature of: the string that includes it, the action 0 that references it, or the action 2 that returns it.) Industry texts accept color codes, and, with this new 4.dat, they accept line breaks too.

in new grf ver 7, industry tiles would return D0xx text too, but NFOrenum reports //!!Error (43): Invalid feature byte.

If you really must have those texts be feature 0B, and not 0A,

Yes, not 0B. But for 09 we have the same problem. And for 09 I have a reson - reporting error "can't be build here ..." for tiles.

and can give a decent reason, I'll update 4.dat again.
You may also open this new 4.dat in any hex editor, and set bits 3 and 4 in the second-to-last byte.

I suppose that is not the right way

Thanks for posting text strings instead of hex codes, BTW.

Do you know perl? I'd like to suggest some changes to NFOrenum. (Please, write me a e-mail to discuss it)

[DaleStan]

AFAICT, there's no reason to code a D0xx text for cargos at all.

Yes, that's why I always used 0B for that :(

Huh? I'm not following.

The only cargo callback is 39, which doesn't return a textID, and, unless I'm missing something, everything else text-related is a property, requiring a DCxx ID.

Why?

Again, I'm not following. Why what?
Why do properties require DCxx IDs, not D0xx? Please tell me I don't have to answer that question.

Show additional text in industry fund window (38)
This callback allows you to display extra information in the industry fund window about your industry. The return value should be the number of a D0xx text to be displayed.

as I can see, it is D0

But isn't that for industries, not cargos?

in new grf ver 7, industry tiles would return D0xx text too, but NFOrenum reports //!!Error (43): Invalid feature byte.

Again, that's because I don't pay anywhere near enough attention when reading the updates to the callbacks page. It should be fixed now.

-------------------------------------------------------------------------------------

So, ... ummmm... Yeah. I kinda tried to renumber a grf file. That didn't work too well. So, now, unless you specify -f or --force, files that do not start with one of "/;#*", whitespace, or a digit do not get processed.

Changelog:
v2.8.1 to v2.8.2
- More a72 and GRFv7 updates:
- - Action 7 condition 0C
- - Allow action 4s for industry tiles
- - Allow line breaks in industry texts (hotfix)
- - Industry property 22 (hotfix)
- (bugfix) Actually add --real-sprites.
- Add check for "looks like an NFO file" (override with -f).
- (bugfix) Set EPARSE when encountering a file with a too-large version.

[George]

AFAICT, there's no reason to code a D0xx text for cargos at all.

Yes, that's why I always used 0B for that

Huh? I'm not following.

I did not understand the problem because it worked in game

The only cargo callback is 39, which doesn't return a textID, and, unless I'm missing something, everything else text-related is a property, requiring a DCxx ID.

Why?

Again, I'm not following. Why what?

Why do you say, that all require DC, I posted the wiki part, that states D0. But as I see, the problem happend because of using 0B instead of 0A

in new grf ver 7, industry tiles would return D0xx text too, but NFOrenum reports //!!Error (43): Invalid feature byte.

Again, that's because I don't pay anywhere near enough attention when reading the updates to the callbacks page. It should be fixed now.

Thank you

[DaleStan]

Some massive internal changes, and a few user-visible ones:

v2.8.2 to v2.8.3
- Beginnings of sprite-rewriting system. No new functionality yet, though.
- Changed "Length does not match ..." (#40) to contain more information.
- (bugfix) Reverted "(bugfix) Checks length of extended house/industry tile action2s before processing." from 2.4.8.
- (bugfix) Callback 30 is for industry tiles, not industries.
- Added check for action 8 before GRM action Ds.

As you can probably see from the first entry, I'm preparing for some big changes. I'll add a URL to this post and my .sig once I write the style guide that I intend to have NFOReum follow. At that point, I invite you to comment here. What's good, what's bad, what I'm missing, &c.
There may be multiple options; the more feedback I get, the more likely I am to give out more options.

EDIT: It's up. (And no, "pretty" is not something I do, in case that wasn't already obvious.)
George, I didn't exactly follow your suggestions; I prefer vertically terse code, and I consider "DM" XX XX to be the correct way to write a GRFid.

[George]

George, I didn't exactly follow your suggestions; I prefer vertically terse code,

Me too, unless it is wider, than a screen. Then I hate it, because I hate horisontal scroll. I suggest us to decide, that 112 chars is a max string width, wider strings should be split into several lines.

and I consider "DM" XX XX to be the correct way to write a GRFid.

I use "Meo" XX notation for my GRFIDs.

I also think that a prop should NOT be placed as left as string number, so instead of

Code: Select all

0*0 00 <feat> <num-info> <num-ids> <id>
<prop> ... 

I suggest to use

Code: Select all

0*0 00 <feat> <num-info> <num-ids> <id>
<tab><tab> <prop> ... 

If <num-ids> is greater than 1, <values> should be aligned.

I think they all should be aligned

Code: Select all

<prop1> <value1>           <value2>            <value3>  
<prop2> <value1(w)       > <value2(w)       >  <value3(w)       >   

Special case for industry prop 0A.

they should not be taken into account when aligned

Also I suggest to comment action 0 props

Code: Select all

<prop> <value[s]> // Speed is 160 km/h (100mph)

09 "__00" "__01" "__02" ...

Special case for the cargo translation table, if sixteen or fewer entries.

Strongly disagree. 16 entries is 112 chars, that makes the string even wider. 8 entries is ok

The following characters are never to be quoted: 00..1F, 22, 7B..A0, AA, AC, AD, AF, and B4..B8, unless part of a UTF-8 character sequence.

Not every editor supports it right. I suggest all 80-FF symbols be not quoted

Current problems: Comments in the middle of sprites, blank lines in the middle of sprites (?)

Blank lines should be removed
Comments inside a line should be coded into a comment before the line. Only the tool should add them automaticaly

Actions ... 2 ... are currently intended to be formatted with no linebreaks, and entirely in hex.

Action 2 is the most usefull place for parsing. I suggest to discuss them in details later, but they sould be parced as action 0 - one possible value on a row (commented if links to defined or pre-defined valuse, the number of line of coresponding action 2 if links to other action 2.

[minime]

George, I didn't exactly follow your suggestions; I prefer vertically terse code,

Me too, unless it is wider, than a screen. Then I hate it, because I hate horisontal scroll. I suggest us to decide, that 112 chars is a max string width, wider strings should be split into several lines.

Any particular reasoning behind the number 112? If anything it should be configurable, not everybody has the same screen or taste.
IMHO 80 would be a more reasonable default(if anything a little more common) - it's about the right for most code.
It should be easy to format the code in a way so it can be easily posted on a website or wiki - and there the width is often even more limited.

and I consider "DM" XX XX to be the correct way to write a GRFid.

I use "Meo" XX notation for my GRFIDs.

GRF ID...it's a convention to use the first two bytes for the creator's initials... The last two bytes should be numbers .... but generally it is best to follow the above guidelines.

I also think that a prop should NOT be placed as left as string number...

I agree with that. Dalestan, think of how you indent a block in C. Here the same logic would apply...

If <num-ids> is greater than 1, <values> should be aligned.

I think they all should be aligned

Code: Select all

<prop1> <value1>           <value2>            <value3>  
<prop2> <value1(w)       > <value2(w)       >  <value3(w)       >   

That's a waste of space (and pain when editing, imagine you start with all bytes and then add a word property - i guess that's what the tool will be for, but i don't like to have to depend on that), there's always the same number of them. At most an extra space in between, and even that would be a little overkill.

Also I suggest to comment action 0 props

Code: Select all

<prop> <value[s]> // Speed is 160 km/h (100mph)

That's redundant, the code says exactly that. Comments like this are in most cases counterproductive.
It may be useful to have a feature to do it on the side, but i can imagine a lot of the files blowing up to unmanageable sizes.

The following characters are never to be quoted: 00..1F, 22, 7B..A0, AA, AC, AD, AF, and B4..B8, unless part of a UTF-8 character sequence.

Not every editor supports it right. I suggest all 80-FF symbols be not quoted

That's gonna make it a real pain to read. Dalestan's idea is logical, those characters are the ones that cannot be displayed in the game without using UTF-8. The rest are fine (in fact I think a few in the 7B-A0 range are OK too). Making the text unreadable because of those few unable to get a proper text editor is a rather weak argument.

Blank lines should be removed

NO! Good chance they are there for a reason.

Comments inside a line should be coded into a comment before the line.

Same as above.

Only the tool should add them automaticaly.

Tool is a tool. Let the user be the one in control.

Actions ... 2 ... are currently intended to be formatted with no linebreaks, and entirely in hex.

I think variable action 2s may deserve some line breaking.
Action 2s for houses and industrial tiles could certainly use that.

---

Overall, I think the whole feature should be quite flexible and configurable. Otherwise you risk the chance that one unfortunately chosen setting will make the whole thing unuseable for some people.

One more thing that just came to my mind. I don't know if you addressed that, but it would be handy if the tool could repair some of the "retarded" literal strings that GRFCodec loves to produce (Like prefixing them with the literal value of the high byte of offset in action 4s).

[George]

George, I didn't exactly follow your suggestions; I prefer vertically terse code,

Me too, unless it is wider, than a screen. Then I hate it, because I hate horisontal scroll. I suggest us to decide, that 112 chars is a max string width, wider strings should be split into several lines.

Any particular reasoning behind the number 112? If anything it should be configurable, not everybody has the same screen or taste.

that is the size that GRFcodec uses to split hex strings

IMHO 80 would be a more reasonable default(if anything a little more common) - it's about the right for most code.
It should be easy to format the code in a way so it can be easily posted on a website or wiki - and there the width is often even more limited.

It would make the code higher. I use the screen wide of 120 symbols and it is rather handy, but it would not be a problem for me to specify it as 80 too.

and I consider "DM" XX XX to be the correct way to write a GRFid.

I use "Meo" XX notation for my GRFIDs.

GRF ID...it's a convention to use the first two bytes for the creator's initials... The last two bytes should be numbers .... but generally it is best to follow the above guidelines.

it is a DWORD. I can use anything I want except FF FF FF FF

If <num-ids> is greater than 1, <values> should be aligned.

I think they all should be aligned

Code: Select all

<prop1> <value1>           <value2>            <value3>  
<prop2> <value1(w)       > <value2(w)       >  <value3(w)       >   

That's a waste of space

it's a horisontal space

(and pain when editing, imagine you start with all bytes and then add a word property

I can use any space I want, the tool should realign as soon as I run it

- i guess that's what the tool will be for, but i don't like to have to depend on that), there's always the same number of them. At most an extra space in between, and even that would be a little overkill.

It will allow selecting vertical blocks for one ID and copying it to the other. If they are not verticaly aligned, you can't use copy-paste.

Also I suggest to comment action 0 props

Code: Select all

<prop> <value[s]> // Speed is 160 km/h (100mph)

That's redundant, the code says exactly that. Comments like this are in most cases counterproductive.

I have to remember all the properties when I read someones code? NO, I do not want a memory trainer, I want an easy to use tool

It may be useful to have a feature to do it on the side, but i can imagine a lot of the files blowing up to unmanageable sizes.

This should not be stored in the grf, it should be generated from the tool's data files

The following characters are never to be quoted: 00..1F, 22, 7B..A0, AA, AC, AD, AF, and B4..B8, unless part of a UTF-8 character sequence.

Not every editor supports it right. I suggest all 80-FF symbols be not quoted

That's gonna make it a real pain to read. Dalestan's idea is logical, those characters are the ones that cannot be displayed in the game without using UTF-8. The rest are fine (in fact I think a few in the 7B-A0 range are OK too). Making the text unreadable because of those few unable to get a proper text editor is a rather weak argument.

You suggest me to use other editor? I'd reather not use the tool. If it is possible, than it may be an option, but if not, it should support all possible editors.

Blank lines should be removed

NO! Good chance they are there for a reason.

What reason? Put an empty comment there

Code: Select all

// -

Comments inside a line should be coded into a comment before the line.

Same as above.

Unless we can store them inside lines, it would be the best sollution. When we could store them inside - they are Ok.

Only the tool should add them automaticaly.

Tool is a tool. Let the user be the one in control.

How? I do not want to spend lots of time to make it all myself. The tool would make it better and MUCH FASTER.

Overall, I think the whole feature should be quite flexible and configurable.

That is much to code. At first it could be less flexible and configurable, but start working. Later it can be improved

Otherwise you risk the chance that one unfortunately chosen setting will make the whole thing unuseable for some people.

That's why it is public topic

One more thing that just came to my mind. I don't know if you addressed that, but it would be handy if the tool could repair some of the "retarded" literal strings that GRFCodec loves to produce (Like prefixing them with the literal value of the high byte of offset in action 4s).

Exectly what I wrote

[DaleStan]

[GRFids]
I'm not entirely convinced its worthwhile providing multiple options here, except possibly all-hex and do-not-touch. Well, not quite do-not-touch. It *will* split the GRFid from the following field if the last character of the GRFid and the first character of the next field (either <name> (08) or another <GRFid> (0E)) are both quoted.
BTW: The reserved GRFids are all the FF XX XX XX ids, and 00 00 00 00.

[indentation]

Code: Select all

    0 * 0      00 <feat> <num-info> <num-ids> <id>
<prop> ... 
---versus---
    0 * 0     00 <feat> <num-info> <num-ids> <id>
<tab><tab> <prop> ... 

Note the code will really look more like ^that^ after formatting. I don't generally like leading space; it tends to make my line breaks earlier and hence my code vertically longer, but since this already has tons of line-breaks anyway I guess it doesn't matter so much.

[alignment]

Code: Select all

<prop1> <value1>           <value2>            <value3>  
<prop2> <value1(w)       > <value2(w)       >  <value3(w)       >   

I thought that's what I said. I'll have to figure out how to clarify that. I'm with George here, minime. I might also add a //!! 00<appropriate space>01 ... comment (with appropriate IDs, of course) for marking which column goes with which ID. Probably only label every 4 columns.

[prop 0A not be taken into account when aligning]
Indeed. Same for station prop 0E. And I skipped station prop 09, because I've never tried to read/write one. Is it worthwhile to beautify it beyond all-hex, one value per line?

[comment action 0 props]
Not particularly easy. And what of action 0s for multiple IDs? More likely would be just eg "//!! Speeds".

[Cargo translation table]
ObNit: 16 entries is 112 characters only if you count the carriage return too.
But how's "Break every 8 or 16, depending on requested width, but do not start unless it won't fit on a single line"? So, for a width of 112 it would break every 16 (because that (just barely) fits into 112 characters), but would move the table down to a new line once it hits about 13 entries.

[not quoting high-ASCII]
What editor are you using anyway, George, and what does it do to high-ASCII? If it tries to turn them into UTF-8 sequences, then just start each string that contains high-ASCII with a lowercase thorn (U+00DE: Þ) and let it UTF-8 encode, otherwise I suggest you get a new editor; both of the ones I've used deal with high-ASCII correctly. Shouldn't be too hard an option to add, but it WILL NOT be default. As minime pointed out, the various control and special characters are not quoted, hence they can't get encoded.

[Comments, blank lines in the middle of sprites]
I'm willing to pull blank lines, at least on the sprites that get beatified, but I'm not willing to pull comments unless they're comments that NFORenum added. (What if NFORenum doesn't add comments where you think it should?) Moving them a couple bytes towards the end of the sprite is thinkable, although not ideal. Three solutions present themselves:
1) No beautification of sprites with embedded comments.
2) Embedded comments force a line break, regardless of context.
3) Embedded comments force a line break, unless context calls for one within the following $SMALLNUM bytes (default 2 or 4 bytes).
Comments that NFORenum adds, if any, are ignored for the purposes of these checks. (Unless -p or its equivalents.)

[Action 2]
Grr... I have a standard 2 feature 07/09 style that I managed to completely forget about.

[The number 112 as width]
ObNit: grfcodec uses 32 bytes, not 112 characters.
And configurable it shall be. Probably set a max-width, and NFORenum will start trying to break ten characters before that, with max-width of 78 as default?

[fixing grfcodec strings-that-should-be-hex]
That is the major incentive for adding this feature. Beautifying the code is really just a side-effect.

[Flexiblility vs coding time]
Actually, the hard parts are as follows:
1) Handling comments properly.
2) Getting outputter working and obeying the requests of the beautifier.

The only configuration so far that's a outputter thing instead of a beautifier thing is the max-width, and it's no harder to make that variable.

[Other things]
I forgot that Action 7/D can contain GRFids/CargoLabels. When they exist, they should be quoted as discussed in action 8/0.

EDIT: new style up.
EDIT2: That's *lower*case thorn, Dale. U+00*D*E.

[DaleStan]

Changelog:
- Added industry variable 60.

[minime]

it is a DWORD. I can use anything I want except FF FF FF FF

Well, if you want to really nitpick, Wiki quotes it as an array of 4 bytes. But that's irrelevant, what I was pointing out to was the "it's a convention" bit. Then again, convention is not a standard - I was merely curious about what reason you may have to do it differently.

I have to remember all the properties when I read someones code? NO, I do not want a memory trainer, I want an easy to use tool

One of the guidelines for commenting code is not to comment the obvious. Anyone who's well versed in coding a grf will likely remember the meaning most of the values. Additionally, while you may desire to use the tool frequently to fix up the layout of your code, the times when you need to have the entire contents explained verbosely will be limited. Hence, I suggested to make it an optional feature, which you seem to have ignored in the answer above.

This should not be stored in the grf, it should be generated from the tool's data files

I don't see myself mentioning a GRF anywhere - I don't know what you're trying to argue there.
However, if for every property you add a comment that's maybe 4 times as large, the NFO's gonna gain some weight...
How often will you need all those automatic comments in there?

You suggest me to use other editor? I'd reather not use the tool. If it is possible, than it may be an option, but if not, it should support all possible editors.

You're putting words in my mouth. All i'm saying is that limiting the strings to 7bit character set is not a good idea - there's no legitimate reason why a string like "Pátek" should be quoted in any other way that the one I've shown. If someone needs (for whatever reason) to have it quoted differently, than sure, make that an option, but a default? No way.

What reason? Put an empty comment there

Code: Select all

// -

Why should I need to write more to do the same thing? Blank line is a blank line. Again, maybe an option.
Besides, that comment you show is definitely not empty . I do use things like that, but they usually signify a divider between two different sections - they bring attention compared to an empty line. A blank lines are for clarity, and thus removing existing ones could be counterproductive in a beautifier.

Only the tool should add them automaticaly.

Tool is a tool. Let the user be the one in control.

How? I do not want to spend lots of time to make it all myself. The tool would make it better and MUCH FASTER.

We're on a different wavelength here. I'm talking about the "only" part of your sentence, you about "automatically".

What I'm trying to say is that it should be the user, not the program, who does the deciding there. Especially if it's a tool that messes around with your code.

---

[The number 112 as width]
ObNit: grfcodec uses 32 bytes, not 112 characters.
And configurable it shall be. Probably set a max-width, and NFORenum will start trying to break ten characters before that, with max-width of 78 as default?

Sounds reasonable.

How do you plan to break long strings? Anywhere, or near spaces? How about newlines (0D) in strings, break after that too?

[DaleStan]

You're putting words in my mouth. All i'm saying is that limiting the strings to 7bit character set is not a good idea - there's no legitimate reason why a string like "Pátek" should be quoted in any other way than the one I've shown.

Actually, "ÞPátek" (byte sequence: C3 9E 50 C3 A1 74 65 6B) would also be acceptable, assuming your editor handles UTF-8 sequences correctly. NFORenum can handle UTF-8 sequences, as long as you don't encode the control characters, or expect it to convert between Latin-1 and UTF-8.

BTW: The lowercase thorn is U+00DE, not U+00FE. U+00FE is the uppercase thorn. Sorry about that. (and edited.)

How do you plan to break long strings? Anywhere, or near spaces?

I did miss that, didn't I? Added.
Basically, line breaks added due to line-length limits are added in the same way that grfcodec adds its line breaks. (And I do intend to use as much of grfcodec's code as possible to facilitate this.)

How about newlines (0D) in strings, break after that too?

That's in the action 4 section, see String #3. Since all strings (actions 4, 8, and B) are run through the same parser (and the beautifier is attached to the parser), they will all get the same treatment.

I've got a proposal for comments and blank lines up too.

[minime]

You're putting words in my mouth. All i'm saying is that limiting the strings to 7bit character set is not a good idea - there's no legitimate reason why a string like "Pátek" should be quoted in any other way than the one I've shown.

Actually, "ÞPátek" (byte sequence: C3 9E 50 C3 A1 74 65 6B) would also be acceptable, assuming your editor handles UTF-8 sequences correctly. NFORenum can handle UTF-8 sequences, as long as you don't encode the control characters, or expect it to convert between Latin-1 and UTF-8.

Yes, I do agree that the UTF-8 encoding would be correct too. But since we're not converting between character sets, and the two are not byte-equivalent, I didn't really consider that an alternative.

EDIT: Whoa, what's action FE?

[DaleStan]

EDIT: Whoa, what's action FE?

The action that was added after action FF. (That wasn't really the answer you wanted, was it?)

Have a look-see.

Officially, action FE is a binary import, but I call it action FE because it starts with an FE byte. I'm not sure if action FF has an official name. It's what you get when you decode a binary include with 0.9.6 or earlier.

[George]

[GRFids]
I'm not entirely convinced its worthwhile providing multiple options here, except possibly all-hex and do-not-touch. Well, not quite do-not-touch. It *will* split the GRFid from the following field if the last character of the GRFid and the first character of the next field (either <name> (08) or another <GRFid> (0E)) are both quoted.
BTW: The reserved GRFids are all the FF XX XX XX ids, and 00 00 00 00.

then I'd suggest XX XX XX XX style as an option and "YY" XX XX as default

[comment action 0 props]
Not particularly easy.

?

And what of action 0s for multiple IDs? More likely would be just eg "//!! Speeds".

I'd suggest speeds 11km/h, 15km/h, ...
These comments should be aligned as last columns

[Cargo translation table]
ObNit: 16 entries is 112 characters only if you count the carriage return too.

plus leading space

But how's "Break every 8 or 16, depending on requested width, but do not start unless it won't fit on a single line"? So, for a width of 112 it would break every 16 (because that (just barely)

it should mean 95 columns for text. for 16 screen width should be 129 chars

[not quoting high-ASCII]What editor are you using anyway, George, and what does it do to high-ASCII?

far in-build editor, transforms to "?" or relevant ASCII symbols. "á" would become "a".

If it tries to turn them into UTF-8 sequences, then just start each string that contains high-ASCII with a lowercase thorn (U+00DE: Þ) and let it UTF-8 encode, otherwise I suggest you get a new editor; both of the ones I've used deal with high-ASCII correctly. Shouldn't be too hard an option to add, but it WILL NOT be default. As minime pointed out, the various control and special characters are not quoted, hence they can't get encoded.

Ok not to do it a default

[Comments, blank lines in the middle of sprites]
I'm willing to pull blank lines, at least on the sprites that get beatified, but I'm not willing to pull comments unless they're comments that NFORenum added. (What if NFORenum doesn't add comments where you think it should?) Moving them a couple bytes towards the end of the sprite is thinkable, although not ideal. Three solutions present themselves:
1) No beautification of sprites with embedded comments.
2) Embedded comments force a line break, regardless of context.
3) Embedded comments force a line break, unless context calls for one within the following $SMALLNUM bytes (default 2 or 4 bytes).
Comments that NFORenum adds, if any, are ignored for the purposes of these checks. (Unless -p or its equivalents.)

why not to use the way I suggested? to move them to a special action C before the sprite?

[Action 2]
Grr... I have a standard 2 feature 07/09 style that I managed to completely forget about.

why not to use the style of action 0 for all actions 2 (the ones that do a check)?

[The number 112 as width]
ObNit: grfcodec uses 32 bytes, not 112 characters.
And configurable it shall be. Probably set a max-width, and NFORenum will start trying to break ten characters before that, with max-width of 78 as default?

If it would be possible to specify it as a param, it would be wonderful, but 80 is Ok too

exception - if action 0 defines many objects, aligned columns may not fit in line. In this case they should not be split

[Other things]
I forgot that Action 7/D can contain GRFids/CargoLabels. When they exist, they should be quoted as discussed in action 8/0.

Ok