Metro Track Set

[FooBar]

Metro Track Set

The Metro Track Set adds third rail tracks to OpenTTD. It can add Metro Tracks as a new railtype or at your option replace monorail or maglev with Metro Tracks instead. You should be able to use it in combination with any trainset providing metro vehicles. Three different railtypes are provided: regular metro, metro with catenary and "underground" tracks.

More information, including available parameter options, can be found in the readme (also provided with the download).

Downloads
Official download locations are:
- OpenTTDCoop DevZone
- OpenTTD's ingame content download

Suggestions, comments, remarks, bugs, etc
Preferrably directly into the issue tracker so that they don't get lost.

General discussion can go in this topic. Development related discussion should go in the development topic.

[Lord Aro]

the | direction tracks sort of look like their floating...(if you get what i mean)

[FooBar]

I get what you mean, but I don't really see it. I guess I looked too much at the sprites already to have a clear view.

By the way, the extra-snowy tracks you see in the screenshot is only show after enabling a parameter setting. By default ballast is shown beneath the track, also above snowline, just like the default graphics do.

[Roujin]

Hey there,

there's an inconsistency between your readme and openttd that confused me for a while earlier: Your readme starts counts the parameters zero based, while the new openttd parameter selector window is one-based.

Then again, an item I saw on your issue tracker suggests that you'll be supporting the new features concerning parameters in OpenTTD soon anyway, so there won't be parameter 0 or 1 anymore, but named parameters instead, I suppose.

[FooBar]

I noticed that too...
Internally (in NFO), parameters are zero-based and I chose to keep that in the readme for reasons that I would not get confused myself and that several other sets seem to do that as well. But I guess that kinda backfired with the new OpenTTD parameter window.

But yes, named parameters are planned, don't know when that will be added though, as it is said that it breaks ttdpatch compatibility. That would somehow need to be resolved.

[Roujin]

Uh, really? I was assuming that it's backward compatible, i.e. TTDPatch and OpenTTD before the revision where this was introduced would just ignore these new features (seems reasonable to me). Or you could do a check for TTDPatch/OpenTTD (and revision while you're at it), and do things the old way or the new way respectively, couldn't you?

Internally (in NFO), parameters are zero-based[...]

Then maybe this is rather a case for the OpenTTD flyspray.. "Bug/Feature Request(?): Count non-named parameters in the parameter window from zero to be consistent with internals / readmes of existing sets."

[Rubidium]

Or you could do a check for TTDPatch/OpenTTD (and revision while you're at it), and do things the old way or the new way respectively, couldn't you?

Yes, the check can be done... but... as it is a new action that TTDPatch does not support it... uhm... doesn't ignore it even if there is a check that says to skip over the pseudosprite containing the unsupported action. OpenTTD will just happily ignore the unknown action.

Count non-named parameters in the parameter window from zero to be consistent with internals / readmes of existing sets.

Yes, but what about the readme documents that speak about first, second and third instead of zeroth, first and second? It would break readmes in either way and this way is more logical for the general user.
That would need a method for specifying whether they count from 0 or from 1. Oh... that requires the new infrastructure we have added. That makes it kinda pointless.

[FooBar]

1-based indeed makes most sense for regular users, as they've learned that numbers start with 1

"first", "second" etc. on the other hand always works. Depending where you start, parameter 0 and parameter 1 are both the first parameter, and so on. I will use that for the next version in the readme, then users can decide where they want to start their counting.

[Gremnon]

I just loaded this +2CC (from Bananas) up into a game, and low and behold... no metro tracks.
And yes, I did make sure there were metros available - they were running on the Monorail tracks instead.

The Bananas 2CC is version 2.0.0Beta3 - whether that's a version supported/ing this, I don't know.

Edit: Didn't realise there were parameters for the Metro GRF. Above problem now solved by putting the Metro tracks over Monorail.
But this gives me a new question - the readme says that for 2CC, to use Parameter 1 (Metro overrides Monorail), and for UKRS2, to set it to 0 (Own railtype). If it's set to 1, will the UKRS2 trains that normally use Metro tracks, still use them?

[FooBar]

But this gives me a new question - the readme says that for 2CC, to use Parameter 1 (Metro overrides Monorail), and for UKRS2, to set it to 0 (Own railtype). If it's set to 1, will the UKRS2 trains that normally use Metro tracks, still use them?

First, to avoid confusion, Parameter 1 is the second parameter.

Having that said, setting the second parameter to 1 makes metro tracks replace monorail, regardless of train set used. Setting it to 0 makes metro tracks an additional track type (in recent OpenTTD).
So using both URKS2 and 2cc is not really possible and setting the second parameter to 1 while using UKRS2 gives the UKRS2 third rail vehicles no suitable track. Depending on how Pikka coded the set, those third rail vehicles might be available for normal electrified rail or may not be available at all.

[Gremnon]

Bleh, stupid change the the numbering system... I preferred the old one. Though I'll grant the nice new GUI for params is interesting.

Anyway.
You've answered the question at least... either 2CC on monorails and UKRS2 on 3rd rail, or not at all, really.
Well, it was a nice idea.

Last question I have for now - can this be loaded alongside NuTracks, or am I right in thinking that NuTracks steals too many of the new rail type slots?

[FooBar]

The numbering scheme will be reconsidered for the next version of the readme, as it indeed is confusing. Pikka for instance also starts with 0, as well does the NFO source. Shortly after I wrote the readme (using 0 as first parameter), the new parameter GUI in OpenTTD was released, which indeed starts with one. Will use "first " and "second" in next release.

I will consider adding an option to allow monorail vehicles on third rail, as then 2cc's "monorail" metros can use the added third rail track, as well as UKRS' third rail vehicles. That should be a useful option if you want to use both sets at the same time.

Also if NuTracks defines a "3RDR" track type, then you can load metro tracks after NuTracks and then Metro Tracks will replace NuTracks' 3RDR track type. If NuTracks does not define such a track type, then load metro tracks before NuTracks and NuTracks' last-defined track type will not be available in favour of metro tracks (as there is no available slot for it to use).

[FooBar]

New release: 1.1.0!

Downloads in the usual location: here or via the OpenTTD ingame content download.

What's new? See below

1.1.0 (2010/08/18)
- NuTracks compatibility (r54)
- Better handling with 2cc set (r53)
- Third rail+catenary tracks (r52)
- Parameter dialog for OpenTTD r20258+ (r51)

1.0.1 (2010/08/14)
- Maglev sprite replacement showed wrong sprites in places (r44, r47)
- Railtypes requires OpenTTD 1.0.3 or r20242 (r48)

TTDPatch users should know that 1.1.0 requires at least nightly r2334. If you don't have that, either upgrade or use 1.0.1 instead. What has been added between 1.0.1 and 1.1.0 is only of use to OpenTTD players anyways, so you might as well just use 1.0.1 for now.

It's safe to upgrade your running games from 1.0.0 to either 1.1.0 or 1.0.1

Enjoy!

[SwissFan91]

Appreciate your work (and anyone elses) on this FooBar

[FooBar]

Thanks! I'm glad you like it

[aDe]

Hey guys, tracks are good, I was initially confused as to how to configure the parameters, but 17 seemed to do the trick, replacing monorail and enabling the "debug" option which makes the metro+catenary rail actually buildable.

However -- when using the 2cc train set, the electrified rail will be much more expensive than the metro+catenary rail, that doesn't make A LOT of sense. how can I fix that?

[planetmaker]

You could try to adjust the track costs with the 2cctrainset down to a reasonable level. It has parameters for that. If then every track type is too cheap, add a base costs grf and up the track build base costs accordingly.

[aDe]

You could try to adjust the track costs with the 2cctrainset down to a reasonable level. It has parameters for that. If then every track type is too cheap, add a base costs grf and up the track build base costs accordingly.

Good idea, but I can't seem to find that parameter anywhere, got any more info about it? I'm using 2cc trainset 2 beta 4...

[planetmaker]

I thought 2cctrainset had a separate setting for the track prices - which it does not seem to have. Nor does metro tracks seem to have a swtich in that respect nor do track costs have a separate base cost setting. So... I see no option, my initial idea does not seem to work, sorry.

[Ammler]

nutracks should work with metrotracks...