Transport Tycoon Forums

Yay, thank you everybody

Maybe you should also thank yourself for everything you did for NRT ?

Awesome job everyone, thank you for your hard work! I've been looking forward to this day for a long time

In celebration I thought I'd upload my NRT NewGRF (RattRoads) to Bananas to give the broader audience something to play with, unfortunately I ran into a problem: Bananas doesn't seem to recognize OpenTTD's new versioning format, so there seems to be no way of limiting these new features to the latest nightlies. On a lark I set the Minimum OpenTTD version to 20190502, which surprisingly it accepted, but my NewGRF still appears even in 1.9.1. I was skeptical it would work at all since Bananas doesn't seem to have been updated in like 3 years (1.6.0 is still newest version listed ), but I figured if anything it would fail on the format being wrong. But I guess not.

So yeah, I tried to put an NRT NewGRF on the online content, but unfortunately it's either available to everybody or nobody due to missing version support, so I've "hidden" it for now

(On a related side note, can NewGRFs themselves even detect OpenTTD versions any more? I can't find any info on an updated format, I know it was talked about but don't know if one was ever decided on and implemented.)

Thanks again!

Andrew350 wrote:(On a related side note, can NewGRFs themselves even detect OpenTTD versions any more? I can't find any info on an updated format, I know it was talked about but don't know if one was ever decided on and implemented.)

If I read your question right, this has been possible for the longest time. It is set out as a global variable in the NewGRF Specifications. I don't do NML so I can't say if it is supported there, but I would imagine that it is.

wallyweb wrote:

andythenorth wrote:The first page of this thread has links to forks of NML with NRT support. A proper release of NML will also be needed for this, we'll get to that.

Will the sample NewGRF Specifications need modifications or are they complete as linked to in the first post?

peter1138 wrote:I'll have time to go through them tonight and make them tentatively official. There's a couple of additional flags (town can build and hidden) but no major changes.

A daunting task.
Hopefully you'll be able to update the NewGRF Specifications wiki as well as the NML equivalent.
Just a simple request once that is done ... Ask adythenorth to add to his first post prominent links to the respective pages.

Congratulations for this new feature!

Is an update of grfcodec/nforenum also planned?

arikover wrote:Is an update of grfcodec/nforenum also planned?

grfcodec fortunately just works with NRT, no changes needed

nforenum is no longer maintained as far as I know, so probably won't get updated unless somebody volunteers

andythenorth wrote:nforenum is no longer maintained as far as I know, so probably won't get updated unless somebody volunteers

Pity. It is so very good at finding missing ";" and line breaks and reminding us of the erers of our ways

andythenorth wrote:nforenum is no longer maintained as far as I know

Can you please stop again with the bulls*** spreading? It's part of grfcodec, it's under our wing, it will be updated.

wallyweb wrote:

Andrew350 wrote:(On a related side note, can NewGRFs themselves even detect OpenTTD versions any more? I can't find any info on an updated format, I know it was talked about but don't know if one was ever decided on and implemented.)

If I read your question right, this has been possible for the longest time. It is set out as a global variable in the NewGRF Specifications. I don't do NML so I can't say if it is supported there, but I would imagine that it is.

Yes the feature is there and it still works for releases (I think), but as far as I know it expects a certain format for the nightly version (like r21234 or so), so I'm not sure if it will work with the new format (openttd-20190502-master-blahblahblah). Unless it just works, maybe I just don't know how to write it correctly? I thought I saw some talk on irc about a new internal version number system, but don't recall what ever came of it, if anything.

Andrew350 wrote:Yes the feature is there and it still works for releases (I think), but as far as I know it expects a certain format for the nightly version (like r21234 or so), so I'm not sure if it will work with the new format (openttd-20190502-master-blahblahblah). Unless it just works, maybe I just don't know how to write it correctly? I thought I saw some talk on irc about a new internal version number system, but don't recall what ever came of it, if anything.

I think I see where you are coming from. Stable is currently at 1.9.1 When OTTD went to stable, I think master went to 1.10.0, but that is of little help when there is a new master almost every night. The problem is that github randomly generates a new number. Why not do a test and test for 1.10? If that works, at least you'll know you're not working with stable.

peter1138 wrote:Can you please stop again with the bulls*** spreading? It's part of grfcodec, it's under our wing, it will be updated.

To be more accurate, the most active former maintainers have either left (rubidium), or have said they will not maintain it (frosch).

But contributions are welcome https://github.com/OpenTTD/grfcodec

wallyweb wrote:Why not do a test and test for 1.10? If that works, at least you'll know you're not working with stable.

Yeah I thought about that after posting. Honestly I'm a bit skeptical but if it works that might be okay for now (still not ideal though). I'll have to test once I get home

acs121 wrote:Maybe you should also thank yourself for everything you did for NRT ?

Nah, I just started it all with Andy, other people did really more work

andythenorth wrote:

peter1138 wrote:Can you please stop again with the bulls*** spreading? It's part of grfcodec, it's under our wing, it will be updated.

To be more accurate, the most active former maintainers have either left (rubidium), or have said they will not maintain it (frosch).

But contributions are welcome https://github.com/OpenTTD/grfcodec

Well, nice to hear that grfcodec already works with NRT, and nice to hear that nforenum was not forgotten...

wallyweb wrote:

Andrew350 wrote:Yes the feature is there and it still works for releases (I think), but as far as I know it expects a certain format for the nightly version (like r21234 or so), so I'm not sure if it will work with the new format (openttd-20190502-master-blahblahblah). Unless it just works, maybe I just don't know how to write it correctly? I thought I saw some talk on irc about a new internal version number system, but don't recall what ever came of it, if anything.

I think I see where you are coming from. Stable is currently at 1.9.1 When OTTD went to stable, I think master went to 1.10.0, but that is of little help when there is a new master almost every night. The problem is that github randomly generates a new number. Why not do a test and test for 1.10? If that works, at least you'll know you're not working with stable.

the check for 1.9 vs. 1.10 still works, but with the move to git as the main repository, there is no linear revision number anymore. so you cannot do any checks like "was this before or after NRT merge?" currently, unless someone invents a new counting method, and puts that into the build system. (PRs welcome, i guess)

Eddi wrote:the check for 1.9 vs. 1.10 still works, but with the move to git as the main repository, there is no linear revision number anymore. so you cannot do any checks like "was this before or after NRT merge?" currently, unless someone invents a new counting method, and puts that into the build system. (PRs welcome, i guess)

I'll make an assumption here. NRT has been merged into master. Once it has passed muster and the merge is found to be stable, OTTD stable will move to 1.10 and master to 1.11.
@Andrew350 - Do you need to test for changes to master, or will a simple "stable/not stable" test satisfy what you need?

peter1138 wrote:I'll have time to go through them tonight and make them tentatively official. There's a couple of additional flags (town can build and hidden) but no major changes.

DISCLAIMER: Not being pushy. I understand that this will be done when it is done.
A question concerning town zones and "town can build".
The pro-forma by Frosch cites a property: 0x14 speed_limit
and a variable: 0x44 town_zone Currently not available for bridges and stations.
Railtypes (feature 10) says: variable 44 Town zone of the tile. (Only available for level crossings and depots.)
If a town can build roads, can a grf tell the town which road type to build in each town zone?
Town zones shift as a town grows. Will the road type evolve and more specifically will the speed limit property follow?
An example: Town zone 5 (road type A) speed limit 30 km/h; Town zone 4 (road type B) speed limit 50 km/h

wallyweb wrote:If a town can build roads, can a grf tell the town which road type to build in each town zone?

no, the GRF only tells the town which roadtypes are available for building in general. the town makes the final decision of which road to build. the decision how that is done might be made available to some town ai type thing in the distant future

Town zones shift as a town grows. Will the road type evolve and more specifically will the speed limit property follow?

no, properties are fixed, they cannot change depending on town zone. (that would require a callback, and probably some place to cache the callback result)

Eddi wrote:

wallyweb wrote:If a town can build roads, can a grf tell the town which road type to build in each town zone?

no, the GRF only tells the town which roadtypes are available for building in general. the town makes the final decision of which road to build. the decision how that is done might be made available to some town ai type thing in the distant future

Town zones shift as a town grows. Will the road type evolve and more specifically will the speed limit property follow?

no, properties are fixed, they cannot change depending on town zone. (that would require a callback, and probably some place to cache the callback result)

Thanks Eddi. So if I understand you correctly, when a player starts a new game, there will be no speed limits anywhere until the player overbuilds a road with a road type and if the player wants to maintain zone specific speed limits the player will have to monitor the towns as they grow?