News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Bug: Drive by sight convoy skipping stops at intersection

Started by DrSuperGood, February 25, 2018, 12:29:01 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DrSuperGood

When a drive by sight convoy is blocked by another convoy when going around a corner at an intersection it will skip stops in its schedule. Other convoys that then try to enter the intersection might also skip stops. They might even try to reach a stop they cannot get to due to distance.

Attached is save. When save loads, simply start convoy from depot and immediately select it and watch the destination. When it bumps into the waiting convoy it will change from Station 4 (where waiting convoy is) to Station 1 (opposite side of 1 way sign). Correct behaviour is to stick to trying to go to station 4 even if a convoy is in the way.

jamespetts

Thank you for your report: I have now found and, I believe, fixed this issue. I should be grateful if you could let me know whether this has been fixed with the next nightly build.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

So far I can see it has only been partially fixed. I just built and sent a big bunch of horsedrawn trains onto a double tracked line, and most of the vehicles insisted on going to the same random stop, quite far down the schedule. When opening the schedule and select the first stop in the schedule and closing, occasionally, the vehicles after a small while reverted to wanting to go to that random stop again. Occasionally, a train suddently goes into reverse out on the open line, after which it whiches usually wants to go that random stop again.

jamespetts

This looks to be a different issue. Can you upload a saved game in which this issue can reliably be reproduced?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

Not fixed at all, possibly even made worse.

On the server my trains are now blocking each other by reserving tiles in front of other convoys ahead of them (usually on save/load cycle). They also still randomly skip stops for no reason.

The random changing of destination seems to occur at any piece of curved track and not just intersections. Specifically it happens if the convoy is blocked from going around a corner due to another convoy.

nochiu

Quote from: DrSuperGood on February 27, 2018, 01:14:56 AM
Not fixed at all, possibly even made worse.

On the server my trains are now blocking each other by reserving tiles in front of other convoys ahead of them (usually on save/load cycle). They also still randomly skip stops for no reason.

The random changing of destination seems to occur at any piece of curved track and not just intersections. Specifically it happens if the convoy is blocked from going around a corner due to another convoy.

I can not find the bug in the save game. Can you give me server and coordinates for the bug?

Ves

Could all this be related to the new addition, that if two trains face each other in a deadlock, one of them will reverse?
I just noticed a big bunch of convoys changing directions, due to hitting a train leaving a depot.

jamespetts

Ves and Dr. Supergood - I really will need a saved game in which this new issue (or new manifestation of the previous issue) can reliably be reproduced in order to fix this: I had believed that it was fixed because I could no longer reproduce it on the specific saved game uploaded here.

Thank you for updating me as to the status of this, however.

Incidentally, as to Ves's last post, the issue that I fixed was indeed related to this new anti-deadlock measure, so it is possible that the remaining issues are also related to this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

I dont know which version of the bug I have trapped, but I have captured a bug:

The savegame is the one from the server.
- Open the rail depot in view.
- There you should find 16 horse convoys, all connected to the same schedule, which has just been created from scratch.
- Open the individual schedules in the depot window, and you will see that all convoys wants to go to "Bundhampton dock", just as they should.
- Press the "start" button 16 times to release all convoys.
- Now, note that the first couple of convoys still wants to go to "Bundhampton dock", but after a short while, more and more convoys wants to go to "Lymthorne Junction Stop" and occasionally also some to "Lesser Wardstone ........ stop".

Also note that they dont take the shortest route towards the "Lymthorne ...", which would be to just cross over to the tracks and turn right, but they travel left, probably because they want to pass the waypoint I have set on (1677,743), however, thats not indicated in the window (I dont remember wether it used to do that, though)

savegame: https://github.com/VictorErik/saved-games/blob/master/master/bug%20-%20General%20strange%20drive%20by%20sight%20behavior.sve


I understand and appreciate the idea behind the anti-deadlock feature, but Im afraid there perhaps would be some principalities that needs to be addressed:
For one, if the track is unidirectional, we would never ever want a train to head in the wrong direction, that is towards the conflicting oneway sign.
A way to solve it: Make a flag "do-not-turn-around-flag" in each convoy which would enable if the convoy passes an one direction sign, and disable when the train passes a junction. If two trains do a head on collision, the train with the flag disabled would be the one to turn around. The flag also has to be enabled on that train, because it might hit another train on its way back to the previous station, and we want that one, along with any further trains to turn around. If both trains have it enabled, well that means that the player has put two one way signs facing each other which is poor trackwork design, and it should rightfully get stuck. If both trains have the flag disabled, the train with the shortest distance to its previous stop should turn around (is that how it is now?). That would also automatically take any more trains on its way back to the station along with it, due to their destination by princip would be further away than the now turned around train.

Ves


jamespetts

Thank you for the report. This is not entirely straightforward, as there are multiple issues here. Firstly, I have disabled the automatic reverse on drive by sight deadlock on depot tiles to stop this occurring when starting convoys from a depot.

Secondly, the behaviour of starting from a stop other than no. 0 in the schedule appears to come from code in Standard: the line's schedule had its own "current stop" setting, which is copied to the individual convoys as their starting point whenever the line is assigned to the convoy. I have now changed this so that this "current stop" setting resets to zero before being applied (but this will not affect convoys which have already been assigned to a line, as in the saved game uploaded). I am not clear on what behaviour was intended from the original Standard code, so this may need further adjustment in due course.

As to the final paragraph, this is an interesting idea (and quite separate from the original report). After I have made the modifications described above, can you check whether there is still an issue that requires this as a remedy?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

The trains are still skipping stops, reversing and overall being impossible to use. I have spent several game months on the server attempting to get a simple line working with new steam engines and the result is that it still deadlocks for no reason at all. Using the replace convoy feature is as good as unusable on drive by sight convoys.

jamespetts

Dr. Supergood - can you be more specific as to exactly what happens in exactly what circumstances and upload a saved game in which these specific problems can reliably be reproduced in particular and specified times and places in that saved game?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Rollmaterial

It seems to be caused by 90° corners in your loops. Trains will incorrectly reverse if they catch up another one in such corners.

DrSuperGood

#14
With exception of the terminals which need them, I have purposely avoided such corners...

I miss standard Simutrans signals. They were infinitely better in comparison.

jamespetts

The reason, I think, for the issue with corners is that the reversing system tries to detect whether the convoys are going in different directions, as there is no need to reverse if they are going in the same direction. I did initially try to have a system where it would only work in the opposite direction, but that then failed to reverse when trains were not on straight, non-diagonal track. I cannot think of any system to check whether a train is actually heading towards another on the same line with any reliability. So, unless somebody else can think of such a system, then the only options are either to live with the issues on corners or to disable the reversing system entirely (which will then give rise to a more difficult to use drive by sight working method).

Dr. Supergood - if the issues that you describe are not on corners, I will need, as requested above, a saved game in which these issues can reliably be reproduced in a specific place and time in order to be able to investigate this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

You make it sound like there are no issues... I cannot even set up a single functional line on the server game with 20 convoys on it and regular services without the trains trying to go the wrong way or skipping several stops seemingly at random.

Maybe I am expecting something that drive by sight is not capable of. Perhaps a guide is needed to explain how one is meant to set up passenger lines using these convoys?

jamespetts

Dr. Supergood - I am not sure why you think that I "make it sound like there are no issues" - can you elaborate? I ask for a specific reproduction case because that is what I need to investigate the issue, not because I do not believe that there is one.

Can I clarify, as this is important - do the issues that you describe occur other than when one of the affected trains is not facing in the same direction as all the others that are touching it? If not, then this may be a question of either disabling the reversing system entirely or implementing Ves's suggestion (although, for the latter, we then need to consider whether the issues occur in places where Ves's system would not assist). If so, then this is not an issue that I have investigated and will need the saved game as requested in order to do so.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ACarlotti

I've just had a thought about how I might implement auto-reversing simply if I were to do it from scratch. I mention it here in case it turns out to be easier than dealing with what sounds like a growing but still incomplete set of different cases in the current system.

Basically, every reserved track tile stores an indication of which tile the convoy reserving that tile intends to travel to next. This would be stored as a direction (one of four) or none. (None should also be used for the last reserved tile if the convoy hasn't reached it yet, to avoid false positives in passing loops that are just large enough). When a convoy gets stuck (i.e. can't travel any further because the tiles are already reserved), then it records on its current tile which tile it wanted to go to, and then iteratively follows these next tile indications (up to some constant limit) to see if they form a loop. If so, then one of the convoys in the loop is ordered to return to its previous stop.

This would require adding a small amount of data to each tile of railway, but it will handle a wide variety of possible deadlock situations relatively gracefully and would likely avoid all the bugs that are currently arising.

jamespetts

That is no interesting idea: does it even need extra data storage? As the tiles already contain a reference to the reserving convoy, could not the other convoy simply check the data from this and perform the same calculation on it? On a large map, there can be so many way tiles that it is best to minimise the amount of memory that these take.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ACarlotti

I don't know exactly how vehicles navigate, so that may be possible without adding extra data (at the expense of added computation and complexity, which is what I would be trying to avoid).

jamespetts

Convoy objects store the route to their next destination in the form of a list of tiles, so this should be able to be extracted without storing this in tiles additionally.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

I do not know what is causing it anymore as it happens so randomly on the line. I have managed to dampen its effects by placing a lot of 1 way signs so at least convoys will not randomly try to drive into each other. If it happens now they will just pointlessly loop around costing my company money and not picking up anyone resulting in degraded service quality.

It seems to be related to 2 factors...
1. Replacing convoys. After a convoy is replaced it tries to resume its schedule in a stupid way such as visiting a stop back from the depot which is effectively only accessible by traveling around most of the loop to get to it. I understand this will likely be fixed by the upcoming convoy recombination system since depots could be explicitly part of the schedule which the convoy will keep ordered correctly.
2. Convoys bunching together due to the bus problem or as a result of other convoys having their schedule changed. This is likely due to the curve related problem.

ACarlotti

I think the following should deal with problems on curves. How to deal with convoys coming out of depots is a harder problem that I'll think about, although as DrSuperGood says, it is likely to be solved by the changes to vehicle maintenance and recombination.

iIt sounds like it should be pretty easy to simplify and fix the auto-reversing (on curves) then. If you just want to deal with head-on deadlocks (or similar), then I think it would suffice check the next tile on the route of each convoy, and if these tiles are each occupied by the other (also blocked) convoy, then that's a deadlock.

More generally (if you want to spot deadlocks involving more than two trains), you could do the following:

Create a list of blocked convoys, initially containing our original convoy.
In a loop, do:
Find which convoy is blocking the last convoy in the list (basically, which convoy is occupying the next tile in the route)
If this convoy is already in our list, then every convoy in the list from this one onwards is part of a deadlock; one of them will have to reverse.
If this convoy is not blocked (i.e. it's moving, or can move, or doesn't want to move yet), then it's not a deadlock.
Otherwise, loop.

It might be sensible to cap the length of the above list. Also, this doesn't specify how to decide which convoy should reverse, and where to reverse to, which brings us back to the depot problem. But at least one bug is solvable here.

TurfIt

Quote from: jamespetts on March 10, 2018, 02:13:22 PM
Secondly, the behaviour of starting from a stop other than no. 0 in the schedule appears to come from code in Standard: the line's schedule had its own "current stop" setting, which is copied to the individual convoys as their starting point whenever the line is assigned to the convoy. I have now changed this so that this "current stop" setting resets to zero before being applied (but this will not affect convoys which have already been assigned to a line, as in the saved game uploaded). I am not clear on what behaviour was intended from the original Standard code, so this may need further adjustment in due course.

When one creates a line, the first stop in the list might not be the desired starting stop... Hence a line having a 'current stop'.
Similar when one copies a vehicle in the depot, the current stop propagates. Allows one to stagger the stops on line startup.
Removing such features would be quite annoying...

jamespetts

Dr. Supergood and A. Carlotti - I have just implemented the basic version of A. Carlotti's latest suggestion for a fix for this. Initial testing seems promising, but it would be very helpful if I could get some feedback from Dr. Supergood and others as to how well that this works on the server game. Thank you for the suggestion.

TurfIt - interesting. Would it not be easier simply to have a different stop as stop 0 in the schedule? I should be interested in others' views on the point - did anyone use this feature? Is it worth restoring? It may be that it had ceased to work properly and incorrectly gave erratic starting points. I was not aware that this was intended.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Do we need to rebuild the lines to test this?

I occasionally use the feature of deciding which stop should be the first stop. It could be that the depot is located somewhat down the line and you at all times need to have vehicles pass through some waypoints or special stops, before it reaches the termini for the line to function. Then it is quite handy to be able to set other stop as the first stop.

jamespetts

It should not be necessary to re-build lines to test this fix, but it will only be available from the next nightly build onwards.

As to setting another stop as the first stop - is there any issue with simply putting that as the first stop in the schedule when it is created?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Yes, when using mirror schedule, you can't have any entry but the terminus as the first entry. Also, a schedule look much cleaner when the terminuses are at the ends of the schedule.

DrSuperGood

QuoteYes, when using mirror schedule, you can't have any entry but the terminus as the first entry. Also, a schedule look much cleaner when the terminuses are at the ends of the schedule.
As far as I am aware one cannot do this with train schedules servicing double track stations. One terminal is usually at the start of the line schedule and the other terminal in the middle as one must explicitly specify the platforms for the return journey. Hence such lines cannot be mirrored.

Unless I am missing something...
QuoteIt should not be necessary to re-build lines to test this fix, but it will only be available from the next nightly build onwards.
As far as I am aware this bug is now fixed. I have not observed any trains randomly skipping stops when operating in drive by sight mode.

That said I am using drive by sight mode a lot less now, but did have a few run ins with it at junctions before the recent fixes and this problem did not occur. Hence why I think it is fixed.