Driving backwards

[frosch]

When vehicles want to drive into the other direction, they have two options: Reversing or driving backwards.
The usual behaviour since TTD has been that trains just reverse in place. For a few years NewGRFs could evaluate a flag whether a train has reversed and then switch sprites to make the train appear as if it did not reverse, but would actually drive backwards.

However, this silly hack had countless limitations, is hyper complex for NewGRFs and effectively resulted in NewGRF authors wasting countless hours into a minor visual feature. During the last year tons of feature requests showed up, to add increasingly more hilarious variables to make sprites depend on weird criterions, just to make this "draw sprites in reverse" hack work in a few more cases.

Anyway, so much for the past. I think it is about time to stop this madness.
I have a working patch now, which allows trains to drive backwards, while the consists keep their arrangement. But well, obviously not all vehicles should drive backwards So this topic should be about figuring out the best options to control that aspect and the implications about it.

Mixed forward/backward traffic. The livestock wagons work fine as cab car. The last wagon accommodates educated animals with train driving licenses.

backward.png (88.31 KiB) Viewed 3668 times

I had some discussion with michi_cc the other day. The sum of things to consider boils down to about this:

• Some of the default vehicles should support driving backwards. Most likely the dual-headed ones.
• Reversing vs. backward driving should have a gameplay effect. E.g. by making "reversing" take some penalty time, while driving backwards starts immediately.
• There should be no difference between reversing in stations and at the end of the line. Reversing at end of lines is equally penalised.
• The former difficulty setting "allow reversing in stations" does not make a lot of sense. This has always been more of a pathfinder setting than a gameplay setting.
  So, maybe this setting should be moved to the order GUI, so players can select per order whether reversing/driving backwards is allowed, or RO-RO should be enforced.
  (effectively turning the advanced setting into a make-new-orders-default-to-this setting)
• This is about driving backwards, not about push-service. The first vehicle of a consist still must be an engine, because an engine in the front is what distinguishes assembled trains from free wagons in OpenTTD.
  However, NewGRF can (and already have in the past) provide cab cars which are technically engines, but provide no power (e.g. by setting power to 0 via CB 36).
• NewGRFs should be able to specify which vehicles can drive backwards, whether they provide power in some driving directions, and whether they can lead a consist (i.e. they can act as cab car).
• There should be an indication in the depot GUI and vehicle details whether a consist supports driving backwards.

Currently I consider these things to solve this:

• The reverse penalty time is fixed, and does not depend on the length of the consist.
• The depot view gains an icon between the train number and the first engine, showing either "<-" or "<->" to indicate the possible driving directions (including tooltip).
  The vehicle details display this icon per engine (in the information tab?).
• Default vehicles either provide the same power in both driving directions, or cannot drive backwards at all.
• Wagons can always drive backwards.
• Dual-headed engines default to "can drive backwards", while all other engines default to "cannot drive backwards".
• NewGRF gain an Action 0 property to control two aspects "this vehicle can drive backwards" and "this vehicle provides power when driving backwards".
  This will make consists drive backwards if there is at least one engine providing power backwards. Consists will reverse if at least one vehicle does not allow driving backwards, or none of the engines provide power backwards.
• NewGRF gain a flag in some VarAction2 variable, which indicates that a vehicle is driving backwards.
  This can be used to switch front/back lights or - if the NewGRF insists on - to change the power or speed when driving backwards (though I would consider that as rather bad for gameplay).
• The old "reverse" flag (var FF bit 0) stays in place. It is toggled when the vehicle reverses. It is not toggled when the vehicle switches between forward/backward driving.
  This should keep stuff compatible, while the flag is otherwise pretty useless.
• By default only engines (or articulated parts of engines) can lead a consist. Wagons gain a callback which is called for (the last articulated part of) the last wagon of a consist, and decides whether the wagon can act as cab car.

I am especially unsure about the cab car thingie: It seems to be common in various NewGRF sets to assemble multiple units using one engine and then attaching passenger/mail wagons to it, which display the image of an engine every n-th vehicle or at the back or similar. This scenario would require the callback to enable wagons in certain consists to act as cab car. OTOH this first/last vehicle business seems somewhat unsymmetric to me, since these wagons cannot be at the front of the consist in the depot. So maybe players should always have to build explicit engines resp. "cab car engines"?
Using dual headed engines might also solve the problem in some cases, but since dual-headedness is somewhat incompatible with being articulated, this cannot be the general solution.

[Michi_cc]

• Some of the default vehicles should support driving backwards. Most likely the dual-headed ones.
• Reversing vs. backward driving should have a gameplay effect. E.g. by making "reversing" take some penalty time, while driving backwards starts immediately.
• The reverse penalty time is fixed, and does not depend on the length of the consist.

To extend on that part a bit: The default vehicles (and many NewGRFs) can be divided into the common single-headed engines and a few dual-headed ones, which graphically are often modelled after MUs or fixed consists and can usually drive backwards in real life as well. Right now there's often no reason to prefer the one over the other except for the usual progression in speed and power.

I imagine the reversing penalty to be a fixed (NewGRF definable) time that specifies the minimum turn-around time, concurrently to the usual loading time. Imagine it as the time for the imaginary run-around of the engine. A train can reverse and depart if both the loading time and the turn-around time are over. In practice this would mean that for e.g. an intercity-ish service with many wagons (and in NewGRFs usually slower loading times) the determining time will be the loading time while for a short commuter service the turn-around time will be more significant. This mostly matches with how the original vehicles are designed and the logic dual-headed == reversing allowed by default holds.

As people will invariably want to model things like steam engines that had different top speeds for forward and backward, an order option to specify reversing or backward driving (akin to the stopping position) makes sense. Our poor order GUI...

IMNSHO this penalty should always apply or at most be a default on setting (even if it will mean big drama about suddenly broken self-regulating, cyclotron-ized and train-length sorted networks). Default off just means the vast majority of players will never see it, which would be a waste (and yes, I am very much guilty of that myself).

-- Michael Lutz

[Eddi]

almost all engines can provide power "backwards", provided there is an engine (or steering car) on the other end, so i'm not quite sure what the "can provide power only one way" idea is about...

[hargs]

Wouldn't this break most tendered steam engines if they were the at the back of a consist?

[PikkaBird]

I'm not sure I see the point, myself. Double-ended trains can already be given a shorter loading time by increasing the load rate, and tend to consist of identical vehicles whose graphics are easily swapped if the author so desires. On the other hand, trains where the locomotive "runs around" are where the "incorrect" flipping of a consist of mixed vehicles is most common. See attached image for further explanation.

whyImnotterriblyfussedbythispatch.png (65.17 KiB) Viewed 3668 times

almost all engines can provide power "backwards", provided there is an engine (or steering car) on the other end, so i'm not quite sure what the "can provide power only one way" idea is about...

I agree, I don't see where this is coming from. And in any case, if for some reason the author wants to have less/no power in reverse, they can use cb36 for that.

Wouldn't this break most tendered steam engines if they were the at the back of a consist?

I don't see it, please explain further.

[frosch]

Since the other discussion was split off, please continue on topic: Driving backwards while keeping the consist as it is.

So far I extract from the discussion that the driving direction does not matter for the engine. All engines can drive equally forward and backward, there is no particular composition that forbids driving backwards. The only thing that matters is, whether there is a cab at the driving side of the consist.

So, for default vehicles this simplifies to: Consists can drive backwards, if there is an engine or a read head of a dual headed engine at the end of the consist. Wrt. gameplay this means that the player can avoid the reversing penalty by either using a dual headed engine, or by purchasing two engines to put one at each end of the consist.

This would then also be the default for all NewGRF engines, including articulated engines. I.e. a steam engine in the back with the trailer leading would be fine according to those rules.
Alternatively articulated engines could be considered as not suitable for leading the consist when driving backwards, unless specifically enabled via some callback.

I imagine the reversing penalty to be a fixed (NewGRF definable) time that specifies the minimum turn-around time, concurrently to the usual loading time. Imagine it as the time for the imaginary run-around of the engine. A train can reverse and depart if both the loading time and the turn-around time are over. In practice this would mean that for e.g. an intercity-ish service with many wagons (and in NewGRFs usually slower loading times) the determining time will be the loading time while for a short commuter service the turn-around time will be more significant. This mostly matches with how the original vehicles are designed and the logic dual-headed == reversing allowed by default holds.

I don't quite get what you are heading for here. Originally I considered the penalty time fixed and not being influenced by NewGRF. What do you have in mind? Adding the penalty times of all vehicles in the consist to a total penalty time? Or taking the maximum of the penalty times?

I'm not sure I see the point, myself. Double-ended trains can already be given a shorter loading time by increasing the load rate, and tend to consist of identical vehicles whose graphics are easily swapped if the author so desires.

If your train consist of only the same vehicles, which all have the same length, and have no articulated parts.... Well, yes, then the old "reverse flag" method is sufficient. However, you are screwed once the graphics of the vehicle depend on the position in the consist, or the vehicles have different length, or there are different types of vehicles in the consist. Then you cannot just switch the front and back graphics, because you cannot just switch the stuff inbetween.
This patch is about providing an easy way to make a consist drive backwards as it is common for multiple units. If it also works for other consists, other than multiple units, then it is fine; but that is not necessarily the goal.

[Snail]

Even this feature sounds interesting.
A few of the points I made in the part of the thread that was split still apply here. Namely;

* Perhaps some engines would require the presence of a specific driving trailer to be able to drive in reverse (my example of the high-speed engines only being able to drive in reverse with a "long-distance" DT), so the ability could be assigned though a callback;
* It would be nice if we could optionally prevent some wagons from driving in the reverse. For instance, an old passenger coach might not have the right equipment, therefore if it's present in the consist, the train won't drive in reverse.

Any thoughts?

[Eddi]

Ok, since you apparently shy away from the complexity of the run-around suggestion, here is a simplified version:

every engine has a flag whether it can be controlled from another cab, if all engines in the consist have this flag set, and there is an engine on each end, then the consist can drive backwards. most modern engines would have this flag set, most steam engines would have this not set, meaning the driving backwards feature will only be available in later stages of the game. having a flag like this will enable GRFs to better control which consists can drive backwards and which not.

i'm unsure about default values here... setting any values for the default engines would propagate to NewGRFs which did not yet consider this property, which may potentially give undesired results in one way or the other. "historically", it was rather handled in a way that the default vehicles will not be changed, and you need a NewGRF (like OpenGFX+) to introduce the new features. (e.g. refitting)


Now which engines could sanely have this flag set? E.g. if you consider the DB around the 1970s, you have two engines BR 103 and BR 111 where currently the BR 103 is massively superiour because of its higher power and speed. If you omit the "can be controlled from other cab" from the BR 103, you create a niche for the BR 111, which would have this flag set.

[Snail]

I assume *both* engines (i.e. at each end) would need this flag to be set for this feature to work?

[Eddi]

i said "all engines", i.e. also the ones in the middle [depending on implementation details, this may cover your request about wagons preventing going backwards]

[frosch]

every engine has a flag whether it can be controlled from another cab, if all engines in the consist have this flag set, and there is an engine on each end, then the consist can drive backwards. most modern engines would have this flag set, most steam engines would have this not set, meaning the driving backwards feature will only be available in later stages of the game. having a flag like this will enable GRFs to better control which consists can drive backwards and which not.

How is this related to driving backwards? You can say the same to forbid consists driving forward when engines do not follow each other directly in the consist, can't you? So, this is rather something for a general start/stop check.

Perhaps some engines would require the presence of a specific driving trailer to be able to drive in reverse (my example of the high-speed engines only being able to drive in reverse with a "long-distance" DT), so the ability could be assigned though a callback;

Is this covered by the callback for the last wagon/engine which decides whether it can lead the consist?

It would be nice if we could optionally prevent some wagons from driving in the reverse. For instance, an old passenger coach might not have the right equipment, therefore if it's present in the consist, the train won't drive in reverse.

So, I guess a general flag for all vehicles, whether they can drive backwacks, or whether they enforce the consist to reverse.

[Snail]

Perhaps some engines would require the presence of a specific driving trailer to be able to drive in reverse (my example of the high-speed engines only being able to drive in reverse with a "long-distance" DT), so the ability could be assigned though a callback;

Is this covered by the callback for the last wagon/engine which decides whether it can lead the consist?

I think so. The last wagon/engine could check the "main" engine, and then decide whether driving in reverse is possible or not, through a callback.

It would be nice if we could optionally prevent some wagons from driving in the reverse. For instance, an old passenger coach might not have the right equipment, therefore if it's present in the consist, the train won't drive in reverse.

So, I guess a general flag for all vehicles, whether they can drive backwacks, or whether they enforce the consist to reverse.

Yes, that would do it. Again, it would be nice if this was set through a callback, so that the main engine can be checked before setting the flag.
I currently use userbits to do this, and such a flag would provide me with a better solution.

[Eddi]

so... no special engine flags, but a callback that is called for the last vehicle of the consist upon leaving the depot/rearranging in the depot which returns whether the consist can go backwards or not. (the callback can then check the userbits of all vehicles, or variables of itself and the front vehicle, or any other fancy whatnots.) if the callback fails, the consist can go backwards if there is an engine on each end. (means you can "cheat" around GRF limitations with the invisible engine GRF)

[Snail]

so... no special engine flags, but a callback that is called for the last vehicle of the consist upon leaving the depot/rearranging in the depot which returns whether the consist can go backwards or not. (the callback can then check the userbits of all vehicles, or variables of itself and the front vehicle, or any other fancy whatnots.) if the callback fails, the consist can go backwards if there is an engine on each end.

I think this sums it up.
Plus, a callback that tells us whether the train is driving in reverse or not (working in a similar way as the current callback which tells us is the consist is "reversed" or not). This would be useful to switch the lights, for instance.

I guess the power effects (smoke, sparks..) would automatically follow their respective vehicles even when driving in reverse? Like, a Diesel engine would keep its smoke even when pushing the train (assuming a driving trailer is attached on the other side)?

[Michi_cc]

I don't quite get what you are heading for here. Originally I considered the penalty time fixed and not being influenced by NewGRF. What do you have in mind? Adding the penalty times of all vehicles in the consist to a total penalty time? Or taking the maximum of the penalty times?

Maximum of all penalty times. Each vehicle gets a prop (+ CB36) for the turn-around time. Maybe it would indeed be superfluous (or could be used to "cheat" around the penalty), but all other vehicle properties can also be modified, so why make this an exception?

i'm unsure about default values here... setting any values for the default engines would propagate to NewGRFs which did not yet consider this property, which may potentially give undesired results in one way or the other.

For single engines it would probably have to be off, but for dual-headed engines it could be handled by implicitly setting the flag when you enable dual-head, with the possibility to override this by setting a (new) property afterwards.

-- Michael Lutz

[Eddi]

reversing times: there need to be two properties here, i think. one for the "traditional" reversing, and one for the "push-pull" reversing. measurement units would either be ticks or "loading steps"

the "traditional" reversing time would cover the time that is needed to detach the engine, turn it on a turntable [if necessary], go to the other end, reattach, and make a braking test.

the "push-pull" reversing time would cover the time the driver needs to go to the other end and take his seat there. (a CB36 could make this depend on train length and whatnot)

[crazy thought: if one could measure the distance travelled between two reversals, one could simulate refilling supplies by abusing the reversing time. but maybe that should be a completely separate feature]

[peter1138]

Plus, a callback that tells us whether the train is driving in reverse or not (working in a similar way as the current callback which tells us is the consist is "reversed" or not). This would be useful to switch the lights, for instance.

You are talking about variables, not callbacks.

[michael blunck]

Plus, a callback that tells us whether the train is driving in reverse or not (working in a similar way as the current callback which tells us is the consist is "reversed" or not). This would be useful to switch the lights, for instance.

You are talking about variables, not callbacks.

He´s talking about var FF.

[reversing times]

Isn´t this a bit over the top?

regards
Michael

[Snail]

You are talking about variables, not callbacks.

He´s talking about var FF.

Haha, sometimes I know the names of things in m4nfo, but not their "real" names

[AndersI]

reversing times

Isn´t this a bit over the top?

Or is it about game balancing?
(Says I, who haven't (yet) tried to balance the Swedish trains...)

(sorry, coming back to Real Life after a week with the flu and high(!) fever, and feeling the need to communicate with the world again)