[Patch] Catenary on third rail-type

[stevenh]

Seeing as that the Japan set uses it and the source says "//unsupported" ... _and_ that I couldn't find anything on flyspray I thought I'd quickly code this in.
Catenary now shows on Shinkansen tracks (and whatever_other_third_rail_type tracks if the GRF supports it) in OpenTTD.

EDIT: All good.

[jaybud4]

Caternary now shows on shinkansen tracks

Am I the only one who didn't understand what that meant at all?

[stevenh]

Patch updated... The actual check for track requiring catenary is now a function in one spot so if anyone wants to add more track types with catenary then they can do it a lot easier.

Am I the only one who didn't understand what that meant at all?

...Just means overhead wires for Japanese bullet trains.

[T-Unit]

Catenary = Over head wires and structure that holds it up
Shinkansen = High speed Japanese trains

[Toni Babelony]

Extra muchos gracias! I hope this gets implemented in trunk, since it's not only a great addition to the Japan Set (which has revived like a phoenix from the ashes), but also for the Swiss set.

Great eye candy. This surely makes playing with Shinkansen even more attractive

[DaleStan]

So, I'm a little bit confused what happens when the GRF expects to get the catenary over monorail, not maglev. (The name of the third track type is not defined in TTDPatch.)

[dandan]

Great to see this feature making it into Open TTD (hopefully).

Three cheers to stevenh!

Not to spoil the celebration, but I want to take the opportunity to mention another problem with the Japan Set in OpenTTD (that also affects the Canadian Set and possibly others). Namely if I'm not mistaken, realistic acceleration is not supported for Shinkansen and Narrow Gauge trains. At least their tractive effort is not displayed.

[stevenh]

So, I'm a little bit confused what happens when the GRF expects to get the catenary over monorail, not maglev. (The name of the third track type is not defined in TTDPatch.)

You now also have me confused... The TTDPatch Wiki states that Bit 5 means "Enable catenaries over the third track type (only with electrifiedrailway on)"...
How does one, in TTDPatch, get Catenary showing on Monorail? By using the unifiedmaglev switch?

[DaleStan]

By using the unifiedmaglev switch?

Correct. The third track type is either "monorail" or "maglev", depending on whether unifiedmaglev is 1 or 2 (not necessarily respectively).

[stevenh]

More research required on my behalf then...
As far as I understood OTTD didn't require support for that switch since it had Electrified Railways as it's own type.
Therefore the "third" type is really the fourth... and either way, using the RAILTYPE_MAGLEV would get it.

Can you suggest a GRF that requires the 'unifiedmaglev' switch so that I can see how it behaves in OTTD?

[DaleStan]

Any of the narrow-gauge sets should check the setting of unifiedmaglev to determine where to put its replacement rail sprites.

The JapanSet should too, but I don't know if it does.

[stevenh]

So as long as the unifiedmaglev 'emulation' of OTTD returns the correct rail-type to replace then all should be swell...
I've just attempted using the Narrow Gauge set and then the Canadian Set (v2j) and all seems to function correctly as far as this is concerned. Of course, neither of these use catenary on the third type; so I've just proven zero.

I'll continue digging to find a set that wants catenary on the second type and then work out what to do.

Just reading over the TTDP Wiki again; if the switch simply defines how monorail and maglev are merged into the 'third type' then there is no real issue with it? I mean, either way the end target is the third type and this is what we are applying the Catenary to. When unifiedmaglev=1 (maglev to monorail) they still are used on the third type.
...still confused but relatively content that this issue wont affect this patch.

[DaleStan]

But it will. In TTDPatch, third-rail-type trains may be coded to use either monorail or maglev; these will be combined into one type, depending on the user's unifiedmaglev setting.

A coder who codes all his third-rail-type vehicles as monorail and requests catenary over the third rail type will be unimpressed when OpenTTD puts all his engines on monorail track and the catenary on maglev track.

[Toni Babelony]

If that's the case maybe there should be developed a .grf wich will cover both rail and catenary with parameters over several rail types. Could be a nice idea to get rid of the maglev rail in the Spanish set and the catenary-less rail in the Swiss set... Also, less bothering with patches and angry/unpleasant surprised .grf developers... Just a thought.

[stevenh]

A coder who codes all his third-rail-type vehicles as monorail and requests catenary over the third rail type will be unimpressed when OpenTTD puts all his engines on monorail track and the catenary on maglev track.

Right, so if someone did code a set like this, then they'd expect the result to be that their vehicles will be on the third-rail type with catenary... as would happen in TTDP. But of course, OTTD will put the vehicles on monorail and then catenary still on the maglev. That would also mean that if they've also attempted to replace the track graphics that they expect to be replacing the maglev, whereas they'd need to replace the monorail in OTTD (and then get catenary on monorail as well.)

If OTTD can determine what the GRF wants to do with this (by checking how the GRF is using the unifiedmaglev setting; I'd imagine the GRFs can control this setting?) then it can work out how and where to put the vehicles? ie. force them onto maglev.

Can any of the OTTD Devs give input on this? Do you want OTTD to emulate TTDP and throw all the vehicles on maglev if that's what the GRFs want?

[Toni Babelony]

would also mean that if they've also attempted to replace the track graphics that they expect to be replacing the maglev, whereas they'd need to replace the monorail in OTTD (and then get catenary on monorail as well.)

What I ment wasn't a parameter for both rail and catenary combined, but two parameters for catenary and rail seperated so you can choose where to place them.

OT:
That reminds me, I should redraw the Iyotetsu trams from your Japanese tram set I've made. They look hideous! Can't believe I actually made these monsters... (with some ugly flashing livery) Could you sent to me the sprites I've drawn. I seem to have lost them somehow.

[belugas]

A coder who codes all his third-rail-type vehicles as monorail and requests catenary over the third rail type will be unimpressed when OpenTTD puts all his engines on monorail track and the catenary on maglev track.

Right, so if someone did code a set like this, then they'd expect the result to be that their vehicles will be on the third-rail type with catenary... as would happen in TTDP. But of course, OTTD will put the vehicles on monorail and then catenary still on the maglev. That would also mean that if they've also attempted to replace the track graphics that they expect to be replacing the maglev, whereas they'd need to replace the monorail in OTTD (and then get catenary on monorail as well.)

If OTTD can determine what the GRF wants to do with this (by checking how the GRF is using the unifiedmaglev setting; I'd imagine the GRFs can control this setting?) then it can work out how and where to put the vehicles? ie. force them onto maglev.

Can any of the OTTD Devs give input on this? Do you want OTTD to emulate TTDP and throw all the vehicles on maglev if that's what the GRFs want?

So what you are suggesting is a way to trap the access to the unifiedmaglev switches (i think there are two, line 4982 and 4983 of newgrf.cpp) in order to guess on which tracks the author wishes to place his vehicles.
Right?
Of course, it would be in conjunction with the setting _patches.disable_elrails. If it is disabled, the system can guess that third is maglev and second is monorail. If it is enabled, then the monorail will be the one using both catenary and engines. Right?
I have not been deeply involved with the rail types, so i can only assume what i'm suggesting.

As to if we would like to implement that, personally, i would say yes. That, and of course, that you are doing a good job, stevenh

[DaleStan]

Can any of the OTTD Devs give input on this? Do you want OTTD to emulate TTDP and throw all the vehicles on maglev if that's what the GRFs want?

How do you determine whether that's what the GRFs want?

If OTTD can determine what the GRF wants to do with this (by checking how the GRF is using the unifiedmaglev setting; I'd imagine the GRFs can control this setting?

There seems to be a metric fsckload of confusion here.
unifiedmaglev is a setting in ttdpatch.cfg. GRFs have never been able to change things set in ttdpatch.cfg, and never will be able to. They can test, but they cannot modify.

[stevenh]

...slightly less confused...
Right, so they can't change the setting... no problems...

[thinking-out-loud]
That just means that if the GRF checks for a unifiedmaglev setting of "1" then they will code all vehicles to be monorail... since the maglev is 'hidden' (in TTDP). Though in OTTD both types are still available... whereas the other way around would work.
[/thinking-out-loud]

I think the best answer here would be (as Toni suggested) a new switch to allow catenary on monorail... but that would mean all GRF authors would have to add in a little logic to check for OTTD...etc...

[DaleStan]

That just means that if the GRF checks for a unifiedmaglev setting of "1" then they will code all vehicles to be monorail... since the maglev is 'hidden' (in TTDP).

No. If the GRF checks for a unifiedmaglev setting, that means it needs to know what the unifiedmaglev setting is. I can come up with two reasons to need to know the unifiedmaglev setting:
1) Replacing different track sprites. Obviously, it won't do to replace the maglev track sprites if TTDPatch is going to display the monorail track sprites.
2) Refusing to load under certain circumstances. eg, Oskar's basetunnels, on the grounds that it's too hard to tell whether or not there's maglev track over the tunnel.
Neither of these have anything to do with the way the vehicles are coded, nor even if there are vehicles present in the GRF at all. Conversely, the failure of a grf to check unifiedmaglev does not mean that it does not expect its vehicles to get a catenary. The GRF may not care what sprites are used for its vehicle's tracks (How many tram GRFs check that tram track sprites are available, for example?), or its GRF may merely check that the appropriate track GRF file is or will be loaded.

Then you've got the other issue: How do you detect what the GRF is testing? More precisely: What NFO code will you look for to indicate the tests for which conditions? Write the NFO code that is "checks for a unifiedmaglev setting of 1". How does it differ from the code that is "checks for a unifiedmaglev setting of 2"?
Keep in mind that most grfs that test unifiedmaglev want to different behaviour depending on that setting, so checking for a <num-sprites> of zero is not sufficient. Also, keep in mind that, once electrifiedrails has been determined to be on, unifiedmaglev will be either 1 or 2.