Hardcoded values -> CFG

[DaleStan]

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.

It does what? Why?

Does just putting TTDPatch somewhere random work, or does it insist on finding proper registry entries and a TTD executable too? But still, it shouldn't.

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.

You're missing an important restriction: It can not possibly be better if you give up the power of those lines-upon-lines of two digit numbers in the process.

[bobingabout]

I'm talking for the new 32bpp stuff, and basicly, instead of numbers, its words that you can actually understand, so, i can't even give an example, because i don't know the language... but something like:

train 1
graphic 1
load graphics "train1"//train1##.png and train1##c.png where ## is 00 to however many angles there are...
maxspeed 200
tracktype 0//rails

just a little easier to understand than half a dozon numbers per line. and since i don't know the nfo language, i can't give a good example of what it might look like in words.

I'd prefer something like CAOS.
new: simp 2 21 6 "ball" 17 0 5000
attr 199
bhvr 35
aero 10
perm 60
accg 2
elas 90
fric 90
mvto 8513 515
setv ov61 10

its not important what that does. but if you look at the CAOS guide i posted, you can figure it out, and with the language being mainly words, its a lot easier to understand than NewGRF NFO

[Patchman]

It seems to me like there are really two options here:

1. Write a program that takes your "plain text" spec file and converts it to NFO, then use the already-(mostly-)working NFO support in OTTD and be done. [1]
2. Write a program that takes your "plain text" spec file and converts it to some other, yet-to-be-specified easily computer-readable format. Then start from scratch implementing this format (which for NFO took many, many months and won't be significantly faster no matter how nicely you design your new one), fixing bugs, redoing the specs because you find things you need to do that can't be done, restart coding yet again, fixing the limitations of specs. Deal with the headaches of supporting two incompatible formats internally (unless you want to drop support for all existing graphics). Repeat as necessary.

My point is, why not use a format that works, can do just about everything that needs to be done[2], that there are many people out there who know how it works, and that OTTD mostly supports already? Why bother making all the mistakes that TTDPatch made all over again in a new design?

I'm not saying NFO is perfect. It has warts, and some things aren't designed as cleverly or cleanly as they could've been (because it's a grown design that grew as artist's demands increased). However, it is very simple for doing simple things (you can make a new train with four or five lines of very simple "code". It can get very complex too, but only when complex things need to be done. You cannot remove the complexity without losing its power and sophistication. Any new design will need to be just as complex if it needs to be able to do what NFO can do[3].

If the hex-ness of NFO is the only thing that bothers you, then it's the only thing that needs fixing. This means either improving/fixing GRFMaker, or writing a "plain text"->NFO converter. A variation of the latter would need to be written even if you come up with your own format.

So why not NFO?

[1] Whether the graphics are 8bpp or 32bpp or 256bpp does not matter here. The way sprites are encoded in the file is irrelevant. NFO can work just as well no matter what type of sprites you have.
[2] And can relatively easily be extended to support new things.
[3] For example Locomotion has a very simple format. As a result it can only do simple things. No repainting of wagons after N years to show a new historical livery. No showing of dirt as vehicles get older. No random variations in colours. No seasonal cargo acceptance/production of industries. No sophisticated animation control. No sophisticated station designs. No simple support for trainsets, other than defining a new vehicle ID for each loco and each wagon in each train set. Etc...

[DaleStan]

Bobing, that format can be extended, with minimal difficulty, to (most of?) the rest of the properties, but, it appears, is only useful for a single set of graphics and for static properties.
NFO provides (among other things) variational graphics[0], random graphics, and callbacks (variational/random properties, essentially).

NFO, or text-to-NFO, has the very major advantage that it's been around, in one format or another, since at least 1.8.2a9 (30/Jul/2002, first instance of "action" in the changelog), possibly 1.7.1a7 (no date given, first instance of "grf" in the changelog). That's at least three and a half years (or more) of artists and coders requesting (and usually getting) new features.

[0] To go back to that "hardware" that NFO runs on: Variational support ranges from "eleven dword registers and one array register" to "26 dword registers, six array registers, and 222 bytes of memory" to "30 dword registers, three array registers, and 256 bytes of memory".

[peter1138]

GRFMaker doesn't require TTDPatch. It also works (mostly) under wine. It doesn't really help with making varaction 2s easier though

[Buggi]

I was under the misunderstanding that the new format rendered the main objects in the game in real time not sprite animations.

DOH

[Patchman]

That has nothing to do with anything. Even if that were the case you could still use the NFO format to assign graphics and stats to vehicles. Which was what this topic (that you started) was (is?) about. We weren't even talking about the graphics format at all, other than pointing out that it is irrelevant for this discussion.

[Buggi]

Man, that was harsh.

What's the estimated learning curve to learn the NFO format? Are there specs on it? Or just compiled notes over the years?

[Patchman]

http://wiki.ttdpatch.net/tiki-index.php ... phicsSpecs

Has the complete specs, several tutorials and other supporting documentation.

The learning curve can be rather gradual, depending on what you want to do. To define vehicle specs, it's quite easy; you only need to read action 8 and action 0. To define graphics, you also need actions 1/2/3/4 and we have a nice tutorial on how to do that.

It does not yet make any attempt to cater to non-TTD graphics (i.e. no 32bpp or the like),

[DaleStan]

It does not yet make any attempt to cater to non-TTD graphics (i.e. no 32bpp or the like),

But it would be relatively easy for OpenTTD to extend the Action 1 data block to also be allowed to contain other things (binary-includes of PNG files, for example). It hasn't yet, but that seems like the best way to do such things.

[Patchman]

Indeed. As far as TTDPatch is concerned, it doesn't really care what's in an action 1 block either, until it tries to display the sprites. So there wouldn't even need to be any magic markers or anything, the specs as they are would cover 32bpp PNG files just as well.

To make OTTD support 32bpp, you'd only need to modify the sprite loader to read PNG binary includes, I imagine. And then patch the display code to do the Right Thing depending on whether it's a good old 8bpp sprite or a fancy new 32bpp one.

[Buggi]

When I originally posted this thread I had something in mind that had nothing to do with graphics.

What I was thinking of specifically were all the vehicles. Right now they're all in a hard-coded array in a header file. I was thinking it would be nice to pull them out and put them in a CFG file similar to the game CFG file.

I'm actually not sure how we got so focused on NFO...

Oh well.

[Patchman]

Well, we got to NFO because it does just that. (Among many other things.)

Its "action 0" allows changing the stats of all vehicles (and other things).

[bobingabout]

I've got nothing against NFO, something that would work for me could be something that converts something more readable into NFO. and for OTTD 32bpp, maybe a few extra commands too, dunno what, but...

patchmans's first reply kinda sums it up nicely, but i think OTTD should have something that either reads this new script and converts it to nfo (or simular) internally, or an outside program that converts it to NFO.


on a side note, i can't find GRFMaker, can anyone link me to it? or where i can get it?

on another note, i played TTDP last night, without it crashing on me. and i liked what i saw. there are a lot of OTTD features that i missed(like dragging signals, and i thought it was inconveniant not having autocomplete...) in there though... but to experiance the UKRS with UKRS industries, and all the extra sounds was just brilliant.

[eis_os]

Actually the grf system could even support 32bpp realsprites and 8bit fallback ones.

Some samples of extra info which didn't get out of my dev lab. Because my current dev format is incompatible to TTDPatch:

http://www.tt-forums.net/files/obridge1glass_114.png
http://www.tt-forums.net/files/obridge1 ... am_181.png

Generally I can put atleast 32KByte data into a realsprite.

[DaleStan]

I've got nothing against NFO, something that would work for me could be something that converts something more readable into NFO.

I seem to be the only person working on an NFO-readability improver, which is probably a bad thing. As I've said before, I consider NFO readable in its current state, with a few exceptions, so unless you can say "The construct $FOO should be changed into the text $BAR", it probably won't happen.

I do have some thoughts, but they aren't going to happen until the beautifier gets finished.

on a side note, i can't find GRFMaker, can anyone link me to it? or where i can get it?

PM Szappy.

Oskar, I thought the limit was just under 64KB?

[DaleStan]

Join from another thread, where it's rather off-topic:

i don't think OTTD should stop support of newGRF, but i do think the 32bpp stuff might need a bit more of a kick than newGRF supports.

How would the graphical bit depth affect the "kick" of newgrf?

because its actually 34bits, because you require a 32bpp image and a 2bpp CC overlay, which means each sprite requires 2 seperate images.

Still not sure why you need to handle it any differently from the 8 bit graphics. I was under the impression that newgrf was fairly agnostic toward bit depth and graphics format.

As I believe has been said before, NFO is utterly graphics format agnostic. As long as the action 1/5/A data-blocks contain as many sprites (real or pseudo, it doesn't matter) as the controlling 1/5/A says the data block contains, the NFO is valid. TTDPatch, in its current state, would have no problems with 32bpp images (or any other data format or even some 3D mesh and texture format, as long as there are guards to ensure that TTDPatch never attempts to draw those sprites.

If you use the include-PNG system I previously suggested, just do something like

Code: Select all

0 * 0 01 00 01 10 // one train with sixteen sprites
0 ** sprites/Name-N-Sprite.png
0 ** sprites/Name-N-Overlay.png
0 ** sprites/Name-NE-Sprite.png
0 ** sprites/Name-NE-Overlay.png
0 ** sprites/Name-E-Sprite.png
0 ** sprites/Name-E-Overlay.png
0 ** sprites/Name-SE-Sprite.png
0 ** sprites/Name-SE-Overlay.png
0 ** sprites/Name-S-Sprite.png
0 ** sprites/Name-S-Overlay.png
0 ** sprites/Name-SW-Sprite.png
0 ** sprites/Name-SW-Overlay.png
0 ** sprites/Name-W-Sprite.png
0 ** sprites/Name-W-Overlay.png
0 ** sprites/Name-NW-Sprite.png
0 ** sprites/Name-NW-Overlay.png

and change Open to DTRT with included PNGs and to understand that when 32 bpp sprites are seen, it should expect that sprite order. (or pick a different order, if some other order works better.) TTDPatch will crash if it ever tries to draw one of these 32 bpp sprites, but that's because TTDPatch doesn't know what to do with them, not because it's an invalid NFO.

For some things, it might work to provide 24 sprites: eight 8bpp sprites, so TTDPatch is happy (I hope. I'm not certain that this will work), and then the above sixteen 32+2 bpp sprites. Then OTTD could use either, depending on which the user requests.

[Patchman]

For some things, it might work to provide 24 sprites: eight 8bpp sprites, so TTDPatch is happy (I hope. I'm not certain that this will work), and then the above sixteen 32+2 bpp sprites. Then OTTD could use either, depending on which the user requests.

Currently that would work, but I plan to define 16 directions to allow auto-reversing of engine heads without any var.action 2 code.

So for future-proofness I'd wrap the action 1 in an action 7 (or better 9?) check, executing the right one depending on whether it's loaded in 32-bpp-aware OTTD or not.

[cybersam]

well it looks like this conversation is going to no where...
he just asked a simple think like making attributes for vihicles and such in a file out side exe and out side grf...
since not everyone can read this nfo thing...

for me it looks like you guys dont get that some of us "normal" people just want to play and change the stuff easy and not sitting there trying to learn reading something that can take forever...
becouse some of them dont have the time... or just dont want to spent so much time to change some attributes...


for you guys it might be easy... but for us we need to recompile the exe everytime we want to change something... since that's a lot easier than with the nfo file (well that goes for me)...(i'm not even sure if that works yet)

[Patchman]

But you don't need to recompile the exe. That was the point of the thread. There already exists a working mechanism to change vehicle and other stats.

I've never used GRFMaker myself, but settings stats should be one of the easiest exercises in the book. Even without GRFMaker it's very easy, if you're not hexophobic.