moving engine to other end

[Eddi]

[edit]
This was split from "driving backwards", extending the behaviour of what should happen when a consist reverses in a station/at the end of the track.
this suggestion does not cover shunting in the sense of exchanging wagons between consists. it also does not cover actually seeing the movement process, only the final result.
[/edit]

i agree with most of what Pikka said (as far as i understood it)

from what i can see, there are four modes of operation that would be desireable:

1. the whole consist is reversed (old behaviour, may stay for backwards compatibility or corner cases only)
2. the engine is reversed and moved to the other end, wagon chain stays the same (slowest, used for most steam engines with extra tender)
3. the engine stays the same but is moved to the other end, wagon chain stays the same (faster, used for steam engines with builtin tender and most modern engines)
4. the whole consist stays the same and goes backwards (fastest, for dual-headed and cab-controled consists)

for cases 2 and 3 there needs to be a way to define which vehicles get "run around" the train (by default, all engines, not just the first engine)

engines would get a flag "can run both ways" (enables mode 3) and "can be controlled from other end (enables mode 4 if both ends have a suitible vehicle). flags can be defined by CB36, if NewGRFs want to do fancy checks on the consist

[PikkaBird]

for cases 2 and 3 there needs to be a way to define which vehicles get "run around" the train (by default, all engines, not just the first engine)

People are going to hate me for this, but, a callback? I love me some callbacks!

Run a callback when the train reverses, checking each vehicle in turn starting with the first vehicle in the train. Return "1" to indicate that this is the beginning of the reversable consist.

If every vehicle in the train returns 0, then every vehicle is a "head" vehicle and jumps - this is the old default behaviour.
If the first vehicle in the train returns 1, then the whole consist reverses - this is the behaviour in this patch.
If the first x vehicles return 0 and then a vehicle returns 1, then the first x vehicles jump and the remainder reverse - this is "running around" behaviour.

The difference between your case 2 and 3 I'd say should be handled with variational graphics, as it is now.

However, I'd say that we're getting away from the original feature; what we're suggesting is much more complex, and involves vehicles swapping positions rather than the whole train simply running backwards. So unless this is something that frosch and michi wish to pursue, let's leave it here.

[PikkaBird]

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).

The dangers of falling in love with your own features.

Given that most "cyclotron" builders use all-ro-ro networks and symmetrical trains, would they notice it anyway?

[hargs]

I don't see it, please explain further.

Sorry it's just me reading it wrong it seems.

[Eddi]

The difference between your case 2 and 3 I'd say should be handled with variational graphics, as it is now.

i'm sorry, but this is a nightmare with articulated vehicles of different lengths... means you will have the same problems as before, and this patch is just useless

[Snail]

The difference between your case 2 and 3 I'd say should be handled with variational graphics, as it is now.

i'm sorry, but this is a nightmare with articulated vehicles of different lengths... means you will have the same problems as before, and this patch is just useless

Agree. If this potentially great feature gets implemented, it will also have to deal with Eddi's cases 2 and 3. If it doesn't, I'm afraid it won't help much (my code would remain just as complicated as it is now, and subject to the same limitations).
With respect of the other features:

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).

This would be definitely needed. Right now I use the "reversed" callback to switch lights when I implement push-pull; if that callback now only indicates whether the train has graphically reversed or not (i.e. magically flipped at an end-of-line, and not doing push-pull), there should be a callback that tells us whether the train is driving in the reverse. To correctly switch the lights, or anything else it might be sensible to change (max speed, for instance).

Another thing I'd like to point out, is that not every engine might be able to do push-pull with any available driving trailer, at any point in time. A newGRF should still be able to disallow push-pull if the combination between engine and DT is "wrong", or whether the consist includes wagons that don't support push-pull. For instance, a high-speed long-distance engine might be able to do PP only with a "long-distance" DT and not with a "commuter" one. Of course, the newGRF author should always explain this in the engine's help text in the purchase menu.

Other than that, I'm looking forward to this new patch!

[Eddi]

let me elaborate on how i think the feature can work:
in the following i use the cases:

• W=any unpowered wagon
• E1 = any engine (including cab cars)
• E2 = any engine that can run equally well forwards and backwards (flag 1)
• E3 = any engine that can be controlled by a cab car/other engine (flag 2, implies flag 1)

Upon leaving the depot, it is determined whether the consist can perform one of the actions defined in my previous post, by the following regular expressions:

• Action 4 (push-pull): (E3 [W E3]* E3)|(E2) [controllable engine or cab on each end and only controllable or unpowered vehicles inbetween, or a single engine (e.g. railcar)]
  The consist goes backwards without any further modifications
• Action 3 (run-around without flipping): E2+ W+ [any number of homogenous engines followed by any number of homogenous wagons]
  The consist gets rearranged so the engines are on the other end in the same order, then goes backwards
• Action 2 (run-around with flipping): E1+ W+ [any number of homogenous engines followed by any number of homogenous wagons]
  The consist gets rearranged so the engines are on the other end in the reverse order, then goes backwards
• Action 1 (flip whole consist): any other cases not matching above formula
  The consist gets reversed and then goes backwards (old behaviour)

IMPORTANT NOTE: "run around" is used in a logical context, not a physical context. the engine does NOT use any tracks to go to the other end, it is just magically placed there (so the consist uses nothing more than the platform it occupies)

I hope that sufficiently clears up what i meant above.

[Snail]

100% agree. I think you could explain it much better than my short message could
Only things I would add:
* the E2 - E3 status should ideally be changeable through a callback, to allow an engine to drive in the reverse only in the presence of a specific driving trailer (as opposed to "any driving trailer")
* I agree with Frosch's idea to allow all wagons to drive in reverse by default, but it would be nice if we could optionally disallow this feature for certain wagons. So, if any wagon that can't drive in reverse is present in the train, the consist won't drive in reverse.

This feature would be very useful. Many of my set's playtesters tried it out and apparently liked it a lot.

[Michi_cc]

* Action 3 (run-around without flipping)
* Action 2 (run-around with flipping)

Implementing these two actions would be quite tricky. Both the code and the NewGRF specs generally assume the first vehicle in a chain is an engine. Rearranging the wagons wouldn't play very well with the various relative references in the specs (and livery overrides etc.). You could solve that by keeping a separate visual chain, but meh...

[michael blunck]

This is interesting, although I fear the original proposal won´t bring much additional usage for rail set coders. Nevertheless, inclusion of push-pull trains into today´s rail sets has developed into a must meanwhile, and a feature to easily allow this should be implemented preferably sooner than later. In the light of this, it´s at least a good sign that a OTTD developer is adressing this feature in a quasi-official way.

[Disclaimer: I´m not talking about "shunting" - someone else changed the topic title]

regards
Michael

[wallyweb]

These are questions born out of ignorance, so please be kind with your replies.

I assume we are talking about the ability of a train to run in reverse (backing up). To my simple mind, "shunting" implies a train pushing some wagons onto perhaps a siding, dropping the consist (decoupling/disconnecting), and then pulling out in the direction from which it entered the siding. Assuming that decoupling remains impossible in the TTD/OTTD game code, then reversing direction appears to be the core of the question.

Assuming that there is an algorithm that regulates the train's motion by shifting sprites in a forward direction, how difficult would it be to introduce a negative value into that algorithm so that the sprites are shifted in the opposite direction?

Somewhere I seem to have seen mentioned that in the TTD/OTTD code, be it a cab control car or an engine, one or the other must always lead in the direction travelled. Why?

How is the consist assembled? Is it an array? How do the wagons know to follow the lead vehicle? If the entire consist (array) moves as a unit, would it not be possible to amend the code such that motion is applied to the array as whole rather than just the leading vehicle?

EDIT: I just noticed the change to the topic name to "moving engine to other end" so it would seem that this is not the topic for my question ... or is it?

[Eddi]

i gave a short summary in the first post, to clarify the context and what this is not about...

[wallyweb]

i gave a short summary in the first post, to clarify the context and what this is not about...

Appologies Eddi ... It would seem we posted at the same time.
Is there anything in my question(s) that might apply to this discussion? Perhaps the part about arrays?

[Eddi]

i'm not familiar with all the details, so the following may be a slightly simplified version of how it actually works, but the vehicles internally are a linked list (i.e. each vehicle has a "next" pointer). moving in negative direction has the problem that things like path reservation, entering tiles, and updating signals must happen from the other end, and thus the movement code must loop backwards through the vehicle chain (i.e. using the "prev" pointer). apparently this has been achieved by frosch123, hence why he opened the other topic. (but i have no insight into how his patch implements this)

furthermore, there must be a dedicated "front" vehicle which stores all the cached values like max speed, train weight etc. i don't think there are many places in the code which actually require this to be an engine, since all vehicles have the appropriate data storage (only their values are ignored if they do not act as front engine currently). only the depot will prevent a vehicle chain from acting as a train if there is no engine in the front.

this topic is an extension to that idea, in the sense that additionally to driving backwards, the consist is rearranged in certain cases, which adds another layer of complexity (especially with NewGRFs which act on how the consist is arranged), and apparently that was too much for frosch123, so he had the topic split off.

[wallyweb]

Would it be possible to replace the linked list with an array where each cell is a vehicle in the consist and the appropriate data storage would be applied to the array rather than any one vehicle? This way your engine move would be a simple shifting of the appropriate cell(s)?

[Supercheese]

Would it be possible to replace the linked list with an array where each cell is a vehicle in the consist and the appropriate data storage would be applied to the array rather than any one vehicle? This way your engine move would be a simple shifting of the appropriate cell(s)?

Err... what?

[Eddi]

this would be possible, but it would be a major restructuring of the game's architecture, which comes with a lot of problems (and especially a lot of work)

the main problem is not actually the moving, but the compatibility with NewGRFs which did not expect consists to be modified outside of a depot, and thus the graphics or callback results may return values that they should not. to resolve this, you need to remember both how the consist was originally arranged and how the consist is currently displayed/moved (and then an array is not the optimal solution anyway)

[wallyweb]

this would be possible, but it would be a major restructuring of the game's architecture, which comes with a lot of problems (and especially a lot of work)

Yes ... I can certainly appreciate that. Thanks for the reply. All good to know.