Topic: Hyperloop

[jamespetts]

It has been in the news recently that Elon Musk's "hyperloop" idea is actually being developed. I wonder whether there would be any benefit in a "hyperloop" waytype for Simutrans?

[DrSuperGood]

And what difference would there be mechanically from something like Maglev next to graphic assets? Which by the way acts pretty much identically to Monorail, rail, light rail, and tram.

As it is pak128 lacks maglev (it only has monorail). Pak64 has maglev under the name "monorail" for backwards compatibility however that is limited to passengers and mail only.

To me hyperloop sounds like something that would just be a fancy maglev/monorail way type with high maximum speed limit.

[jamespetts]

The only important difference, aside from graphics, speed limits and other pakset asset matters, would be that hyperloop vehicles would not be able to travel on maglev ways and vice versa.

[Ters]

The difference, as far as Simutrans is concerned, is that they are different. Another thing is that Hyperloop might become a one-of-a-kind system. There might be other similar lines, but as similar and yet incompatible (or more so) as different gauge railroads.

[Sarlock]

With Experimental's waytype restrictions, wouldn't it be as easy as making new hyperloop graphics: waytype(s), vehicles, depots, and then flag the vehicles as only being able to use the hyperloop waytypes?  The maglev and hyperloop lines could, of course, be joined together, but the vehicles could still only travel on their respective waytypes.

It would be a fun way to extend a pakset in to 2030 and beyond with a very viable competition to aircraft.

[jamespetts]

With Experimental's waytype restrictions, wouldn't it be as easy as making new hyperloop graphics: waytype(s), vehicles, depots, and then flag the vehicles as only being able to use the hyperloop waytypes?  The maglev and hyperloop lines could, of course, be joined together, but the vehicles could still only travel on their respective waytypes.

It would be a fun way to extend a pakset in to 2030 and beyond with a very viable competition to aircraft.

The idea of way constraints is not to duplicate the function of way types, but to have a system of partial restrictions: only certain trains, for example, can fit through tube gauge tunnels, but those trains can also travel on the same track as ordinary trains; only certain canal boats can fit on a narrow canal, but those boats can also travel on wider canals; certain trains require a particular type of electrification, but steam and diesel trains can also travel on track that has that type of electrification, and so forth. A completely separate system is much better simulated with its own way type. Also, there is no reason to limit this feature, if it is thought worthwhile to introduce it (and I should point out that I was only half serious about this suggestion, since this is not yet a viable means of transportation; but it might improve the longevity of a single game into the future), to Experimental.

[Ters]

One thing that might be worth looking into is removing the definition of way types from the game core and delegating it to the pak sets. I don't suspect that this is an easy task, as some things are hardcoded onto specific way types, like city cars. Breaking this binding, and making the city car concept something configurable for any way type, can lead to more eye-candy like small private boats and airplanes cruising around. I'm sure there are players that will start drooling at this idea.

Water is the most special case-ish. While similar to air in the sense that waterways and airspace are provided by nature, airspace is for all aircraft, with any difference between air way types restricted to the runways. The oceans are however only for ocean-going ships, while smaller rivers are quite the opposite.

[Leartin]

Basically, the Hyperloop is just a different Maglev. Of which there are already severel with completely different approaches and visuals, so that including them would already require multiple different track types. So before "hyperloop_track" is viable, you'd need "transrapid_track", "jr_maglev_track", "berlin_m_track" and so on. Oh, and let's not forget broad gauge. Or rather, that there are 20 different named gauges.

Since all of those would be copys of each other with different names, I once proposed on the German forum to change them to a more modular approach, allowing the pak creator to invent a new type of track just by defining it as 'something'_track. So you'd remove things like monorail_track or maglev_track from the code and have it work for all x_track.
While this was turned down as impossible (I don't understand code, so there you go) it was also said by prissi that more track types are not needed at all, since the track types we have are not used sufficiently currently.
I think that's wrong, since something like the Hyperloop is complete just with one track, signals, and one vehicle if it's supposed to deliver only pax, more (which would look almost identical) for mail and goods. But why would one do it if it can't even be in a set?

Edit: What I proposed back then, after a while of tinkering around, translated:

I'd like to write [xxx]_track as the waytype in a dat file, where [xxx] is any word - I want to do this with ways, vehicles, signals, depots, stations... . The game should realize it's a track, a track of type [xxx]. The game knows how to handle a track. [xxx] only makes sure that only [xxx] vehicles bought in the [xxx] depot move on [xxx] tracks, and [xxx] tracks don't connect to any other tracks.

[Ters]

[...]this was turned down as impossible[...]

Not impossible, but I've pointed out some of the difficulties. And that's just what I could think of while writing the post without looking at the code. But I don't think it's too much more complicated than double height.

[...]it was also said by prissi that more track types are not needed at all, since the track types we have are not used sufficiently currently.

This is a valid reason for not introducing more way types into the game, but it also shows how defining the way types in the game isn't optimal. Much is unused by each pak set because not all pak sets want the same way types.

[Leartin]

Well, nothing is impossible I guess, what I meant was it was turned down because of the coding part, since there seem to be things holding it back. But what you mentioned seems of no concern. If you reduce the coded waytypes to street, track, water and air, you'd still have a "street" in additon to all custom made "xxx_street"s, which applies for city cars, city generation, and so on. All natural water would be of the "water" waytype, while custom made "xxx_water" might behave similar, but that's not the waytype every sea-tile has. This is different for air, since air is pretty much the same as 'any', unless on the ground. They are the least likely to interfere.
Tram, as a subtype of track, would probably work for any type of track than. But that would not be too bad, since it has no effect. Except that you could have multiple gauges of tram tracks if you want.

The stuff about "city cars for other waytypes" is nice, but I'd rather do it with moving ground_objects. Two new types of behaviour for them, "stick_to_water" (resulting in a ground_object that only moves on water tiles) and "straight_way" (resulting in a ground_object that does not move completely at random, but saves the last direction it went and has a high chance of repeating it, a lower chance of going slightly astray diagonally, and even lower chances the more the course iwould be changed) should solve both flying and swimming ducks. As for tracks, I don't think you'd ever want a game-generated vehicle there.

[prissi]

You could have tram like tracks for any set, just define system_type = 1. It is not tested though.

[Ters]

Well, nothing is impossible I guess, what I meant was it was turned down because of the coding part, since there seem to be things holding it back. But what you mentioned seems of no concern. If you reduce the coded waytypes to street, track, water and air, you'd still have a "street" in additon to all custom made "xxx_street"s, which applies for city cars, city generation, and so on. All natural water would be of the "water" waytype, while custom made "xxx_water" might behave similar, but that's not the waytype every sea-tile has. This is different for air, since air is pretty much the same as 'any', unless on the ground. They are the least likely to interfere.
Tram, as a subtype of track, would probably work for any type of track than. But that would not be too bad, since it has no effect. Except that you could have multiple gauges of tram tracks if you want.

It depends on what one means with way types. In broad terms, there are just four: road, rail, water and air. But vehicles need a more specific, and since that's what the term way type is now, that's what I mean with way type. The question is how to connect the code with pak set defined way types. One can either say that there are only the four coded way type classes, or be more parametric about it if it can make any sense. Trying to mix way type classes and specific way types will likely just complicate things.

[Leartin]

You could have tram like tracks for any set, just define system_type = 1. It is not tested though.

system_type=1 is an elevated way. I guess you mean system_type=7, but the way I see it that's just a flag for the menu and does not work. I always define "waytype=tram_track" and "system_type=7" for a normal tram. I tried it just now, since you got me excited for a moment. Pak192.comic would probably change all trams to narrowgauge if it was that easy.

But actually, even if system_type=7 was enough, it wouldn't have full functionality. You'd not be able to have a seperate depot for tram vehicles of that track, and no vehicles specific for tram either. Which is sad :(

It depends on what one means with way types. In broad terms, there are just four: road, rail, water and air. But vehicles need a more specific.

I'm not sure what you mean. Those four way types are the one I'd keep hardcoded, but the number of actual waytypes you can create from them would be unlimited.
I don't know if you can have "track" as a superclass and every user-generated "x_track" as a subclass, or need a "track_superclass" with an actual subclass "track" alongside all user-generated "x_track"s. None of them has a special behaviour, they are just copys of each other. It's just that there is only one which always needs to exist as a reference.

I guess you mean to have no pre-prepared waytypes, but only parameters like with signals. "unlimited_stacking=1" for water, something like that. I guess that would open up the way system even more, since it would be easier to sneak in new parameters than new waytypes, but I don't really see the point, since each waytype we have right now would have exactly one such flag...

[Ters]

I'm not sure what you mean. Those four way types are the one I'd keep hardcoded, but the number of actual waytypes you can create from them would be unlimited.
I don't know if you can have "track" as a superclass and every user-generated "x_track" as a subclass, or need a "track_superclass" with an actual subclass "track" alongside all user-generated "x_track"s. None of them has a special behaviour, they are just copys of each other. It's just that there is only one which always needs to exist as a reference.

A way type is a number. Ways can only be connected if the number is the same. Vehicles can only drive on ways with the same type number as it has itself. (Trams are a bit special here, because they're a pseudo-separate way type.) If you hardwire the code to the four basic types, any user defined way types would not do anything, because there is no code for them. Instead, you have to just have to code way type classes not tied to any specific way type, and then the user-specified way types specify which implementation class to use (creating subclasses would be overly complicated). It would be something like:

Code: [Select]

obj=waytype
name=narrow_gauge
waytypeclass=track

obj=vehicle
waytype=narrow_gauge

The problem is that some vehicles can operate on more than one such specific way type. Watercraft is a prime examples. These even overlap, so a simple category system like goods will not work.

[DrSuperGood]

How does experimental do it? They have separate ways types to some degree.

[jamespetts]

How does experimental do it? They have separate ways types to some degree.

Experimental's waytype system is unaltered from Standard; however, Experimental also has a way constraint system. That, however, as described above, is quite different in intention and implementation from waytypes.