The place to talk about Transport Tycoon
https://www.tt-forums.net/
No.
Why not? What's preventing a patch from allowing multiple instances of bridges, defined by whichever NewGRF the bridges are from?
Each bridge in a set has a unique ID between 0x00 and 0x0C inclusive.SimYouLater wrote: 02 Nov 2019 00:09 Why not? What's preventing a patch from allowing multiple instances of bridges, defined by whichever NewGRF the bridges are from?
Ah. Okay, that makes sense and it's too bad that's the case. Is it possible to add more types that appear only with railtype and roadtype NewGRFs?wallyweb wrote: 02 Nov 2019 06:54Each bridge in a set has a unique ID between 0x00 and 0x0C inclusive.SimYouLater wrote: 02 Nov 2019 00:09 Why not? What's preventing a patch from allowing multiple instances of bridges, defined by whichever NewGRF the bridges are from?
A patch to extend that number is possible. JGR and cirdan gave us three extra bridge IDs: 0x0D, 0x0E and 0x0F.
16 is hard set in OpenTTD's code and that set of 16 is not repeatable.
To complicate the situation, each of those 16 IDs has four types: RAIL, ROAD, MONOrail and MAGLev. so in reality one could say there are 48 bridges to a set.
It is possible for each of those 16 IDs to have its own NewGRF, but depending upon the placement of that GRF in your GRF load sequence, it will either overwrite or be overwritten by any other bridge set using the same ID.
So now the question becomes: Is it possible to patch the code to allow multiple bridge sets such that one set won't overwrite all or part of another set?
The short answer would be yes. It is, after all, only code, but the task would be fraught with peril. The code for bridges touches upon so many other features of the game that it would probably require a complete rewrite of OpenTTD's code and that's the simplistic "no" answer to your question.
I do stand to be corrected on this.
In a manner, that happens now. railtypes and roadtypes define bridge surfaces that are applied as overlays to a bridge deck as long as the bridge is built from within a railtype/roadtype's GUI. The limitation is that the superstucture of a bridge is not addressable from within a railtype/roadtype's code.SimYouLater wrote: 02 Nov 2019 06:59 Ah. Okay, that makes sense and it's too bad that's the case. Is it possible to add more types that appear only with railtype and roadtype NewGRFs?
Are there any other bridge GRFs that make use of these extra IDs? Just found out about your bridge set but it would also be possible to create an extension for TBRS or something.wallyweb wrote: 02 Nov 2019 06:54 A patch to extend that number is possible. JGR and cirdan gave us three extra bridge IDs: 0x0D, 0x0E and 0x0F.
Not that I am aware of.Emperor Jake wrote: 11 Nov 2019 22:18 Are there any other bridge GRFs that make use of these extra IDs?
One could have a standalone set of one, two or three extra bridges. It would work alongside any bridge set.Just found out about your bridge set but it would also be possible to create an extension for TBRS or something.
Wasn't there a special "platform" type number (action 7/9, var 8B) of "2" for cirdan's NMF? And probably another one for JGRPP as well? (At least it had been discussed for the latter).Eddi wrote: 14 Nov 2019 20:42 NewGRFs tend to not use this kind of custom modifications, because it's not really possible to test if you're in a version that has them or not.
There is a feature test for this in JGRPP.michael blunck wrote: 15 Nov 2019 08:45Wasn't there a special "platform" type number (action 7/9, var 8B) of "2" for cirdan's NMF? And probably another one for JGRPP as well? (At least it had been discussed for the latter).Eddi wrote: 14 Nov 2019 20:42 NewGRFs tend to not use this kind of custom modifications, because it's not really possible to test if you're in a version that has them or not.
regards
Michael