Transport Tycoon Forums

Not entirely off topic, this still applies; 2v.dat has had variable 46 (*checks*) since it entered version control.

It would obviously be easier to just allow any user-supplied value in addition to the known ones, but reading a relatively-static-format data file would allow GRFMaker to be stricter without requiring immediate updating of the executable.

AndersI wrote:But it's not very complicated to code with variable 0A in GrfMaker, adding a comment before each of the lines (make the comment appear in the NFO), produce the NFO, open Notepad, locate the comments and change 0A to 46 in the next line, finally create the GRF with grfcodec.

But that'd result in me having to manually change the NFO everytime I encode the GRF after a smallish update...

OK, it's more complicated than having a GrfMaker that could do it right now, but we don't.

Yeah, I guess I'll wait with those animated sprites till the rest of the set is coded, and then consider again. Thanks for your help so far

DaleStan wrote:Not entirely off topic, this still applies; 2v.dat has had variable 46 (*checks*) since it entered version control.

Where is it? I don't see any 2v.dat when browsing svn.ttdpatch.net with TortoiseSVN. Have I mangled my settings to hide it?

AndersI wrote:

DaleStan wrote:Not entirely off topic, this still applies; 2v.dat has had variable 46 (*checks*) since it entered version control.

Where is it? I don't see any 2v.dat when browsing svn.ttdpatch.net with TortoiseSVN. Have I mangled my settings to hide it?

Well, it's kinda there. It entered version control in that the file that contains its data (data.cpp) entered version control. The file itself (which is generated by NFORenum) can be provided. Sorry for the misleading clues.

It sounds like you might be interested, though that may change when you see what is/isn't found in 2v.dat.
Anyway, the format of 2v.dat is:
- The byte 0D. (If not 0D, the format below does not apply.)
- Any single byte. (Larger values mean newer data. This byte is unsigned, but the distinction has not yet been significant.)
- A byte indicating the number features for which this file contains data.
- A byte indicating the maximum valid value for the <operation> in advanced variational action 2s.
- A string of byte pairs <varible><width> for each global variable. Exception: 60+x variables have byte triples (<variable><width><maxparam>) instead. This is terminated by "FF F0".
- For each feature: (Repeat reading this at most $THIRD_BYTE times. Feature 08 is co-opted for town variables.)
- - A byte indicating the feature for 82/86/8A varactions on this feature (ie for feature 09 (indu tiles) this byte is 0A (industries)
- - A string of byte-pairs/byte-triples, as for the global variables. Terminator is "FF F0" or "<First invalid 80+x variable> 80" (e.g. For canals, this is 84 80, and for industry tiles, with no 80+x variables, this is "80 80".)
The high bit of <width> is always set, for hysterical raisins. The low nibble contains a value 0..4, indicating 0..4 bytes of useful data.

This is the second most complicated data file, by the way. Only 0.dat is worse. If you're familiar with C/C++ (And have a sturdy sanity. My code can be ... interesting, to put it in terms that can be repeated in polite company.) searching for "myfopen(name)" will point you to the reading code for name.dat. _datname is the data that file contains. GetCheckFOO means read a FOO, little endian, and ensure that you didn't hit end-of-file in the process.

DaleStan wrote:The file itself (which is generated by NFORenum) can be provided. Sorry for the misleading clues.

No problem. So, it was here on my own hard disk all the time... And binary, too

It sounds like you might be interested, though that may change when you see what is/isn't found in 2v.dat.
Anyway, the format of 2v.dat is:
...

Ugh! Do you have a formal grammar for that I see that this isn't a little weekend (evenings) project, so it will have to wait until February or some such (forever?).

The idea is sound, though, to read such things from external files instead of hard coding. Although there's the little problem of a readable (translatable) description - maybe it's better to parse the Wiki...

AndersI wrote:Ugh! Do you have a formal grammar for that

Ugh indeed. And no, I don't[0]. It was designed in the same way that NFO was designed. Write the parser and then write data that matches what the parser expects to read. Rewrite the parser when it needs to be fed more/different data, and then add the new data.
If that one worries you, then I probably shouldn't mention the format of 0.dat. (Which contains at least one blatant "The parser doesn't like that, so I'll do this, rather than fix the parser.") OTOH, 0 does contain some formatting hints for the beautifier, which might be helpful to GRFMaker too.

Except for langs.dat, none of the files contain data that is supposed to be any more human readable than NFO.

[0]Let's see ... does something like this parse?
(AIUI, BNF (after which this might be vaguely modeled) can't do counted repeats, and recursion requires extra though here, so I've used * as the repetition operator.) The first instance of varlist contains variables accessible by all features; the other 16 (currently) contain variables that are specific to their corresponding feature. All non-80+x variables are non-existent unless otherwise specified. maxparam is unsigned; the various landscape-access vars have a max of FF, not 7F.

And I lied in my previous post. The third byte is the maximum feature, not the count of features. I've corrected that here.

I think I've grokked this now, assuming that 'var60' is anything 60-7f and 'var80' is anything 80-FE. The two remaining questions are:

What is the significance of the width 'C4' (red in the picture)? Is it a width of C4-80 = 44 (68 dec) or something completely different?
Is there any significance in the actual values for 'byte' (violet in the picture)?
(the terminators are green, please confirm or refute my reading)

C4: Ah. I'd forgotten that. Bit 6 of <width> is set if NFORenum is not to complain if the variable is anded with 0. (This also applies to var 7E.)

<byte> Each feature's <byte> entry is the effective feature for 82/86/8A varactions, when applicable. Since "feature" 08 is co-opted for town variables, it's not relevant there, but its presence makes my reader much simpler, and therefore me much happier.

The terminators look right to me; they're not generally valid as anything else, and each of the following <byte>s is correct.

<var80> is actually 80-FF, which may make things more interesting. A terminator of FF 80 would indicate a 127-byte structure (vars 80..FE), while FF F0 indicates a 128-byte structure (vars 80..FF).