[OTTD] SlowRails 0.2 beta

[supermop]

Wouldn't it be easier for the labels to be "slow, medium, fast" rather than specific speeds? That way if hypothetical grf 'supermop's gorgeous rail graphics' can set graphics for 100kmh, 200kmh, and 300kmh, it can still be compatible when used with say, 'planetmaker's incredibly slow rail types', even if the latter specifies tracks for 10kmh 20 kmh and 30kmh....

Best,

[cmoiromain]

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.
Also, this doesn't take monorail or maglev into account.
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. A mix of the two... How could you take this into account?

[Kimby]

I need some advise regarding the use of parameters in an NFO. I'd also like to reply on a few posts. The question goes first:

I'm currently working on a scheme to map parameter bits to settings I want to use for SlowRails, but this makes things a bit difficult when checking against values set. I see the following possible answers, but maybe there are options I'm unaware about.

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.

2) use testing by going one bit at the time. That would work, but I'm not too impressed by the coding style needed for it. Still, so far it seems to be the best option

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.

Any great advise from someone ?


Now it's time to reply:

Wouldn't it be easier for the labels to be "slow, medium, fast" rather than specific speeds?

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.

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.

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.

Also, this doesn't take monorail or maglev into account.

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.

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.

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.

[ostlandr]

Finally got around to testing this. I thought at first the original rail type was still available in addition to the "slow rails" but I figured out that it's now the most expensive. (that's with the "Kimby" paramater enabled.) Very cool!

In case you're interested, here are the United States track classes and speed limits. Sorry about the formatting.


Class Freight Passenger
Excepted <10 mph (16 km/h) not allowed
Class 1 10 mph (16 km/h) 15 mph (24 km/h)
Class 2 25 mph (40 km/h) 30 mph (48 km/h)
Class 3 40 mph (64 km/h) 60 mph (97 km/h)
Class 4 60 mph (97 km/h) 80 mph (129 km/h)
Class 5 80 mph (129 km/h) 90 mph (145 km/h)
Class 6 110 mph (177 km/h)
Class 7 125 mph (201 km/h)
Class 8 160 mph (257 km/h)
Class 9 200 mph (322 km/h)

http://en.wikipedia.org/wiki/Speed_limi ... tes_(rail)

[planetmaker]

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.

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.

Cheers,
pm

[ostlandr]

Great work so far. I love that slow rails uses the "standard" rail graphics, since in the US the only difference between the track classes is maintenance and not structure (up until the introduction of concrete ties anyway.) Would love to see the configurable speed limits from NuTracks added to SlowRails.

This opens up so many possibilities. I am picturing an "eyecandy" rail graphic set as cmoiromain mentioned, with the slowest rail type being rusty rails with grass growing between the ties and the HSR having concrete ties.

As far as monorail/maglev, I think they are fine using the existing game mechanics to regulate speed.

One suggestion for the price model (which I love.) Could it include a maintenance cost multiplier also? That would encourage players to use the slower rail types and not just lay everything to the highest standard available. It would also put a drain on the finances of large companies, which IMHO would improve game balance.