Moderator: OpenTTD Developers
We have been discussing a solution for the scenario problem for a while already. We considered a new format unhindered by NewGRF problems as the best option and after many discussions about the details you can check the first draft of the spec here:
I'm interested in getting more feedback for the extended heightmap format, before deciding on a final format and starting implementation. The industries issue has been deliberately left behind because they are completely NewGRF dependent. We have some vague ideas about the best way to create industry definitions that don't rely on NewGRF data, but because of their difficulty IMO it's best to let them rest until all other parts of the extended heightmap format have been decided and implemented.
Finally, note that this thread is NOT about NewGRFs, but about creating scenarios in a way that are independent from them. If you want to discuss about changing NewGRFs ingame, please take the discussion here.
You might also need to store the road bits in order to handle more complicated things at hilly terrain correctly. Also two parallell flat roads may not be intended to be connected at every tile. However, if the road bits are not stored, you have to connect all road tiles that are adjacent as you don't have any information on when to connect and when to not.
Great to see some proposal though to get beyond discussions.
And allow me to open the can of worms called 'roadtypes'...
I see the benefit of the png format (edit a scenario in a graphics editor), but I'm a bit surprized as to why it's chosen over a simple text array of coordinates with different properties attached to them.
But then again, I can only applaud the effort, as the game would really benefit from a decent scenario format
That way you can combine the height, water and canal layers. This spares some files.
Sure, but it breaks human readability/editability.Expresso wrote:To my collection, png files can be 32bpp. So, why not take a look at what openttd does for tiles and do the same a bit scaled down to the png image.
That way you can combine the height, water and canal layers. This spares some files.
A decent bitmap editor has overlays nowadays, so you can stack the various files into overlays, and edit them manually and still understand what you are doing (at least somewhat).
In previous discussions we achieved the conclusion of assigning a different colour to each roadbit combination. I have corrected it to reflect all of those combinations. My first idea to deal with oneway-ness is to add even more colours, but I'm going to delay that in case someone else has a better idea.
Foobar: The first idea was to use a text array for roads, but it would be the only game data requiring one. Since I don't think that a single layer deserves a specific format and we have plenty of colours available in paletted PNG files anyways, IMO a PNG image is enough for them.
Roadtypes are a big can of worms indeed, but smaller than industries. Ideally, each road type would get its own layer (except those that are company-owned only). The road layer would get an extra property (or properties) in its metadata section, indicating things that would help in identificating a similar roadtype to use for that layer. If no roadtype can be found, that layer would be ignored. As I mentioned in the industry case, anything NewGRF related is hellish, but since we plan to cross that bridge for industries in the future anyways, a similar solution could be adapted for roadtypes. I think that probably these solutions will require additions to the NewGRF format itself.
This reminds me that I forgot to add a "version" metadata property for extended heightmaps. It would work in a similar way than OpenTTD savegame version. Good idea or not?
Maybe it's possible to use different colours/colour indexes to encode different types of road bits in the file?
Certainly a good idea. It would be weird not to, as I suppose any other game file has a version number.Terkhen wrote:This reminds me that I forgot to add a "version" metadata property for extended heightmaps. It would work in a similar way than OpenTTD savegame version. Good idea or not?
One of the things I'm missing at the moment is specifying a date at which something is created (power stations did not exist before 1878), or even removed from the map. Whilst I understand you do not want to talk about GRFs (which I understand) I hope your suggestion makes it possible to define 'possible future founding locations' when some more love is given to the scenario system.
That's out-of-scope. You can and need to write a game script for that end. The scenario format is about the state of the game on game start.broodje wrote:One of the things I'm missing at the moment is specifying a date at which something is created (power stations did not exist before 1878), or even removed from the map. Whilst I understand you do not want to talk about GRFs (which I understand) I hope your suggestion makes it possible to define 'possible future founding locations' when some more love is given to the scenario system.
The other somewhat big addition is the addition of the max_speed property to bridges. This represents our planned approach for NewGRF changes; guessing from values, either real properties or some kind of labels.
How do trams work, though? Another road layer? Three sets of colours for [road]/[road+tram]/[tram only]? Did I just miss that bit of the wiki page?
Linux user (XMonad DWM/KDE, Arch), IRC obsessive and rail enthusiast. No longer building robots; now I ring church bells.
Author of an incredibly boring stickied post about NewGRFs.
You can't have town-owned trams or trams without an owner; they only appear as company property. Because of that, they will never appear in the new format.
I respectfully disagree with that. As far as I know you can't set any location for (for example) a power station to appear around 1950. You can make an existing power station disappear though. But apart for the abilities of a game script... Why does it have to be so complicated .planetmaker wrote: That's out-of-scope. You can and need to write a game script for that end. The scenario format is about the state of the game on game start.
The scenario format as discussed here describes the map state. The evolution of the game state is defined by OpenTTD itself, NewGRFs chosen, game script and AI and player input. Simple as that. You likely can recommend a game script for a map in the scenario, even write one dedicated to a particular map.broodje wrote:I respectfully disagree with that. As far as I know you can't set any location for (for example) a power station to appear around 1950. You can make an existing power station disappear though. But apart for the abilities of a game script... Why does it have to be so complicated .planetmaker wrote: That's out-of-scope. You can and need to write a game script for that end. The scenario format is about the state of the game on game start.
Since you're using an indexed palette, wouldn't be more useful to give different meanings to different palette entries rather than using 9 pixels for each tile?
So for instance:
- index 0: no road on tile
- index 1: x axis full road
- index 2: y axis full road
- index 3-9: one-way and no-entry roads
- index 10-13: T-junctions
- index 14: full junction
- and just continue if I missed something
Or use the colour index as a bitmask:
- 00000001: top right halftile
- 00000010: top left halftile
- 00000100: bottom right halftile
- 00001000: bottom left halftile
- 00010000: oneway towards north
- 00100000: oneway towards south
- 00110000: no-entry
Simply add the values and that gives the colour index number to be used. Obviously some combinations do not make sense, these can be interpreted as "no road".
The actual colours of the palette entries do not matter, so one could use a palette with all pink colours that is useless outside the game, or some more decent colours that are usable in a graphics editor. I don't think this format is less editable outside of the game than the 9-pixel format.
You could even put road tunnels and bridges in the same file.
And using this method of indices, you could also combine the water, canal and aquaduct layers into one.
the setting "min_desired_height" is a misnomer. i got the totally wrong impression from the name. it should be renamed to "desired_min_height".
furthermore, i think you should prepare support for more height levels, as i expect that to be included sooner or later. a possibility for that is to turn "desired_min/max_height" into a mapping like "flat:6,hilly:10,mountaneous:15" [and clamp all larger values to 15 for now]
Keep in mind that this scenario format is not only about loading and saving it with OpenTTD. The most common usecase of todays heightmaps is reallife-data generated using various tools. What tool do you expect to easily generate colour codes for road tiles? Using multiple pixels is a lot easier to put into a converter. (if you even need a converted, maybe you can just use the raw image and it will work reasonably well)
@Eddi: The format is well prepared for any number of heightlevels (< 256). That's what "max_height" is meant for.
In this scenario format you have to distinguish scaleable and not-scaleable information. You can scale a heightmap in height, but you cannot do that when roads or canals are involved. The "desired_height" properties (if I got this right) are fixed if the scenario is not scaleable in total, and are only recommendations if the scenario is scaleable.
So this format even allows you to use the same scenario using different max-height levels if all layers are scaleable.
I don't remember seeing one.
Zuu may want it ( http://www.tt-forums.net/viewtopic.php?f=32&t=61151 )
and then i possibly didn't understand the use of max_height and desired_max_height... that needs more clarification.
Users browsing this forum: Google Adsense [Bot] and 1 guest