The place to talk about Transport Tycoon
https://www.tt-forums.net/
That would actually be rather difficult, because the meaning of "slow", "medium" and "fast" can differ a lot. Let's say I use those labels for the speeds I have now, then what do I do when I decide to add 120 km/h to the mix ? It's also easy to assign a 160 km/h loc to the _160 railtype, but when you label it as "fast", there's no guarantee the railtype is going to be fast enough.supermop wrote:Wouldn't it be easier for the labels to be "slow, medium, fast" rather than specific speeds?
I agree such rails are possible, but I see no problems introducing labels for them that don't conflict with those I'm using. On the contrary, the use of numbers makes it very unlikely I'll have a conflict with a railtype that isn't essentially the same as what I defined.cmoiromain wrote:Something else to consider with your label is the case of an eyecandy rail set, providing only new graphics (concrete based, grassy, etc...) without setting any speed limit.
True: I didn't add monorail/maglev at the moment for some reasons, not least of them those tracktypes being significantly less popular. If it turns out there's a demand for slower versions of them, I'll look into adding it to SlowRails.cmoiromain wrote:Also, this doesn't take monorail or maglev into account.
As I understand it, all that's needed is for someone to add those 2 extra railtypes you'd like to the game using a newGRF and they'll appear in the list. Since there are 12 slots available for extra railtypes, of which SlowRails currently only uses 6, such newGRF should be usable alongside SlowRails. But it's possible I got that wrong.cmoiromain wrote:In my case, I'd love to use standard monorail and maglev along with the concrete based monorail and maglev released as newgrfs, without it affecting speed limit.
ad 1) Where's the problem with that? But if you have a number of boolean settings you can store them as bit mask (like suggested in 3) within one single parameter and then query them for specific use. You might use an internal parameter for that and should not overwrite user-parameters for that means. See http://wiki.ttdpatch.net/tiki-index.php ... parameters or http://hg.openttdcoop.org/nml/raw-file/ ... f-settings or possibly look at how some of the existing NewGRFs handle that, some sources are found at the DevZone.Kimby wrote: 1) the "wastefull" answer: use a full parameter of 32 bits to store each and every setting, even if I'd only need a few bits from it. That would makes things easy of course, but somehow I don't feel good about doing it this way.
3) apply an AND bitmask to the parameter so I only have the bits left I need for my test. This is the way I'd like to do it, but from what I've found out, the only way to do that and be able to use the result would be with an action D. If I understand the consequences of that action correctly, I'd need to reserve a parameter to store the result of any action D I want to use (which would logically best be parameter 0 I guess). I'm also not clear if it's allowed to use a parameter as both a source and a target in the same action D.
