TD8 proposal

[Gymnasiast]

Since OpenRCT2 now features a considerable number of new track pieces that TD6 cannot save, users are running into problems saving their track designs quite frequently. TD6 additionally requires a fake originalId and does not support the new split paths.

While there are plans for a new track format (NTDF) that would considerably expand the possibilities, e.g. also working as a way to create blueprints of scenery and other tile elements, better support for hacks, and more stuff like that, it hasn’t yet come to fruition and most likely won’t do so for some time to come. The idea of the TD8 is to act as an easily-to-implement stopgap until the NTDF is fleshed out, and solve most user’s immediate problems without being too much of a burden to support.

TD8 will closely resemble TD6, but with a few changes:

• More room for the track type ID
• Ability to save brake speed of block brakes
• Ability to save JSON-object identifiers, in addition to DAT ones
• Entrance style will use the identifier instead of the fixed RCT2 index
• Support for split path surfaces and path supports.
• Support for more than 7 circuits
• Support (at least) 255 trains and 255 cars per train, including their colours
• The number of track elements, entrance/exit elements, path and scenery will be written before each table, rather than reading until 0xFF is hit.
• TD6 has a limit of 8192 track elements, this limit will not be present in TD8. The upper bounds will be determined by the limits of the integers used to store the size of each table

Other notes:

• With TD4 using version number 0 and 1, and TD6 using 2, TD8 will use version 3, and save it to the same location as TD4 and TD6 (i.e.

---

I am prepared to pick this up, providing the team is behind it, of course.

[karst]

I think the biggest justifying questions to consider are the following things:

• How much additional code/bloat does it require to continue supporting until NTDF/blueprint format
• How long would it take for the blueprint format to become a thing (if it's a year and a half then you'd might be better of waiting, but is it 5 years it might be worth implementing).
• How much work would it take to implement a said TD8/TDX: is it a quick but solid temporary solution or is this work better put in the blueprint format?

[Gymnasiast]

1. The idea is to add very little extra code by following the TD6 structure quite closely. TD6 and TD4 do not require much import code in the first place.
2. I would argue that even if NTDF is 1.5 years away, TD8 is worth it - not adopting it means 1.5 years of users not being able to save diagonal brakes, zero G rolls, medium loops, sloped 45 degree curves, newer paths, block brake speeds, etc. I would put the threshold for it at 6 months, rather than 1.5 years. In general, NTDF has been talked about for more than 5 years already and work hasn’t even started.
3. Like I mentioned in the proposal, it is intended as quick-but-solid temporary solution, one that I can bash out in a few days.

[ZehMatt]

I'm against it. It will add a bunch of code which will have to be supported forever, it will be essentially a copy of all the TD6 structures and the importer/exporter code with ever so slight modifications to account for the new fields. The logical thing to do is cleanup the existing track design code in order to move towards the new format, if we are going with TD8 then there will be also little reason to do the new format. I know its currently inconvenient but that is also the result of rushing features with bare minimum planning. It would help if the new requirements for the new format are known then we can move towards the structure and then we can actually implement it.

I would be okay if we consider TD8 to be the new format and call it a day but I'm absolutely against having another format after that then. We already have a ton of legacy code that no one is cleaning up to bring it to a better level so this wouldn't help it.

[ocalhoun6]

Yeah ... if you do this, you'll have to support TD6 and TD8 importer code pretty much forever. Which could be especially onerous if TD8 has only ever been used for a short-ish amount of time, but still requires indefinite support.

[spacek531]

I believe that refactors to TrackDesign.cpp may make a temporary format more palatable and would help in reducing the permanent import code to the minimum possible levels.

[733737]

What about a 4th alternative color scheme for all tracks?

[ocalhoun6]

That's probably best left for a full-blown new save format.

[733737]

I want to make it known that I am in favor of implementing TD8 now and still implementing NTDF Blueprints at a later date.