Hardcoded values -> CFG

[Buggi]

Something that's bugged me all the vehicle information, etc. is hard coded and compiled into the EXE.

I don't see why this information can be taken out and placed into a CFG file. This would allow tweaking the values and easily expanding the set later on.

Thoughts?

[Sacro]

The default vehicles are hardcoded, however newgrf does support value tweaking. The only problem at the moment is that OTTD doesnt fully support newgrf, though that is being worked on all the time.

[Buggi]

Right now I'm just thinking take the existing information and extract it to CFG files.

I would suggest XML but I don't want to be flamed.

[DaleStan]

Why add a new format when there's already a perfectly good[0] format for changing both the vehicle properties and the vehicle sprites. There is no good way of extracting the built-in info, but is that really what you want?

XML is supposedly being used for the 32bbp graphics, but I remain unconvinced that XML can do everything that NFO can.

[0] Yes, I know what some of you think of NFO. Go away. I still maintain that NFO is human-readable. I can read it, and I'm a human, therefore it's human-readable.
And, unlike these 32bpp graphics, there are publicly available versions of OTTD that can read newgrf.

[bobingabout]

i can usually read and decode all kinda of code, and NFO boggles the hell out of my mind.

i think something a bit more user friendly, like using words instead of numbers would be a far better idea, after all, the NFO code was a bodge in the graphics format. however, I'm not sure about XML...

[WWTBAM]

but if someone wanted to they could write a nfo editor that used words instead of numbers shurely.

[peter1138]

Like GRFMaker?

[WWTBAM]

yes but more on the lines of something that displayed words to represent the numbers and output it as an nfo file.

[Brianetta]

One day there'll be a simply Grf maker that I can use on Linux. I'd write one, but I saw an NFO file once and the word "fugly" popped into my head, and I totally lost the motivation to learn it.

[bobingabout]

still can't beat CAOS.

would need some kind of modification to make it work in OTTD, but imo, we are best off coming up with our own system for the OTTD 32bpp.

note, this is a HTML document, but the forums won't let me upoad 1, so, if you use IE, you are ok, but firefox will load it as a text document, instead of a web page, so, you'll need to download it, rename it to .html, then open it.

[DaleStan]

i can usually read and decode all kinda of code, and NFO boggles the hell out of my mind.

Yes. It's an exercise in a rather unusual way of thinking. I find it an interesting and often fun exercise, but then again, it's generally agreed that I'm moderately insane.

i think something a bit more user friendly, like using words instead of numbers...

yes but more on the lines of something that displayed words to represent the numbers

I saw an NFO file once and the word "fugly" popped into my head

Do I detect a recurring theme here?

The output from grfcodec is difficult to use regardless of whether you use -t (for "no quoted strings") or not; either strings come out as 42 65 6c 6c 20 56 2d 32 32 20 4f 73 70 72 65 79[0], or some adjacent bytes come out as "Ð&"[1]. I have been known to decode the same file twice, once with -t and once without, and then manually merge the two as necessary.

For those of you who don't read the NFORenum thread, I'm working on making NFORenum intelligent enough convert between strings and hex, as appropriate. There are also some format extensions I have bouncing around in my head (backslash-escaping in quoted strings[3], ability to specify words and dwords big endian, instead of little, specifying some things in decimal, ...)
If you've got other ideas on how to make NFO more readable[2], feel free to suggest them. The same applies to any opinions may you have on how the extensions above should be implemented.

Brianetta, NFORenum should compile and run on Linux systems. I do not distribute a makefile because I have no make-fu, not because there's masses of Windows-specific code. (There is a little, but it's all guarded with #ifdef _WIN32) If you're interested, I'll try to work out a sane makefile.

[0] Instead of "Bell V-22 Osprey"
[1] Instead of D0 26 (decimal 9936, which could, for example, be an introduction date of around 1947) Or the 26 could be a property number, which makes reading that even more fun.
[2] Preferably changes that could be automatically applied to the canon format; I don't like LST because it is not backformable from a GRF, and I don't want NFORenum to introduce another format with the same problem.
[3] The only three I currently have in mind are \n, \", and \\. Again, suggestions are always welcome.

[Buggi]

Holy off-topic.

I mean an ALL TEXT format. Decoding HEX is something I program util apps for.

[DaleStan]

Decoding HEX is something I program util apps for.

So, why don't you? Feel free to ask me anything about the NFO format, or the NFORenum internals; NFORenum's poorly commented, but it checks nearly every single byte, and knows what most of them mean.

[Buggi]

Decoding hex byte-for-byte is equivalent to deciphering machine code.

I think in this nice object oriented world we can think on a higher plane and use the nice features presented to us. That's all I ask. Leave the byte-saving world in the past where it belongs and embrase your multi-gig tower like it was a member of the family.

I say lets splurge a little! Lets not just use "T" lets use "TRAIN"!! *gasp*

[DaleStan]

Decoding hex byte-for-byte is equivalent to deciphering machine code.

If you s/hex\ byte-for-byte/NFO/, which is, I believe, what you mean, that's only fair if the machine code in question has:
1) no push or pop instructions, (except the implicit push/pop in call/ret)
2) a call instruction that does not change the ret destination, and cannot be used recursively.
3) highly restricted jmp instructions[0]:
4a) pointers that may only exist as literals OR
4b) an absurdly large number of registers[1], and no memory or pointers.
5) mostly read only memory/registers (depending on which idiom you chose in #4)

[0] There are two classes of jmp instructions:
The not-entirely-a-jmp, which executes most of the instructions it pretends to skip (including most HCFs generated by true-jmps), and the true-jmp, which turns most of the instructions it skips into HCFs, and hence is rarely used.

[1] Depending on context, either:
1) 96 dword registers, 16 registers containing arrays of 256 dwords, and 0 to 128 bytes of memory that can be addressed (with literal pointers only) as bytes, words, or dwords (all read-only, bar an implicit write to one of the 96 dword registers done by the call instruction) OR
2) 128 read-write dword registers and 128 dword registers of which some are read-only, some are write-only, and some are read-write.

[Buggi]

...

Do you realize how cryptic that response was dude? I mean, holy MOLY! You actually used a JMP in your reference to JMP statements!! [0]!??!

DUDE!

Do you dream in HEX? Do you look up at the sky and see #0000FF ??



Seriously, let's land this plane and take us back to the topic, which is making it so more then 3 people on the Earth are able to read the data-format the game uses. Nothing personal, I admire your abilities, even used some HEX deciphering to crack SimCity 4, but there's a time and place for some low level stuff, and I don't think it's in this instance.

[DaleStan]

Do you realize how cryptic that response was dude? I mean, holy MOLY! You actually used a JMP in your reference to JMP statements!! [0]!??!

I'm talking to a programmer. When talking to a programmer, I expect that I can get away with more technobabble than I could if talking to non-programmer.

And isn't that a call, not a jmp?

let's land this plane and take us back to the topic, which is making it so more then 3 people on the Earth are able to read the data-format the game uses.

Off the top of my head, and in alphabetical order: 459, Csaba, DaleStan, George, gl2, Lakie, mb, Mek, minime, Oskar, Oracle, OzTransLtd, Patchman, peter1138, and Szappy.
Possibly others; I've left of several who use GRFMaker but may also know NFO. There is some disagreement here; some say that you have to know NFO to use GRFMaker; others say that you do not. I can't speak from experience; GRFMaker is a point-and-click programming tool, and I tend to shun them on the grounds that they usually slow me down, not speed me up.
</OT>

Do you dream in HEX?

Not quite. And I do still have pull out a calculator for a lot of the decimal-to-hex conversions (the main reason I want decimal values in NFOs) But I do think "Tile shape check. That's callback 2F." No amount of insistence that 2F is a hex number will make it be anything other than callback 2F. Similar things apply to variable 0C (the callback control variable), and action F. Except I can't come with a better alternate name for action F than "The action that defines new town names."

You're perfectly welcome to design a new "more readable" format, and I'm willing to "help" with "OK, now how do you do $FOO? $BAR?" questions. I probably won't consider it "more readable", though; I've been programming in NFO for something around a year and a half now, and am not really interested in learning a new language.

... Oh, right. There's something else I need to change: operation bytes to C operators (+, -, *, %, |, &, ^, &c.) (Oh, wait. Didn't I say </OT>?)

[bobingabout]

unfortunatly, 99% of OTTD users can't use GRF maker because it looks for your TTDP exe and upon failing to find that, thows a wobbler and quits. so, we are stuck with GRF codec, that only a handfull of people can understand. i can understand that the NFO is written in the language that TTDP reads, however, we humans are not TTDP nor OTTD, can't it be something a little simpler that you write in english, then the GRFCodec software converts it to the format TTDP+OTTD read? yes, this is the purpose of GRFMaker, but like i've said, I've pointed out the fact that it looks for TTDP, which makes the software a pile of crap, and a waste of diskspace on my computer.(actually, I think i might have another shot at it, this time installing TTD and TTDP just to try it, but many won't).

since this is OTTD, and OTTD is leaving the 8bit NewGRF universe and entering the 32bit(or 34 bit minimum(a 32bit base image with a 2 bit overlay) as i've pointed out, for the CC), so wouldn't it be better that a new format be used for OTTD(since there is no magical GRFMaker for OTTD) that people can actually understand. still some sort of language that you need to learn, but something a little easer to learn than lines upon lines of 2 digit numbers.(this information could then be fed into the graphics pre-processor(assuming we have 1, god forbit OTTD requiring thousands upon millions of PNG images, i'd refuse to use it because if i installed it on my USB hard drive, my Portable DivX player would be overloaded by the massive FAT table and instead of taking a min to read, would take several hours.) simular to GRFCodec to be encoded to a more NewGRF format(whatever we are going to call our 32bit GRFs.)...

[Darkvater]

.(this information could then be fed into the graphics pre-processor(assuming we have 1, god forbit OTTD requiring thousands upon millions of PNG images, i'd refuse to use it because if i installed it on my USB hard drive, my Portable DivX player would be overloaded by the massive FAT table and instead of taking a min to read, would take several hours.) simular to GRFCodec to be encoded to a more NewGRF format(whatever we are going to call our 32bit GRFs.)...

Even if OTTD is going to have a zillion PNG files (just as almost all games have nowadays in one form or another), it will be packed into a single file. Like pak files in DOOM or mpq files of Warcraft.

I do agree that the NFO is unreadable. Not totally unreadable but you need to spend a lot of time on it to understand what is going on without have a split-screen next it of the manual (that's how I read it). GRFMaker would be a good choice for all users who are not so proficient at hacking away on the 'HEX-madness'. However why it needs TTDPatch is beyond me, it has "nothing" to do with it (the executable it is).
Because if it works for all there doesn't really need to be designed a new grf format. Just have to make sure it is multi-platform

[bobingabout]

Even if OTTD is going to have a zillion PNG files (just as almost all games have nowadays in one form or another), it will be packed into a single file. Like pak files in DOOM or mpq files of Warcraft.

glad to hear it.

don't forget this info:
http://www.tt-forums.net/viewtopic.php?t=22024
note, the process described in this can be done while either compressing, or while loading the compressed files, but the general idea is that it cuts down processing power reuired while rendering the images.