[patch] Realistic Train Shunting

[TrueSatan]

Hey Karn,

sorry I don't like to bring bad news but... The attached savegame has to trains no 9 and 13,
if you start them to the same time the first trains is running towards its first destination
and well... it gives me a windows 10 bluescreen after the games crashes.
its repeatable.
Game is still vanilla no newgrfs.

Hope you can fix it

btw I can produce more crashes while fiddling with those new trains orders.
But I lost my crashsave for that, if i stumble over those other crashes again, i will
post them here.

Cheers

[Karn]

Thank you for bug report.
The game crash, but my pc and windows survive it. Problem was with first order set as inherit. I made a mistake with copying already deleted memory in such case.

Version 0.10.1 fix this and the attached save file in previous post is safe to load and use.

[TrueSatan]

Thank you for bug report.
The game crash, but my pc and windows survive it. Problem was with first order set as inherit. I made a mistake with copying already deleted memory in such case.

Version 0.10.1 fix this and the attached save file in previous post is safe to load and use.

Wow thanks that was fast.
I guess you were fast enough to click the small window with the error message.
Ig to plenty of them and then the crash.
Not always good to have some fast pc lol
I will test it l8er.
Cheers

[TrueSatan]

Next report,
This time I stopped train 2 because it made a strange and completely wrong track reservation.
First time I was thinking about how to setup train 9 and 13 again to learn what can be
done with those orders.
Then I got the notification that some train exploded in a huge fireball.

So I loaded the save game again and waited at the station where the crash happened.
The orders worked flawless before 10.1, so no clue what had happened
but the train with the number 2 shows the right order but reserves the track right into
the neighbor track and will crash there.
Maybe the train driver is on a suicide mission, but I doubt that. I pay them fairly lol

Thanks for looking into it.
I will try an earlier save again an try to stop the game right before the reversal of the track happens.Attached a save before the fatal track reservation happens

Cheers

[Karn]

Thanks for another report. I was already looking into it when you posted. I let your game run for a while to see if everything else is alright and it wasn't

Not that it's important, but driver was still thinking that he needs to find wagons after coupling. Then the order changed, but reservation stayed.
It was bug in v0.9 feature which let train decide to which direction go after coupling. For example if next station is behind the train, train would reverse, which is same as leaving station.

Anyway, there is fix for this 0.10.2 in the first post, hopefuly everything will be fine there.

[TrueSatan]

Thanks for the fast fix, runs fine now

Back to track more bugs down hehe

Cheers

[TrueSatan]

Okay besides hunting bugs i'm fooling around with the system.
Not sure if anyone is interested but the little attached save is coupling and decoupling
different trainlength together. So with these orders a switching yard would be possible.
Just start Train 9 and 13. Since 10.2 crash free

All thats needed are station tiles looking like a switchyard and that do not accept and provide
any goods. I know its possible but i am not sure if there are any of those around
and if they fulfill the need for a switching yard.

Nice work Karn

Cheers

[le_harv]

All thats needed are station tiles looking like a switchyard and that do not accept and provide
any goods. I know its possible but i am not sure if there are any of those around
and if they fulfill the need for a switching yard.

How about these? I used Industrial Station Renewal and New Stations (my personal favourite for yards) for the stations and Dutch Station Additions for waypoints.

Now I have seen your orders in action, I need to play this amazing patch some more. I have been playing JGR Patch Pack for so long you realise what you took for granted!

[Snail]

Version 0.10 released. This one is about fixing NewGRF glitches.
Technical explanation: parent VarAction2 properties 0xC6, 0xF2, 0x42 and first_engine are stored in vehicle and updated only during depot arranging and refitting. I tested it on several NewGRFs and it looked alright.

Wow! I've tested it, and looks great!
So, what I've done was to send a train to a station and order to decouple: now, the wagons are retaining their livery and properties, including their length.

However, I have a different problem now. When I send a locomotive out of a depot to "couple any train", the loco approaches the wagons I had decoupled before... but won't actually couple them. It will leave the station all alone instead.
This happens even I try to couple the same engine that had brought those wagons to the station in the first place, so it's obviously "compatible" with the wagons' properties...

NewGRF property for checking if vehicle is reversed is disabled, because there are NewGRFs doing own magic during reversing, which is obviously not compatible with this patch.

Hmm. I understand why you would do that, but unfortunately, this messes up my trains' lights and animation. For example, once a lonely steamer reverses, it won't switch its lights, and its rods will appear to be running backwards!
Would it be possible to re-enable the property that checks if the vehicle is reversed? I was planning to modify my set, by adding a parameter to disable my push-pull system so that it would handle your patch.

Lastly, I found another glitch. If I send a train pulled by an animated loco (for example, a steamer) to an end-of-line track and back, it will reverse, this time preserving the length and liveries of all the wagons in the consist. However, what is not preserved... is the locomotive animation! You will see the train being pushed by the steamer, but its rods are motionless. Does this have to do with the way you reverse the vehicles, perhaps ignoring animation?

Karn, I can PM you current my set if that'd be useful, although it didn't significantly change since the last time.

Keep up the good work!

[Karn]

Version 0.10 released. This one is about fixing NewGRF glitches.
Technical explanation: parent VarAction2 properties 0xC6, 0xF2, 0x42 and first_engine are stored in vehicle and updated only during depot arranging and refitting. I tested it on several NewGRFs and it looked alright.

Wow! I've tested it, and looks great!
So, what I've done was to send a train to a station and order to decouple: now, the wagons are retaining their livery and properties, including their length.

However, I have a different problem now. When I send a locomotive out of a depot to "couple any train", the loco approaches the wagons I had decoupled before... but won't actually couple them. It will leave the station all alone instead.
This happens even I try to couple the same engine that had brought those wagons to the station in the first place, so it's obviously "compatible" with the wagons' properties...

Can you specify what engines and wagons fail to couple? I did quick testing and it all worked, so I need more information.

NewGRF property for checking if vehicle is reversed is disabled, because there are NewGRFs doing own magic during reversing, which is obviously not compatible with this patch.

Hmm. I understand why you would do that, but unfortunately, this messes up my trains' lights and animation. For example, once a lonely steamer reverses, it won't switch its lights, and its rods will appear to be running backwards!
Would it be possible to re-enable the property that checks if the vehicle is reversed? I was planning to modify my set, by adding a parameter to disable my push-pull system so that it would handle your patch.

Well, that's a problem from past that OpenTTD carry on. Developers let NewGRF authors to fix reversing instead of doing it themself and now we have all kind of inconsistent behaviour. What could maybe work is using VRF_TOGGLE_REVERSE flag instead of VRF_REVERSING in the NewGRF for lights. I didn't find NewGRF that change reversing with VRF_TOGGLE_REVERSE so hopefuly that can be still supported. Other solution would be to move VRF_REVERSING flag to different action property to support NewGRFs that count with new way of reversing. However I would need political support for such move...

Lastly, I found another glitch. If I send a train pulled by an animated loco (for example, a steamer) to an end-of-line track and back, it will reverse, this time preserving the length and liveries of all the wagons in the consist. However, what is not preserved... is the locomotive animation! You will see the train being pushed by the steamer, but its rods are motionless. Does this have to do with the way you reverse the vehicles, perhaps ignoring animation?

Can you give example of such locomotive? I have no animation problems. I assume all animation is based on motion counter, which I didn't touch even remotely, that's another strange bug.

Also you said earlier "and its rods will appear to be running backwards" which implies it's problem only with certain engines?

[TrueSatan]

Okay.. next bug please
If you enable forbid 90° turns for trains
the shunting wents wrong in "Wertwald"
First coupling of three wagons is okay, but
if the second three wagons are coupled the train should
"stay" (means decouple in Wertwald again)

Instead it pushes the train out of the station to
Hamhaven North (or to the depot there)

Only happens with the 90° turning option on.
Dunno if its by design.

You can use the save attached and turn on the 90° setting
and wait at Wertwald to see whats happening.

Cheers

[Snail]

However, I have a different problem now. When I send a locomotive out of a depot to "couple any train", the loco approaches the wagons I had decoupled before... but won't actually couple them. It will leave the station all alone instead.
This happens even I try to couple the same engine that had brought those wagons to the station in the first place, so it's obviously "compatible" with the wagons' properties...

Can you specify what engines and wagons fail to couple? I did quick testing and it all worked, so I need more information.

Sure, please see the first savegame. I'm trying to send my "230T" steamer to couple a bunch of wagons the same engine had decoupled before. Once the engine reaches the wagons, I get the "failed to couple" message...

NewGRF property for checking if vehicle is reversed is disabled, because there are NewGRFs doing own magic during reversing, which is obviously not compatible with this patch.

Hmm. I understand why you would do that, but unfortunately, this messes up my trains' lights and animation. For example, once a lonely steamer reverses, it won't switch its lights, and its rods will appear to be running backwards!
Would it be possible to re-enable the property that checks if the vehicle is reversed? I was planning to modify my set, by adding a parameter to disable my push-pull system so that it would handle your patch.

Well, that's a problem from past that OpenTTD carry on. Developers let NewGRF authors to fix reversing instead of doing it themself and now we have all kind of inconsistent behaviour.

Unfortunately, that's true

What could maybe work is using VRF_TOGGLE_REVERSE flag instead of VRF_REVERSING in the NewGRF for lights. I didn't find NewGRF that change reversing with VRF_TOGGLE_REVERSE so hopefuly that can be still supported. Other solution would be to move VRF_REVERSING flag to different action property to support NewGRFs that count with new way of reversing. However I would need political support for such move...

Hmm, ok... So I guess I'll have to use another m4nfo function? So far I'm using "reversed()". We might have to wait until MB is back from his vacation for this one.

Lastly, I found another glitch. If I send a train pulled by an animated loco (for example, a steamer) to an end-of-line track and back, it will reverse, this time preserving the length and liveries of all the wagons in the consist. However, what is not preserved... is the locomotive animation! You will see the train being pushed by the steamer, but its rods are motionless. Does this have to do with the way you reverse the vehicles, perhaps ignoring animation?

Can you give example of such locomotive? I have no animation problems. I assume all animation is based on motion counter, which I didn't touch even remotely, that's another strange bug.

Sure, you can look at this in my 2nd savegame. Train #3 is running in reverse and the steamer's rods are motionless.

Also you said earlier "and its rods will appear to be running backwards" which implies it's problem only with certain engines?

I tested a bunch of them, and the problem persists. See the 3rd savegame for this (the 230T is running backwards, and its rods have the opposite animation as they should have: they're running forward).

Thanks in advance! These savegames should run with the GRF I sent you before, let me know if you need an updated one.

[Karn]

Sure, please see the first savegame. I'm trying to send my "230T" steamer to couple a bunch of wagons the same engine had decoupled before. Once the engine reaches the wagons, I get the "failed to couple" message...

Thank you for your assistance. First save shows problem with reversing articulated vehicles. It's my patch design flaw, when reversed articulated vehicle parts have switched parts and IDs don't match the NewGRF arragnment specification and cause problem with autoreplace too. I'll try to fix this in the near future.

Sure, you can look at this in my 2nd savegame. Train #3 is running in reverse and the steamer's rods are motionless.

Second save is in my opinion more of bad design of NewGRF. It seems the engine rods depend on first vehicle in consist, which in my opinion should depend on vehicle itself, because it's graphic part of the vehicle. This design makes it impossible to connect different engines together. Which I see is plan, but may be problem in the future changes?

I tested a bunch of them, and the problem persists. See the 3rd savegame for this (the 230T is running backwards, and its rods have the opposite animation as they should have: they're running forward).

Is the problem order of rods images or what's wrong? the direction seems to be alright?

[Eddi]

It seems the engine rods depend on first vehicle in consist, which in my opinion should depend on vehicle itself

uhm, that's the only way it works? because the direction flipping variable is only updated for the front engine by the game.

[Karn]

It seems the engine rods depend on first vehicle in consist, which in my opinion should depend on vehicle itself

uhm, that's the only way it works? because the direction flipping variable is only updated for the front engine by the game.

I'm not sure if we are at the same page with this. I'm talking about Snail's NewGRF that he develops. I pointed out the rods graphic should be connected to engine itself and not front vehicle of consist. This way it has very limited use.

You are right about VRF_TOGGLE_REVERSE flag. It's invalid when it's only in front vehicle, that needs to be reworked here.

[Snail]

Thanks for looking into this!

It seems the engine rods depend on first vehicle in consist, which in my opinion should depend on vehicle itself

uhm, that's the only way it works? because the direction flipping variable is only updated for the front engine by the game.

I'm not sure if we are at the same page with this. I'm talking about Snail's NewGRF that he develops. I pointed out the rods graphic should be connected to engine itself and not front vehicle of consist. This way it has very limited use.

The way I'm doing is already by referring to the vehicle itself:

Code: Select all

def(4) animation(
         ref(0) if(0) 
         ref(1) if(1)
         ref(2) if(2)
         ref(3) else
)

This is how I do it in m4nfo, where c-IDs "0" to "3" refer to the single animation frames. I'm not explicitly connecting this to the front vehicle of the consist (that would be achieved using an "engine()" syntax). Not sure about what's going on behind the scenes.

Also, my set allows for multiple traction and it works well: in other words, animated vehicles already work correctly even if they're not the first vehicle of the consist (you can test it yourself with the GRF I sent you).

I tested a bunch of them, and the problem persists. See the 3rd savegame for this (the 230T is running backwards, and its rods have the opposite animation as they should have: they're running forward).

Is the problem order of rods images or what's wrong? the direction seems to be alright?

Yes, the problem is the order of the rods. They go 4-3-2-1 instead of 1-2-3-4.
This is already an issue when a player manually flips the engine in a depot. I've actually coded animation in two ways, forward and backward, and my code chooses which way to display depending on flipping and reversing.
My guess is that this glitch is due to your patch disabling the "reversed" variable: in other words, it's the same issue as the lights.

[Karn]

Thanks for looking into this!

uhm, that's the only way it works? because the direction flipping variable is only updated for the front engine by the game.

I'm not sure if we are at the same page with this. I'm talking about Snail's NewGRF that he develops. I pointed out the rods graphic should be connected to engine itself and not front vehicle of consist. This way it has very limited use.

The way I'm doing is already by referring to the vehicle itself:

Code: Select all

def(4) animation(
         ref(0) if(0) 
         ref(1) if(1)
         ref(2) if(2)
         ref(3) else
)

This is how I do it in m4nfo, where c-IDs "0" to "3" refer to the single animation frames. I'm not explicitly connecting this to the front vehicle of the consist (that would be achieved using an "engine()" syntax). Not sure about what's going on behind the scenes.

Also, my set allows for multiple traction and it works well: in other words, animated vehicles already work correctly even if they're not the first vehicle of the consist (you can test it yourself with the GRF I sent you).

Okay, never mind, the problem is in code. Motion counter is not updated when a wagon is in front of train. Pretty silly mistake from me, based on few assumptions There will be fix in upcoming version.

I tested a bunch of them, and the problem persists. See the 3rd savegame for this (the 230T is running backwards, and its rods have the opposite animation as they should have: they're running forward).

Is the problem order of rods images or what's wrong? the direction seems to be alright?

Yes, the problem is the order of the rods. They go 4-3-2-1 instead of 1-2-3-4.
This is already an issue when a player manually flips the engine in a depot. I've actually coded animation in two ways, forward and backward, and my code chooses which way to display depending on flipping and reversing.
My guess is that this glitch is due to your patch disabling the "reversed" variable: in other words, it's the same issue as the lights.

I will investigate how motion_counter overflows and maybe it could be possible to count backwards for reversing. Otherwise it will be fixed some time in future when I'll be sure about messing with NewGRF compatibility outside of this patch.

[Karn]

version 0.10.3:
Fixed bugs from Snail's 1st and 2nd save game.
Added 0(auto) for number of wagons to decouple

Okay.. next bug please
If you enable forbid 90° turns for trains
the shunting wents wrong in "Wertwald"
First coupling of three wagons is okay, but
if the second three wagons are coupled the train should
"stay" (means decouple in Wertwald again)

Instead it pushes the train out of the station to
Hamhaven North (or to the depot there)

Only happens with the 90° turning option on.
Dunno if its by design.

You can use the save attached and turn on the 90° setting
and wait at Wertwald to see whats happening.

Cheers

Thank you for report. It's quite complicated bug. It will be fixed later.

[supermop]

I've been playing with 10.2 a bit, and so far so good... I wonder if you could clarify the intended use cases of keep orders and inherit orders for me. For a locomotive at the head of the train that 'runs around' to the other end at end of line, everything is clear and works fine. For a second locomotive that attaches to front or rear of the train for just a portion of the journey, it is unclear to me how orders will be handled after that decoupling -- that is, can the parts of a decoupled train go on to do distinct actions, or will the 'orphaned' part of the train always just dumbly await coupling? I am trying to use this to pull trains out of terminus tracks, but I think the common case would be 'banking' engines (extra locomotive attaches at bottom of hill, detaches after pulling train over hill, awaits next train to help while the original continues per orders). In this case, after the decoupling, the original train needs to retain its ongoing orders, and the banking engine needs to retain its "wait to help" orders. Is this possible?


Another issue I've noticed are odd gaps in the timetable, not just immediately around coupling movements. In the attached image, I understand why there is no time given between arriving at the station and the decouple order (underlined in blue), as these happen at the same time. However, I am not clear on why travelling from the previous station to the station where the decoupling happens (red) is also not timetabled.

travel time.PNG

(19.32 KiB) Not downloaded yet

Separate from this, trains seem to be getting a lifespan of 0 years when reversing, then returning to normal after reversing again:

age.PNG

After Reversing at end of line, age 7 out of 0 years...

(58.64 KiB) Not downloaded yet

age2.PNG

After reversing again, all is normal: 8 out of 25 years.

(47.5 KiB) Not downloaded yet

[Karn]

I've been playing with 10.2 a bit, and so far so good... I wonder if you could clarify the intended use cases of keep orders and inherit orders for me. For a locomotive at the head of the train that 'runs around' to the other end at end of line, everything is clear and works fine. For a second locomotive that attaches to front or rear of the train for just a portion of the journey, it is unclear to me how orders will be handled after that decoupling -- that is, can the parts of a decoupled train go on to do distinct actions, or will the 'orphaned' part of the train always just dumbly await coupling? I am trying to use this to pull trains out of terminus tracks, but I think the common case would be 'banking' engines (extra locomotive attaches at bottom of hill, detaches after pulling train over hill, awaits next train to help while the original continues per orders). In this case, after the decoupling, the original train needs to retain its ongoing orders, and the banking engine needs to retain its "wait to help" orders. Is this possible?

Use case for dividing orders is entering terminus station in reversed state (the loco pushing wagons) and then the loco can go somewhere else. It's meant for small cargo terminus stations. Or it can be used for some kind of shunting yard.

Autonomous banking engines and shunting train out of "passanger" terminus station by other engine is not possible with current orders. Those orders as they are just prepare ground for the future update.

Edit: the terminus shunting with other engine is currently not supported because of how train looks for other train. It allows only one train in station platform. This is planned to be changed too, there wasn't use case for this so far.

To support those operations, we will need arbitrary orders for both decoupled parts. There was suggestion to make it in a faster "hack" way with "contitional jump", but I personaly dislike those hacks in gui, it's annoying for gameplay and usually brings unwanted special cases. Basically what should solve all this is implementation of independent orders list, which I call global order list, that could store future orders of both train parts. But it will take a while to implement.

Another issue I've noticed are odd gaps in the timetable, not just immediately around coupling movements. In the attached image, I understand why there is no time given between arriving at the station and the decouple order (underlined in blue), as these happen at the same time. However, I am not clear on why travelling from the previous station to the station where the decoupling happens (red) is also not timetabled.

Separate from this, trains seem to be getting a lifespan of 0 years when reversing, then returning to normal after reversing again

Thanks for reporting bugs.
Timetables are not handled at all at current implementation, they need support in source code. I'll add it to bug list and fix it later.

Lifespan of vehicle in trunk is too simple, it's just first vehicle's property, it wasn't updated in this patch yet. The topic is actually breakdowns, which is currently inconsistent too. It's another bigger future fix.