Thought for long term code cleanup: separate tunnels/bridges from ways...

[neroden]

OK, so I'm fighting my way through the hairy hairy bridge and tunnel code in order to try to get the maintenance right.

And it struck me that we could improve both realism and flexibility *while* improving the code if we did one thing:

If we can figure out how to decouple the bridges and tunnels from the ways which run across them.

This would make it possible to upgrade a "stone tunnel with plateway" to a "stone tunnel with high speed track" or to convert a "stone tunnel with road" into a "stone tunnel with railway".

This would eliminate a lot of hairy code in the tunnel and bridge building code.  Why?  Because when the "way" is built, it automatically accounts for its own maintenance costs.  And then those have to be *subtracted*, before adding the bridge/tunnel maintenance costs back. 

If the way were treated as a fully separate object, with its own maintenance, buildable and removable independently, this would simply "do the right thing".

Now, the interesting thing is that the basic structure of Simutrans seems to already allow for this.  The wayobj objects are separate from the bridge and tunnel structures, and much effort is made within the code to build them and destroy them.

So the problem is mostly a user interface problem.  If we changed the user interface so that you built tunnels or bridges without "contents", and then afterwards pulled road/rail surfaces through them, we could remove a lot of mess from the code *while* increasing realism.

This would be a major internal change, but I think it would bring long-term benefits.  Now, I think I see how to do most of the work.  We can already drag tram tracks through road tunnels, which shows that most of the work has already been done.  But there are some problems:
(1) Artwork.  Is it possible to separately overlay the way artwork on the tunnel/bridge artwork?  This would simplify things a lot.
(2) Click-and-drag.  It's not clear to me whether this will work "automatically", though dragging tram tracks across bridges and tunnels indicates that it probably will.

What do people think?  Is this worth doing?  I think it will both improve gameplay and simplify the code, which is a double win.

[jamespetts]

In principle, this is a good idea indeed. It has been discussed several times before, I think, but deferred due to the amount of work involved. The realism/gameplay improvements would be very substantial: the ability to upgrade the track inside a tunnel, for example, would mean that we no longer need tunnels in the early eras to have unrealistically high speed limits that incentivise players to build tunnels rather than plain tracks in order to get higher speed limits.

There are, of course, complexities. The first is how to deal with existing paksets that do not separate the two. There is no obvious easy answer to this. I think that it probably is possible to separate the track and tunnel artwork: indeed, I think that a lot of the current tunnels and bridges are merged from track/road graphics and base bridges graphics in the GIMP.  However, unpicking this would be quite a lot of work, and may well take some months start to finish. There is the further complexity of the tunnel innard graphics, which I think are at present sporadically applied (see the tube tunnels in Pak128.Britain), and might well be tied to the track.

Another issue is restrictions: if we build a standard gauge railway tunnel, of course it should be possible to upgrade it from 40lb/yard wrought iron track to 95lb/yard steel track - but if we build a narrow gauge tunnel, it will be too small to fit standard gauge track into it; the converse is not true, however. Similarly, a standard gauge railway tunnel is wide enough for a road, but a narrow gauge tunnel is not. Then we have the spectre of the small "tube" tunnels of the London Underground, which are demarcated using way constraints. The issue is less acute with bridges, where the main constraint is the weight capacity, which is simulated directly.

As to click and drag, I am afraid that I don't know much about this code: you will have to investigate that yourself, I suspect.

However, as a long-term project, and despite these difficulties, this is still a worthwhile goal: I am put in mind of the tram tunnel in Kingsway, London that is now a road tunnel, or the road tunnel in Caernarfon, Wales that was once a railway tunnel.

[neroden]

In principle, this is a good idea indeed. It has been discussed several times before, I think, but deferred due to the amount of work involved. The realism/gameplay improvements would be very substantial: the ability to upgrade the track inside a tunnel, for example, would mean that we no longer need tunnels in the early eras to have unrealistically high speed limits that incentivise players to build tunnels rather than plain tracks in order to get higher speed limits.

There are, of course, complexities. The first is how to deal with existing paksets that do not separate the two. There is no obvious easy answer to this.

I was not planning to deal with this, period.  :-) 

Hence the choice to do the work in experimental, where there is only one pakset which *must* be updated.

I think that it probably is possible to separate the track and tunnel artwork: indeed, I think that a lot of the current tunnels and bridges are merged from track/road graphics and base bridges graphics in the GIMP.  However, unpicking this would be quite a lot of work, and may well take some months start to finish. There is the further complexity of the tunnel innard graphics, which I think are at present sporadically applied (see the tube tunnels in Pak128.Britain), and might well be tied to the track.

If you would be willing to work on the graphics end of it for pak128.britain, I can work on the code end.  We should do this as a branch for both the pak ("separate-tunnel-ways") and the code ("separate-tunnel-ways"), keep it out of the way of the main experimental pak.  Luckily git makes this easy.

Another issue is restrictions: if we build a standard gauge railway tunnel, of course it should be possible to upgrade it from 40lb/yard wrought iron track to 95lb/yard steel track - but if we build a narrow gauge tunnel, it will be too small to fit standard gauge track into it; the converse is not true, however. Similarly, a standard gauge railway tunnel is wide enough for a road, but a narrow gauge tunnel is not. Then we have the spectre of the small "tube" tunnels of the London Underground, which are demarcated using way constraints. The issue is less acute with bridges, where the main constraint is the weight capacity, which is simulated directly.

This stuff isn't very hard to deal with.  I can do this.   I believe that the way constraints are a useful tool for this. 

First, the weight capacity should not be a problem, although it will require retaining some special-case code to translate the weight capacity from the bridge onto the ways.  You get the "worst of the two".

Second, ways should inherit prohibitive constraints from tunnels.  So, if a tunnel is "tube", any track inside it (of any type) becomes "tube" and only "tube" trains can run on it -- you get the "worst of the two".  This is easy enough.

Done naively, this would have some funny results, in that you could run a road through a "tube" tunnel but there would be no cars which could run on it.

So, next step: tunnels (and bridges) would have a permitted list of track types, so that the most narrow tunnels would not allow roads (for example).  This also allows us to avoid some types of absurdities.  For example, canal tunnels don't usually convert easily to non-canal tunnels for reasons related to drainage design.  We don't want ANY tunnels to allow aircraft runways!  Also, open-deck trestles can only take tracks.

As to click and drag, I am afraid that I don't know much about this code: you will have to investigate that yourself, I suspect.

However, as a long-term project, and despite these difficulties, this is still a worthwhile goal: I am put in mind of the tram tunnel in Kingsway, London that is now a road tunnel, or the road tunnel in Caernarfon, Wales that was once a railway tunnel.

OK, if it's a good idea, then I'll start planning my line of attack.
Step 1: Data-typing work to give tunnels and bridges a list of approved waytypes rather than a single track type.
Step 2: Strip out the code which prevents overwriting ways on tunnels and bridges.  Replace it with code which pushes weight limits and restrictions from the tunnel/bridge to the way.  This gives the first chance to test.
Step 3a: Fix the graphics algorithm to draw the ways on top of the bridge.  This is the part I'm most worried about.
Step 3b: Fix the graphics algorithm to draw the ways on the tunnel interiors.  This I'm also worried about.
Step 4: Strip out the code which automatically builds ways on tunnels and bridges.  Test.
Step 5: Clean up the accounting (to the extent this wasn't done earlier).  Test.
Step 6: Move tunnels and bridges into their own menus.
Step 7: Debug.

[prissi]

If you just want to upgrade tunnel and bridges, than this could be done without a complete code rework.

Moreover, the ways underground are always taken from a reference. Thus old paks would use those. Only the number has to be changed.

Bridges is a different stories. There are bridges without ballast (not uncommon actually). Those would look bad with other tracks. Viaducts indeed may look ok with any track; but iron frameworks certainly not. Imagine a concrete clocks laid on a wooden bridge ... You can use constraits to forbid this. But how would you then indicate allowed waytypes. It sounds like a good way to frustrate player to have "This was is not allowed in this tunnel"

[ӔO]

maybe a separate image, or no image, for those types of bridges?

similar to how crossings use an overlay image.

[neroden]

The advantage of reworking the code is eliminating a large and annoying class of subtle bugs related to accounting.

Anyway, the start of this project is a little ways away...

[jamespetts]

Thank you for all of the thoughts - this is a very helpful topic.

I do think, however, that backwards compatibility is necessary: we don't want to lose the ability to use Standard paksets, or older Simutrans-Experimental paksets that do not have this new artwork, and also load older saved games. How to achieve backwards compatibility might involve a system in which it is possible to lay both tunnel/bridge and track at once, for instance, whilst maintaining the conceptual separation, although precisely how this would work if a player than tries to upgrade is another matter.

As to the artwork, I have not so far had much luck with way graphic artwork, but this might not be too hard, in that it might well be possible just to slice existing tunnel graphics into layers and isolate the track/road part from the tunnel part. For bridges, I can ask The Hood to upload wayless renders of the various bridges, which I understand are the base in any event onto which tracks/roads are subsequently laid, and use the existing road/rail graphics.

I assume that the same system would work for elevated ways as it does for bridges and tunnels? It would be good to be able to use elevated railways in a manner akin to the Docklands Light Railway in London, for example.

[kierongreen]

I've thought about it before too - indeed as I've mentioned elsewhere eventually I'd like bridges to be as flexible as tunnels. However graphics is the real sticking point there are a large number of images required to make this look reasonable.

[neroden]

I assume that the same system would work for elevated ways as it does for bridges and tunnels? It would be good to be able to use elevated railways in a manner akin to the Docklands Light Railway in London, for example.

Goodness I hope so.  Little point in doing it unless we can do this...

Anyway, this remains a longer-term project.  Backward compatibility is the last thing to think about; the first thing to think about is how to do it *at all*.  I don't think loading old save files will be a problem (the compatibility code is straightforward); while loading old paks when you have major new features *always* breaks things, and one shouldn't worry too much about it.

I don't think the images are going to be a serious problem if we can manage to separately overlay way images and bridge/tunnel images.   ....Which is probably harder than I first thought.

Tunnel portals are an issue, as are "over the top" truss bridges.  I think bridges and tunnels will need two-part images: one which goes under the way and one which goes over the way.  I think that would work. 

A combination of restrictions will need to be used to determine what sort of ways can go into what sort of bridges, but that isn't difficult coding. 

For convenience of player interaction, each bridge can, if you like, have a default waytype which is automatically built with the bridge (but can be removed or replaced).

[jamespetts]

A long-term project indeed: but a worthwhile one. The default system is probably sensible, and should probably be optional at the pakset level: this will help with loading of older saved games.

As to the graphics, I have never really done much with the graphics code, but I understand that there is a concept of "front images" and "back images" that do something similar to what you suggest: "front images" appear in front of vehicles, whereas "back images" appear behind vehicles. Quite how tunnel portals will work will need further thought.

The restrictions system is sensible enough, and should indeed be fairly straightforward.

[kierongreen]

Graphics are an issue because every way type requires a graphic for every bridge type potentially. Combine that with junctions and slopes and the number of images required could be immense. Therefore careful thought will be required over exactly how and what we want to implement.

[neroden]

In practice the majority of ways... sit on background.  What I was hoping to do was live compositing, so that the paving sits on top of the bridge surface.  Combinations which are no good would be prohibited by the pakset.

----

Think about how sidewalks sit on top of way images.

[jamespetts]

Graphics are an issue because every way type requires a graphic for every bridge type potentially. Combine that with junctions and slopes and the number of images required could be immense. Therefore careful thought will be required over exactly how and what we want to implement.

If it really was necessary to have different way images for each bridge type, this would probably be too much work - but why can't we re-use the same way images for each bridge?

[kierongreen]

Because not every way has ballast, and ways that do have ballast have different colours of ballast. With bridges different types have different widths, some need ballast, some do not. Add to this the fact that bridges are already composed of two layers and it would be tricky making sure that all graphics fitted seemlessly together. There could be constraints placed on this as neroden suggests, although this has the potential to be confusing for players.

[jamespetts]

I'm not sure that I entirely follow - would the ways themselves not have the ballast graphics?

[kierongreen]

If ways have ballast graphics though that would have to match different styles of bridge - which have different widths and some do not even need ballast at all.

[jamespetts]

Would it not suffice to have ways with the narrower of the ballast graphics for all uses?

[sdog]

If ways have ballast graphics though that would have to match different styles of bridge - which have different widths and some do not even need ballast at all.

But that would be something easily resolved:

Allow two types of bridges (i) with way graphics defined by the way (ii) with way graphics defined by the bridge.

For type (i) (applied to viaducts) etc, it follows excactly what neroden envisioned. The standards rail type would be applied. (in fact such bridges could be entirely replaced by elevated ways.)

For type (ii) bridge and way are still seperate entities. The way is not drawn however. The properties of the way are used and it interacts in every other aspect as type (i). The bridge would only need one image for an empty bridge and one for rails. Road bridges would not fall into category (ii).

for type (i) bridges different balast colour would be ugly and confusing. Having only differently coloured rail in type (ii) bridges would be much less of a problem.


From what i read in other forum threads, especially from pak-set makers side, this would most likely be very much desired in simutrans standard too. Perhaps it oughn't be only an experimental project.

Furthermore, this would be very beneficial for new players: First it would reduce the number of objects in the menu bars, from a bridge, an evelated way, and a tunnel for each speed and waytype to only one tunnel, a few bridges.

Secondly it allows upgrading of ways much more easily, bridges are an obstacle when doing so.

Thirdly it could help to actually implement the automated way builders, that place tunnels and bridges as they are drawn. I'd guess with the new landscapes, this buider could be revived again?


From a longer term perspective, it would resolve the old axle-load vs. tile load problem when introducing weight limits. (That is still on the agenda for standard?)

[kierongreen]

Don't get me wrong - I can see the advantages of way types being independent of bridges, particularly when it comes to upgrading track. Having two types of bridges would I think be more confusing though - players might well ask why some bridges change when upgraded and others do not.

Another couple of options are forcing all bridges to have the same width, and having separate rail and ballast images for tracks. The latter potentially makes having linking ballast easier also.

[jamespetts]

Separate ballast is an interesting idea...

[kierongreen]

If ballast is separated from track then you have the option of incorporting all ballast into the bridge images. The disadvantages are that it might then not match ballast on surrounding tiles, and that changing a bridge from rail to road, or canal to rail would be tricky.

[jamespetts]

Indeed - all things to consider.

[prissi]

I really wonder: How many bridges could be updated to higher weight or higher speed just be changing the asphalt or the tracks on them? As far as I know the speed and weight limits on bridges are rather set by the construction, widths, slopes and so on and not by the surfacing/tracks. The only thing is that some bridges were changed from rail to road, but then usually slow roads and low speeds. I really do not see the advantage for gaming here. (And bridges have already an invisible way so if you just want to change the properties it would be very easy.)

For tunnels however, those restrictions do not apply. My current feeling is, that maybe for elevated way, and tunnels but not for bridges. I even know of elevated ways which were upgraded three times, and the last time to high speed rails.

[jamespetts]

It's hard to see that there is a distinction in principle here between bridges and elevated ways, especially given how they are implemented in the code. It's frequent for the speed/weight limit of railway tracks on bridges to have been increased as better track is laid on older bridges: the axle load limit of track itself depends on the lb/yard (kg/m) rating, which does not depend on the bridge at all: the speed of the track depends on the tolerances to which it is laid, so, again, there are many circusmtances in which a suitable bridge might well be held back from a higher speed limit by lightly laid track.

[isidoro]

There can be a similar principle to the one now applied in the game for tram tracks: when you lay some 80 km/h tram track on a 50 km/h city road, the more restrictive speed applies.

The same can happen in bridges: if the bridge poses some restrictions then you can lay a 120 km/h rail track on it, but you won't get that speed at all.  And the same for other quantities like weight.

[jamespetts]

That makes sense for speed, but for weight, we have the important distinction between total convoy weight and axle load.

[prissi]

Still bridges have a load in t/m. In practice (e.g. german highways) there is a max. axle load and a max. weight.

Elevated ways and viaducts are indeed more liek normal ground; especially short viaducts coudl be upgraded a little. However, when at the end the speed limit and weight limti is given by the support structure, then nothing is gained, or?

[jamespetts]

Isn't the speed and weight limit given by both the support structure and the way (whichever is the most restrictive of the two)?

[prissi]

The weight limit is almost always given by the structure (apart from very short viaducts maybe), since this is really increasing the costs. Having to use stronger support means strong beams, means even strong supprot. It is quite non-linear in money and hence brdiges are usually built to be just strong enough (with large margins of course).

[kierongreen]

Bridges survive now from the early history of railways that were hugely overengineered for the time though. They now take trains twice as heavy and twice as fast as originally envisaged. That's not to say all bridges were built to this standard, and for sure it did cost more but it was considered worthwhile for some routes because of the interruption that would be caused later if rebuilding was required.

[jamespetts]

Bridges survive now from the early history of railways that were hugely overengineered for the time though. They now take trains twice as heavy and twice as fast as originally envisaged. That's not to say all bridges were built to this standard, and for sure it did cost more but it was considered worthwhile for some routes because of the interruption that would be caused later if rebuilding was required.

Indeed - and we want to be able to simulate these over-engineered bridges: they were an almost ubiquitous feature of the Victorian railway landscape.

[neroden]

OK, so I believe the current situation involves weight limits and axle loads using the same variable (and "overloading" it).

If weight limits and axle loads are in different variables, it makes it quite easy to take weight limits from the bridge and axle load limits from the way.  The ways should have nearly-infinite weight limits while the bridges should have nearly-infinite axle loads, and you just take the worst of the two, in each case.  (Just like taking the worst of the two speed limits.)

[kierongreen]

Yes that's correct neroden - some bridges could have larger weight and speed limits (brick viaducts) while others would have low limits (wooden trestles). Brick viaducts could then later be upgraded with ways introduced in later years, while wooden trestles would still be limited.

[jamespetts]

Yes, indeed: in Experimental, the variable is overloaded. We could use separate variables, or alternatively continue to overload the variable for storage and just add logic in the weight limit checking system to differentiate bridges (with convoy weight limits) from ways (with axle load limits), which could then be overlayed onto each other, rather than act exclusively of each other as now.

[greenling]

Hello
I think that´s better it, first to search data over bridges and tunnel.

[Vladki]

I have an idea, that could solve some of the questions above and backwards compatibility as well.

Most of the tunnels and brick/stone viaducts are kind of "convertible". Their speed and weight limits are high, tracks have ballast, and can be converted from railroad to road and vice versa. Such bridges and tunnels would have to specify a list of allowed waytypes (road, track, tram_track, narrowgauge), and any way of given waytypes could be built on them. The graphics would be empty - just the bridge or tunnel structure without the way. Speed and weight limits have to be checked for both way and bridge (tunnel) and the lower will apply for the whole thing. These bridges/tunnels would be built "empty", and a way would have to be built on top of them later.

Other type is non-convertible - e.g. wooden or steel bridges with track directly mounted to the structure without ballast, or tube tunnel that is too small for anything else that tube trains. These bridges and tunnels would have to specify the only way that is allowed on top of them, and the way could be built automatically. At the moment tunnels already specify a way that is displayed in underground mode, so all current tunnels could behave as non-convertible for backward compatibility.

For non-convertible (and backwards compatible) bridges I would suggest that the graphics include the tracks as they do now, and the way itself would be an invisible high-speed track. The track would have to be coded similarly to tube tunnel track, so that it cannot be built by player. For compatibility - if a bridge does not specify the way, this special one will be assumed. Top speed and weight limits would be limited by the bridge itself, not the way.

So, what do you think about this?