Hardcoded values -> CFG

[DaleStan]

since not everyone can read this nfo thing...

And whose fault is that?
First on the list of people whose fault it is NOT would probably be Patchman; I've almost never seen such clear or complete documentation. Mine definitely doesn't even begin to compare.

I've offered to make NFORenum do bidirectional conversion between canon NFO and whatever you consider "readable" NFO, provided both NFO constructs and the "readable" form, but I must have missed your requests. Care to point me to them?

for me it looks like you guys dont get that some of us "normal" people just want to play

... a clone of a computer game that's over ten years old. I don't think that qualifies as "normal".

sitting there trying to learn reading something that can take forever...

FVO "forever" that more closely resembles couple months. IIRC, that's about how much time elapsed between my first read through the NFO specs, and the point when callbacks (the last bit to click) finally made sense to me. The vehicle action 0s made sense the first time through, so if that's all you want to do, maybe an hour or two to read the tutorial and that portion of the spec? Even if you only read while waiting for OTTD to compile, it shouldn't take you more than two or three days.

Oh, and please invest in a new keyboard. Your current one has a broken shift key and a sticky full stop ('.').

[cybersam]

well..
i see your points... and it looks to me like you dont want to understand that not everyone can learn it that easy even with that documentation
and i'm not blaming someone becouse he understands it...

i'm not sure if you understand what i mean but there are peoples that can learn things fast and there are other that cant learn it fast and others that need a lot of time to learn something

but anyway as i see here this whole conversation is going nowhere (as said before)


well does this attribute changing thing in the nfo work even with OTTD ?!...
if it does i'd like to test your NFORenum thingy its not that i'm not open to new things

but i still think its much easier if the attributes are stored in a configlike file...

[DaleStan]

well does this attribute changing thing in the nfo work even with OTTD

The word "try" pops into mind, but for most things, the answer is "Yes."

NFORenum doesn't do much in the readability department yet.
If you get 3.0.0p2, there's a beautifier[0], which is currently a glorified code reformatter, but its output remains valid NFO.

[0] Slightly buggy in the obeying-its-settings department though.

[cybersam]

hmmm i got that one...
i looked in to it...
and i must say...
this is kinda complicated...


it might be just me since its already late here (5:30 am)
well i'll have to look in to it again when i wake up...


cya ^-^

[bobingabout]

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.

yer, OTTD plans to have more than 8, or even 16 facings per sprite, it was either 32, 64, or something crazily inbetween, like 48... and then i think it also has different zoom levels(instead of resizing in real time, they want to avoid the blockyness of a pixel resize) and alternate graphics for seasons and day night... not all sprites need all of these, but i'd image most vehicles would consist of over 100 sprites, and something as simple as a tree(which includes life/build stages), could have over 20...

like i said before, OTTD's 32/34bpp will probably need a few of its own commands.

[peter1138]

Bobingabout, vehicle directions and seasonal variations are entirely a different matter. NFO already has the capability to do many different variations. How to specify more than 8 directions would need to be decided on, but that's probably far away at this point.

We would also need to extend it (or come up with a joint spec) to handle things like 20 tree growth stages, though.

Different zoom levels can be handled by the sprite cache -- i.e. the game still uses the same sprite IDs but picks the appropriate images based on zoom level.

[bobingabout]

actually, that was about 5 life stages in the 4 seasons, but atleast i got 1 point right

[DaleStan]

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.

And when Patchman and I disagree, do what Patchman says.

OTTD plans to have more than 8, or even 16 facings per sprite, it was either 32, 64, or something crazily inbetween, like 48

And that matters why? Until you get to 65536 sprites, the current action 1 format works just fine. Just increase the number of sprites as necessary. Depending on how you folks choose to do things, this could possibly be used for the various zoom levels too:

Code: Select all

0 * 0 01 00 01 FF YY XX // one train with 0xXXYY sprites
0 ** sprites/Name-Dir1-Zoom1-Sprite.png
0 ** sprites/Name-Dir1-Zoom1-Overlay.png
0 ** sprites/Name-Dir1-Zoom2-Sprite.png
0 ** sprites/Name-Dir1-Zoom2-Overlay.png
0 ** sprites/Name-Dir1-Zoom3-Sprite.png
0 ** sprites/Name-Dir1-Zoom3-Overlay.png
0 ** sprites/Name-Dir2-Zoom1-Sprite.png
0 ** sprites/Name-Dir2-Zoom1-Overlay.png
//...

If you can manage to overflow the extended byte there, even with that, I think it's probably time to rethink the number of sprites you really need. But if you really do need more space, just redefine that to be a doubly-extended byte; set the word to FF FF and read the value from the following doubleword, just the same as you set the byte to its maximum and read the value from the following word.

and alternate graphics for seasons and day night...

Variables 02 (current month) and 09 (date fraction) already exist.

Admittedly, TTDPatch doesn't have 1/2/3 support for trees yet, but that's been requested multiple times.
A decent proposal may (and I emphasize "may") cause newtrees to be implemented sooner than otherwise. As for the growth stages, you'll almost certainly get the tree's planting date; either as a byte of years since 1920 or a word of days since 1/1/1920, I'm not sure, but in either case, just subtract that from current date (available in both formats), and you've got your age.

Granted, you've found something that 34bpp OTTD wants and NFO doesn't have, but it's not 34 bpp specific. TTDPatch's artists have been asking for that at least as long as you have, if not longer. (See the Japan Set.)