The International Simutrans Forum


Author Topic: Improvement of the convoy detail window  (Read 1595 times)

0 Members and 1 Guest are viewing this topic.

Online Matthew gb

  • *
  • Posts: 316
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Improvement of the convoy detail window
« Reply #35 on: February 03, 2020, 10:51:01 PM »
Teriyaki is an awesome sauce from Japan.
In this patch and the new depot GUI, Ranran has provided us with awesome source (code) from Japan!

Now that they are part of the Bridgewater-Brunel nightly, it seems a good moment to thank Ranran for all his work on them. They're really a great improvement to the game.

Good luck to all of you sorting out these details. It looks very complicated!

Offline Freahk

  • *
  • Posts: 577
  • Languages: DE, EN
Re: Improvement of the convoy detail window
« Reply #36 on: February 04, 2020, 12:22:38 AM »
Thank you Ranran for all the great Teriyaki sauce code implementing those extremely useful features.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Improvement of the convoy detail window
« Reply #37 on: February 04, 2020, 04:15:36 PM »
Yeah, thanks Ranran for the implementation.

First we have to distinguish between two types of "unidirectional" vehicles:
1. that have only one cab, but can run at full speed backwards, if coupled back-to-back with twin engine, or with appropriate cab car, i.e <__) or <__|   (typically EMU/DMU front units)
2. those that can run backwards, but at limited speed - typically steam tender engines, as there was a risk of derailing if running tender first. However I think that if coupled back to back, they would run just fine. Although this was probably very unusual to do.
3. those that cannot run backwards and back-to-back coupling does not make sense - all road vehicles, ships and planes. Also trams with doors only on one side. This is also often enforced via constraints.
But I do not see much reason to distinguish graphically between them.

For reversal purposes, we should consider #1 (and #2) as unidirectional only if it is running alone - without its twin engine, or cab car. Otherwise the whole twin-set should be treated as one bidirectional engine, or with cab car the whole train treated as EMU/DMU.
The presence of unidirectional vehicles does not necessarily mean that rotating the whole train is necessary. Usually only the engine would be rotated and shunted to the other side. Even if there are more of them. But some unusual combinations might be easier to rotate using wye.

- if there is no cab at the end, all vehicles from the front up to the first one with a cab on the backside will move to the back.
Unfortunately it is not that simple. You forgot about brake vans that have to also move to the other end. I described the algorithm in detail in,15766.msg180025.html#msg180025
I don't know how much of it ranran really implemented.

Regarding can_use_cab_car flag - that would be nice. The question is how deep we should go. Should it be just a flag, or multi value specifying which type of remote control is used? Should then be there a corresponding flag "cab_car_type" on cab_cars and "remote_control_passthrough" on intermediate cars? This was discussed earlier, together with group constraints and other features like train heating, brake and coupling types. But no consensus was found, what would work and still be playable. Also note that helper steam engines were used (both pulling and pushing trains) without any remote control. All were manned and comunicated using whistle signals.