Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Thu Oct 18, 2018 11:28 pm

All times are UTC




Post new topic  Reply to topic  [ 159 posts ]  Go to page Previous 14 5 6 7 8 Next
Author Message
PostPosted: Thu Aug 09, 2018 9:27 am 
Offline
Transport Coordinator
Transport Coordinator

Joined: Wed Jul 16, 2003 6:33 pm
Posts: 283
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


Attachments:
File comment: BEWARE CRASHES THE PC IF YOU START TRAIN 9 AND 13
bluescreen.sav [109.5 KiB]
Downloaded 9 times
Top
   
PostPosted: Thu Aug 09, 2018 10:00 am 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
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.


Top
   
PostPosted: Thu Aug 09, 2018 10:46 am 
Offline
Transport Coordinator
Transport Coordinator

Joined: Wed Jul 16, 2003 6:33 pm
Posts: 283
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.

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


Top
   
PostPosted: Thu Aug 09, 2018 3:17 pm 
Offline
Transport Coordinator
Transport Coordinator

Joined: Wed Jul 16, 2003 6:33 pm
Posts: 283
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


Attachments:
train 2 crash.sav [109.93 KiB]
Downloaded 6 times
save before track reservation.sav [110.05 KiB]
Downloaded 8 times
Top
   
PostPosted: Thu Aug 09, 2018 4:55 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
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 :D

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.


Top
   
PostPosted: Thu Aug 09, 2018 5:08 pm 
Offline
Transport Coordinator
Transport Coordinator

Joined: Wed Jul 16, 2003 6:33 pm
Posts: 283
Thanks for the fast fix, runs fine now :bow:

Back to track more bugs down hehe

Cheers


Top
   
PostPosted: Thu Aug 09, 2018 6:07 pm 
Offline
Transport Coordinator
Transport Coordinator

Joined: Wed Jul 16, 2003 6:33 pm
Posts: 283
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 :D

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 :bow:

Cheers


Attachments:
File comment: Test for shunting
shunting-test.sav [110.95 KiB]
Downloaded 11 times
Top
   
PostPosted: Thu Aug 09, 2018 6:46 pm 
Online
Engineer
Engineer

Joined: Sat Sep 27, 2014 5:16 am
Posts: 57
Location: Calgary, Canada
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.


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!


Attachments:
shunting-test (station upgrades).sav [112.86 KiB]
Downloaded 9 times
Top
   
PostPosted: Fri Aug 10, 2018 3:17 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Apr 28, 2003 6:52 pm
Posts: 1194
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.


Wow! I've tested it, and looks great! :D
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...

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.

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!


Top
   
PostPosted: Fri Aug 10, 2018 6:35 am 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
Snail wrote:
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.


Wow! I've tested it, and looks great! :D
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.

Snail wrote:
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.

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

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?

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?


Top
   
PostPosted: Fri Aug 10, 2018 8:50 am 
Offline
Transport Coordinator
Transport Coordinator

Joined: Wed Jul 16, 2003 6:33 pm
Posts: 283
Okay.. next bug please :D
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 8 times
Top
   
PostPosted: Fri Aug 10, 2018 12:55 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Apr 28, 2003 6:52 pm
Posts: 1194
Karn wrote:
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...

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

Karn wrote:
Snail wrote:
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.

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 :(

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

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:
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?

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.

Karn wrote:
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.


Attachments:
File comment: failed to couple
Tours Transport, Jan 26th, 1910.sav [346.78 KiB]
Downloaded 9 times
File comment: train running in reverse with motionless rods
Tours Transport, Feb 10th, 1910.sav [343.62 KiB]
Downloaded 9 times
File comment: single locomotive running in reverse with rods animated in the wrong direction
Tours Transport, Jan 11th, 1910.sav [345.7 KiB]
Downloaded 8 times
Top
   
PostPosted: Sat Aug 11, 2018 10:26 am 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
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...

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, 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?

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

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


Top
   
PostPosted: Sat Aug 11, 2018 1:34 pm 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 7159
Karn wrote:
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.

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Sat Aug 11, 2018 1:59 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
Eddi wrote:
Karn wrote:
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.


Top
   
PostPosted: Sat Aug 11, 2018 3:11 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Mon Apr 28, 2003 6:52 pm
Posts: 1194
Thanks for looking into this!

Karn wrote:
Eddi wrote:
Karn wrote:
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:
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).

Karn wrote:
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).

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.


Top
   
PostPosted: Sat Aug 11, 2018 4:42 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
Snail wrote:
Thanks for looking into this!

Karn wrote:
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.

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:
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 :oops: There will be fix in upcoming version.
Snail wrote:
Karn wrote:
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).

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.


Top
   
PostPosted: Sun Aug 12, 2018 10:12 am 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
version 0.10.3:
Fixed bugs from Snail's 1st and 2nd save game.
Added 0(auto) for number of wagons to decouple

TrueSatan wrote:
Okay.. next bug please :D
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.


Top
   
PostPosted: Sun Aug 12, 2018 2:29 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sun Feb 21, 2010 12:15 am
Posts: 1031
Location: Fitzroy North - 96
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.

Attachment:
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:

Attachment:
File comment: After Reversing at end of line, age 7 out of 0 years...
age.PNG [58.64 KiB]
Not downloaded yet

Attachment:
File comment: After reversing again, all is normal: 8 out of 25 years.
age2.PNG [47.5 KiB]
Not downloaded yet

_________________
Image
Trolleybi! Trucks and Buses -- Docklands -- Unspooled -- MLSS


Top
   
PostPosted: Sun Aug 12, 2018 4:06 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
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?

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.

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

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.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 159 posts ]  Go to page Previous 14 5 6 7 8 Next

All times are UTC


Who is online

Users browsing this forum: le_harv and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2018 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2018.
Hosted by Zernebok Hosting.