[_o_OOOO_oo-Kanawha]

In my opinion the only realistic catenary is provided with the Halycon Schwarzwaldbahn.

It has the proper vertical chain and zigzag. It is not a loft, it is assembled by hand using fixed pieces. Probably a rather tedious job, but well worth the effort.

I also like the RMD catenary, which is also assembled by hand I think.

For catenary to be even more realistic, a lot more visible hardware is needed: insulators, line breakers, guy wires, Y-suspension wires, downholders, wire tensioners, feeders and all other kind of kit. I doubt that these exist and authors are willing to put a lot more work into the electrification of their routes.

[cjakeman]

 Csantucci, on 08 May 2013 - 05:01 AM, said:

For the time being I would be happy if a checkbox in the Experimental options page could be available to select between the two solutions.

Couldn't we find a better solution than a checkbox?

Looking at the code in Wire.cs, there is already provision for overriding the default file in global\textures by providing one in the routes\<route>\textures

That solution seems to me to fit well with the way OR works.

[CGW121]

I will add my 2 cents by stating upfront that I have no real interest in electric railroading outside of HO scale. Electrified lines such as the PRR which were called heavy electric use the 2 wire version which I believe is better for pantograph operation. Interurban lines quite often used single wire as it was cheaper and those lines often ran on a shoestring budget. Then there were lines like the CA&E which used outside 3rd Rail. So for what its worth I would suppose both have their place in a sim.

[JTang]

 BB25187, on 08 May 2013 - 06:40 AM, said:

Hello,

On my side I reverted the change in the source files, since the double wire is more relevant on most of the routes I use.
Nevertheless, I agree that an option would be convenient, since the trolley style also make sense.

By the way, a couple of countries (Belgium, France, ... ) do use 3 wires catenary for 1500 or 3000V direct current. So, I am (naively) wondering if the shape profile used to define the overhead wire basic section could not be defined in a dedicated file rather than to have it hardcoded in the Wire.cs source files (i.e. without need to recompile)?

Regards

It adopts code from dynamic tracks, so yes it is possible to define new profile for it (in theory) without recompiling the code.

[Csantucci]

 cjakeman, on 08 May 2013 - 01:34 PM, said:

Couldn't we find a better solution than a checkbox?

Looking at the code in Wire.cs, there is already provision for overriding the default file in global\textures by providing one in the routes\<route>\textures

That solution seems to me to fit well with the way OR works.

Do you suggest to maybe add a further parameter in file route.trk, or to introduce a new parameter file within the route folder? I agree that this is the long term solution, but I understood that this is for milestones of OR beyond 1.0, and it would require a design of such new parameter files. E.g. also superelevation and route gauge by the moment are within the experimental page as a provisional solution.

[rdamurphy]

A long time ago on a website far away, someone showed a set of MSTS tracks with the overhead wire, guys, pulls, poles, and various accessories modeled as part of the track pieces.

Ultimately, it was some nice looking stuff, and took no longer to lay than normal track.

Alas, nothing came of it and it was never released.

To be honest, we should trash the majority of the horrible looking MSTS track, and create something that actually looks more like track rather than square pieces of silver painted lumber sitting on top of flat paper thin ties parked on the ground.

And rid the world of those absolutely horrible turnouts with the curves through the frogs. UGH!

Robert

[Csantucci]

There are some stating that catenary could be implemented much, much better (taking into accont however that some of the features indicated above are more an issue of the route/object builder than an issue of OR). There are others that would be already happy if as a first step what was already available could be again available as an option...

[Genma Saotome]

 rdamurphy, on 08 May 2013 - 11:51 PM, said:

To be honest, we should trash the majority of the horrible looking MSTS track, and create something that actually looks more like track rather than square pieces of silver painted lumber sitting on top of flat paper thin ties parked on the ground.

YES.

What I don't understand is why it has not yet occurred (not specifically by the OR team but by anyone). Shouldn't it be a rather simple program?

Open first world file and scan lines for first "TrackObj". When found skip 2 lines to locate SectionIDX. Check to see if that value has already been processed. If not, and use it's value to do a lookup in the tsection file. Use Walt's DT Profile logic to create a substitute mesh. Scan world file for next occurrence of FileName and save mesh in \routes\<routename>\shapes using that value. Add SectionIdx value to list of processed shapes. Repeat until end of file. Open next world file. Repeat all.

Quote

And rid the world of those absolutely horrible turnouts with the curves through the frogs. UGH!

Well, yeah, that too... but it's a bit more difficult to do: you have to design the replacement turnout to fit within the space allotted for the existing shape because you don't want to use the tsection data for the diverging path.

[markus_GE]

For my part, I can only say: 2-)
Two would fit better for my favourite line, LESurroundings, as in Austria I actually don´t know any standard track lines using something else than 2-wire catenary or none. In Austria we have single overhead wires at the very utmost on some NG lines - but it´s not common.

I can just agree to cjakeman, saying that a non-checkbox implementation would be better - just when looking at the options menu tabs and seeing how cluttered they will become with all those checkboxes and flags and whatsoever :thumbup3:

[rdamurphy]

 Genma Saotome, on 09 May 2013 - 09:01 AM, said:

YES.

What I don't understand is why it has not yet occurred (not specifically by the OR team but by anyone). Shouldn't it be a rather simple program?

Open first world file and scan lines for first "TrackObj". When found skip 2 lines to locate SectionIDX. Check to see if that value has already been processed. If not, and use it's value to do a lookup in the tsection file. Use Walt's DT Profile logic to create a substitute mesh. Scan world file for next occurrence of FileName and save mesh in \routes\<routename>\shapes using that value. Add SectionIdx value to list of processed shapes. Repeat until end of file. Open next world file. Repeat all.



Well, yeah, that too... but it's a bit more difficult to do: you have to design the replacement turnout to fit within the space allotted for the existing shape because you don't want to use the tsection data for the diverging path.

It happened YEARS ago, check out M-Tracks! # 15, 20, and 24 turnouts, straight through the frogs and curves with authentic measured arcs. And, AND, real world track spacing.

Yet hardly anyone has used it...

And, of course, it still uses the square rails.

Robert