[patch] Realistic Train Shunting
Moderator: OpenTTD Developers
Re: [patch] Realistic Train Shunting
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
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
- Attachments
-
- bluescreen.sav
- BEWARE CRASHES THE PC IF YOU START TRAIN 9 AND 13
- (109.5 KiB) Downloaded 138 times
Re: [patch] Realistic Train Shunting
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.
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.
Re: [patch] Realistic Train Shunting
Wow thanks that was fast.Karn wrote: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.
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
Re: [patch] Realistic Train Shunting
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
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
- Attachments
-
- train 2 crash.sav
- (109.93 KiB) Downloaded 203 times
-
- save before track reservation.sav
- (110.05 KiB) Downloaded 136 times
Re: [patch] Realistic Train Shunting
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.
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.
Re: [patch] Realistic Train Shunting
Thanks for the fast fix, runs fine now
Back to track more bugs down hehe
Cheers
Back to track more bugs down hehe
Cheers
Re: [patch] Realistic Train Shunting
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
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
- Attachments
-
- shunting-test.sav
- Test for shunting
- (110.95 KiB) Downloaded 129 times
Re: [patch] Realistic Train Shunting
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.TrueSatan wrote: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.
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!
- Attachments
-
- shunting-test (station upgrades).sav
- (112.86 KiB) Downloaded 135 times
Re: [patch] Realistic Train Shunting
Wow! I've tested it, and looks great!Karn wrote: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.
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...
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!Karn wrote: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.
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!
The French Narrow Gauge Train Set is now released! Get it here
Re: [patch] Realistic Train Shunting
Can you specify what engines and wagons fail to couple? I did quick testing and it all worked, so I need more information.Snail wrote:Wow! I've tested it, and looks great!Karn wrote: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.
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...
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...Snail wrote: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!Karn wrote: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.
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.
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.Snail wrote: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?
Also you said earlier "and its rods will appear to be running backwards" which implies it's problem only with certain engines?
Re: [patch] Realistic Train Shunting
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
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
- Attachments
-
- München Transport, 8th Jul 1982.sav
- (111.93 KiB) Downloaded 145 times
Re: [patch] Realistic Train Shunting
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...Karn wrote:Can you specify what engines and wagons fail to couple? I did quick testing and it all worked, so I need more information.Snail wrote: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...
Unfortunately, that's trueKarn wrote: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.Snail wrote: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!Karn wrote: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.
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.
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.Karn wrote: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...
Sure, you can look at this in my 2nd savegame. Train #3 is running in reverse and the steamer's rods are motionless.Karn wrote: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.Snail wrote: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?
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).Karn wrote:Also you said earlier "and its rods will appear to be running backwards" which implies it's problem only with certain engines?
Thanks in advance! These savegames should run with the GRF I sent you before, let me know if you need an updated one.
- Attachments
-
- Tours Transport, Jan 26th, 1910.sav
- failed to couple
- (346.78 KiB) Downloaded 138 times
-
- Tours Transport, Feb 10th, 1910.sav
- train running in reverse with motionless rods
- (343.62 KiB) Downloaded 125 times
-
- Tours Transport, Jan 11th, 1910.sav
- single locomotive running in reverse with rods animated in the wrong direction
- (345.7 KiB) Downloaded 131 times
The French Narrow Gauge Train Set is now released! Get it here
Re: [patch] Realistic Train Shunting
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.Snail wrote: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...
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?Snail wrote:Sure, you can look at this in my 2nd savegame. Train #3 is running in reverse and the steamer's rods are motionless.
Is the problem order of rods images or what's wrong? the direction seems to be alright?Snail wrote: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).
Re: [patch] Realistic Train Shunting
uhm, that's the only way it works? because the direction flipping variable is only updated for the front engine by the game.Karn wrote:It seems the engine rods depend on first vehicle in consist, which in my opinion should depend on vehicle itself
Re: [patch] Realistic Train Shunting
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.Eddi wrote:uhm, that's the only way it works? because the direction flipping variable is only updated for the front engine by the game.Karn wrote:It seems the engine rods depend on first vehicle in consist, which in my opinion should depend on vehicle itself
You are right about VRF_TOGGLE_REVERSE flag. It's invalid when it's only in front vehicle, that needs to be reworked here.
Re: [patch] Realistic Train Shunting
Thanks for looking into this!
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).
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.
The way I'm doing is already by referring to the vehicle itself:Karn wrote: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.Eddi wrote:uhm, that's the only way it works? because the direction flipping variable is only updated for the front engine by the game.Karn wrote:It seems the engine rods depend on first vehicle in consist, which in my opinion should depend on vehicle itself
Code: Select all
def(4) animation(
ref(0) if(0)
ref(1) if(1)
ref(2) if(2)
ref(3) else
)
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).
Yes, the problem is the order of the rods. They go 4-3-2-1 instead of 1-2-3-4.Karn wrote:Is the problem order of rods images or what's wrong? the direction seems to be alright?Snail wrote: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).
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.
The French Narrow Gauge Train Set is now released! Get it here
Re: [patch] Realistic Train Shunting
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.Snail wrote:Thanks for looking into this!
The way I'm doing is already by referring to the vehicle itself:Karn wrote: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.Eddi wrote:uhm, that's the only way it works? because the direction flipping variable is only updated for the front engine by the game.
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.Code: Select all
def(4) animation( ref(0) if(0) ref(1) if(1) ref(2) if(2) ref(3) else )
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 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.Snail wrote:Yes, the problem is the order of the rods. They go 4-3-2-1 instead of 1-2-3-4.Karn wrote:Is the problem order of rods images or what's wrong? the direction seems to be alright?Snail wrote: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).
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.
Re: [patch] Realistic Train Shunting
version 0.10.3:
Fixed bugs from Snail's 1st and 2nd save game.
Added 0(auto) for number of wagons to decouple
Fixed bugs from Snail's 1st and 2nd save game.
Added 0(auto) for number of wagons to decouple
Thank you for report. It's quite complicated bug. It will be fixed later.TrueSatan wrote: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
Re: [patch] Realistic Train Shunting
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.
Separate from this, trains seem to be getting a lifespan of 0 years when reversing, then returning to normal after reversing again:
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:
Re: [patch] Realistic Train Shunting
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.supermop wrote: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?
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.
Thanks for reporting bugs.supermop wrote: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
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.
Who is online
Users browsing this forum: Bing [Bot] and 35 guests