Transport Tycoon Forums

A discussion today in IRC has produced this.

It is an attempt to create a simpler roadtype spec than those proposed before, mainly by dispensing with the special treatment given to tram tracks, and unifying everything as a single layer of roadtype.

Thoughts, feedback, and offers of coding help with this new proposal would be appreciated.

Andy and I have considered various ways to deal with the legacy second-layer tram system, and we're currently leaning towards not dealing with it.

My favourite option is to simply convert all tram tracks in old save games into roads, and all trams into normal road vehicles. This would at least allow players to return trams to depots for selling.

What I understand from this, tram tracks either allow both road and tram vehicles, or only tram vehicles. If you want both variants, you need two different roadtypes for that.

If that is correct, then may I suggest adding a default "tram+road" roadtype to the game. All tram vehicles can then remain tram vehicles, and all tramways without road will be converted to this type. However, I understand that dropping trams completely from old saves is easier, as it just means dropping the tram flag.

Is the intention is to have no default road types except just normal roads?

Some random musings on the spec:

In all cases, ownership of road tiles remains with the original owner, unless there is no original owner. While this is arguably open to griefing (for example, a player could upgrade all of their opponents' dirt roads to highways, greatly increasing their property maintenance costs; or a player could remove the tram tracks another player built on their roads), this is not significantly worse than the current situation (players can already remove their own roads or tramtracks even if they are used by other players, or block roads with level crossings).

This doesn't sound entirely desirable. Would it not be better to prevent players from upgrading their opponent's roads, or would this cause too many problems?

With regard to the action 3:

1) Shouldn't the icons for the loading bays be included in cargo type 00? Or conversely, shouldn't the depot icons be included in cargo type 08?
2) One way markers - won't you need 4 flat and 8 slope arrows? What about the no entry markers?
3) Road sprites - shouldn't this be 15 flat and 4 slope? How are pavements to be handled?
4) Street furniture - what are your four sprites here? In the current base set you've got one tree and two street lights (three sprites), but ideally I think you want to allow four orientations for the street lights (making five sprites in total). Would street furniture appear in the same town zones as it does now, or could this be customised (and would it be better to give trees and street lights seperate cargo types)?
5) Drive-through stations - would it be possible to allow custom road markings for these?

Are the roadwork sprites something that need to be considered?

PaulC wrote:This doesn't sound entirely desirable. Would it not be better to prevent players from upgrading their opponent's roads, or would this cause too many problems?

Well, it would mean that you couldn't build tram tracks across or along roads built by someone else.

The action3 stuff was all written very quickly, and is all subject to change. The road furniture is four sprites for the four sides of the tiles (eg, 4 orientations of streetlights). "Trees" vs "streetlights", for example, would be done with multiple sets of sprites and testing the town zone; it's fully customisable and you can have furniture in zones which currently have none, or based on random bits, dates, or other variables.

Yes, roadwork sprites too...

Oh, I have another suggestion, about catenary pylons:

Can there be an additional flag that changes how the pylons are drawn?
Without the flag set: current behaviour, pylons at both sides of the road;
With flag set: new behaviour: pylons drawn in the middle of the road between the vehicles.

This allows for some very fancy dedicated tram/trolley/etc. road types. Something I initially wanted to do for my tram track set, but impossible at the time.

i'd like to reiterate my statement from IRC earlier:

i am sceptical about this suggestion, especially because it makes it impossible to lay a straight tram rail over a road crossing (or any other combination that currently is possible)

So, one could implement Subways under roads by just keeping normal road sprites but defining a new Road Type, setting powered and compatible types with default road vehicles and Subway vehicles, disallowing overtaking for Subway vehicles, disabling drive-in stops, and drawing subway vehicles just as mostly transparent "shadows" to indicate they're underground? (Maybe also adding a bit of invisible buffer space behind each subway so they don't crowd each other so much). Then just add a stairway to the underground portion of the default drive-through bus stop, and hopefully it's all good to go!

If so, great! Still, I'm not sure how the system would handle "Subway under road and tram tracks" -- would that require another road type for compatibility? And what about even further road overlays, such as an Elevated system?

If all those would require additional road types, I would hope there wouldn't be a limit of 16, because it would get "eaten through" pretty quickly...

Like with railtypes, any combination will require a separate roadtype. And like railtypes, the limit here will be 16 as well. There simply isn't more space in the map array.

Eddi wrote:i am sceptical about this suggestion, especially because it makes it impossible to lay a straight tram rail over a road crossing (or any other combination that currently is possible)

If this is true, then I share that concern.

Eddi wrote:i'd like to reiterate my statement from IRC earlier:

i am sceptical about this suggestion, especially because it makes it impossible to lay a straight tram rail over a road crossing (or any other combination that currently is possible)

This is true. You will end up with a crossroad of road+tram track. However, the action 2 chain to pretty-up the tramtracks so they're only drawn to neighboring tiles with tramtracks on is relatively straightforward.

I definitely think abandoning tram tracks as a special case is needed for roadtypes to move forward. Trams as a roadtype should be treated like any other.

Supercheese wrote:Subways

No.

Supercheese wrote:Elevated system

No.

PikkaBird wrote:

Supercheese wrote:Subways

No.

Supercheese wrote:Elevated system

No.

Wherefore the brusque dismissal, sir?

Supercheese wrote:Wherefore the brusque dismissal, sir?

Maybe he doesn't like your suggestions Also I had the same suggestions in irc earlier

Elevated things are a problem: they run through bridges.

Subway is possible already as a hack on trams (just make them invisible)

andythenorth wrote:Subway is possible already as a hack on trams (just make them invisible)

Yes, but they still interfere with regular road vehicle/tram traffic.

...... and I just realized that they still would do that even with this new proposal. Derp. I guess some "non-interfering" variable would have to be added to make that work.
Sigh, disregard previous questions, then...

Eddi wrote:i am sceptical about this suggestion, especially because it makes it impossible to lay a straight tram rail over a road crossing (or any other combination that currently is possible)

I guess I have a possible solution for this. Probably best explained with an example.

Let there be three roadtypes, all with the same rating (prop 1E):
- normal road, allowing road vehicles
- tram track, allowing trams
- combined road and tram track, allowing both road vehicles and trams

On the map there is a road. The player builds a tram track in the other direction, crossing the road. In the current scheme, the tram track will stop at the road (or there will be a gap). This is because the tram track doesn't allow road vehicles on it. And this is annoying, as what we have now works better.

My solution:
- If the new type supports all the vehicles that the old type supports, replace the old type with the new type (same as currently proposed);
- Else, combine the supported vehicle types of both the old and new type, and scan the available roadtypes to see if there is a third type that supports all these vehicles;
- - If such a type exists, build this third type instead of the old or new type;
- - Else, fail construction.

This way, if there is a road type that is the sum of both the old and new types, it will be built automatically, saving the user a lot of clicks.



On a sidenote, I've given it some thought and I'm seriously in favour of having ROAD and TRAM roadtypes as default, where TRAM also allows ROAD vehicles on it. Dropping tramtracks just like that breaks way too much of what was accomplished in the past on this field. And that's not just because I'm an author of both a tram and tram track set, but especially because a considerable amount of players will have trams and tram tracks in their games.

FooBar wrote:On the map there is a road. The player builds a tram track in the other direction, crossing the road. In the current scheme, the tram track will stop at the road (or there will be a gap).

Well, this is the same way railtypes work. I don't see why it should be any different. And what if there's more than one "third type"?

On a sidenote, I've given it some thought and I'm seriously in favour of having ROAD and TRAM roadtypes as default, where TRAM also allows ROAD vehicles on it. Dropping tramtracks just like that breaks way too much of what was accomplished in the past on this field. And that's not just because I'm an author of both a tram and tram track set, but especially because a considerable amount of players will have trams and tram tracks in their games.

Yes, we did think about it a bit more and decided, though it would be quite a bit of work, this is the best option. Anyway, we have to get something coded and working before this even becomes an issue.

Supercheese wrote:Wherefore the brusque dismissal, sir?

Well, you're free to do such things if you want to, of course. The same goes for pipelines and - my personal favourite - canals. But these things are not roads, and implementing them as roads is hackish. So they will not be considered in designing the spec.

PikkaBird wrote:Well, this is the same way railtypes work. I don't see why it should be any different. And what if there's more than one "third type"?

This can be transplanted to railtypes as well, as there it would be useful in such situations as well.

In case of more "third types", just build the first found. This is better than just failing is case there actually is a different type available that is compatible with both. Or pick the one with the lowest rating that is higher than the highest of the ratings of the original type. This will allow newgrf authors to have some control over it.

PikkaBird wrote:Yes, we did think about it a bit more and decided, though it would be quite a bit of work, this is the best option.

Good to hear (well, read) that!