Convoys goes to the wrong entry on the schedule list

[Ves]

It appears as if the recent changes have made schedules broken, so that convoys will go to the wrong schedule entry in the schedule. This has created massive deadlocks and moneylosses on the server...

I have a save from the bridgewater brunell server, which I made as a backup. Look at the Royal Beckborough, there are tons of convoys deadlocking. Also look at Tumperminster (5920,1782), there are also lots of lots of convoys doing weird stuff.

https://we.tl/t-xVO5FynwY5

File is so big, Github would not take it this time, so it is on WeTransfer.

edit: Wrong link -> corrected

[Mariculous]

This bug is already known in case of waypoints, but now I have observed it the first time without any waypoint involved.

On stephenson-siemens, the "R Brockshot/chisselfield touristic" line is shuttleing all the time in between the Abbey and Manor house. It will never continue to the station.

This can be observed on stephenson-siemens at Convoy (2648).

In case this behavior should change, I have saved the game locally just in case that behavior changes on the server, which I don't expect tbh.



Edit: Sorry, this is a duplicate. Please merge with https://forum.simutrans.com/index.php/topic,19979.0.html

[jamespetts]

Thank you for the report: I believe that I have now fixed this. I should be grateful if you could re-test with to-morrow's nightly build.

[Ves]

Thanks, could you perhaps use the backup save as well for the server? I dont dare to see in what condition my company is now... If it is still even there 

[DrSuperGood]

Looked at a schedule and for some reason it said traveling to a waypoint on a neighbouring tile to the directly above stop entry was a distance of ~16 km. Might be related or just a UI bug.

[jamespetts]

Topics duly merged.

As to Dr. Supergood's post, it is probably best to wait to see whether the fix posted here addresses the issue. If it does not, then this should be a separate bug report.

[wlindley]

Latest off github (3a1e01) seems differently broken, still not proceeding properly through schedules.

[jamespetts]

Latest off github (3a1e01) seems differently broken, still not proceeding properly through schedules.

Can you elaborate?

[wlindley]

Hmm. It does seem solved with a bit of manual intervention. Convoys that were in a confused state seemed to continue reversing or skipping, but restarting such a vehicle from the start of schedule (and clearing Reverse Route) seems to resolve the problem, and no new problems seem to arise. 

[jamespetts]

Hmm. It does seem solved with a bit of manual intervention. Convoys that were in a confused state seemed to continue reversing or skipping, but restarting such a vehicle from the start of schedule (and clearing Reverse Route) seems to resolve the problem, and no new problems seem to arise. 

Splendid, thank you for confirming.

[wlindley]

The offending schedule had a reversing mark [<<] at a waypoint.  Removing and re-adding the waypoint is what corrected the problem.

[Mariculous]

That's a seperate bug reported elsewhere.
Do you think the resersal at waypoints might be fixed by this either?
Is it worth to give waypoints another try?

[jamespetts]

That's a seperate bug reported elsewhere.
Do you think the resersal at waypoints might be fixed by this either?
Is it worth to give waypoints another try?

It would be helpful if people could check as to the extent to which previously reported waypoint bugs are still an issue.

[jamespetts]

Can I check whether the recent waypoint fixes have addressed this issue?

[Ranran]

Can I check whether the recent waypoint fixes have addressed this issue?

Strange automatic reverse bugs are common. Check Line "(pmw41) Abbott's A" of my company on bridgewater server for a reliable example.
There are several bus stops along the way, but [<<] will be automatically inserted, and as a result convoy will be teleported to the depot.
Oddly, another line following a similar route (Abbott's B) doesn't seem to get teleported.

EDIT:
The message seems to be teleporting it to try to travel some very long distance. Sometimes it's seen in another line, but it doesn't happen in all of the lines, but it seems to happen sometimes. But at least I'm not manipulating that schedule. Suddenly only some convoys get teleported.

EDIT2:
At least for some reason the weird [<<] in that line cannot be removed.

EDIT3:
It turns out that there is a case where a meaningless [<<] is attached when the next tile is an intersection.

EDIT4:
I tryed to fix that [<<] and added a waypoint along the way. Immediately after that, all convoys on that line were teleported to the depot.

[Ranran]

I have uploaded a server save that can check teleports.
https://drive.google.com/file/d/1RPulsN7MpCA7TH8QwIaRAOPT4cpUUUg0/view?usp=sharing

(pmw41) Abbott's A will automatically insert [<<] at stop a.
Most of the stops along the line had this. However, the bus stop is located on a straight line along the road, so no reverse is necessary. I've been fixing it by setting relay points, changing bus station locations and repeating. And every time the convoy of the route is teleported. If I don't do that, It will It gradually teleport or return to the depot. There should be no problem that the road is not connected or the distance is too long. I checked a few times. And it's been working fine for a while and other line convoys are passing there. The 24km range limit should have been cleared.
In fact, if you observe there, it will not turn back there.
But if the route changes (by build shortcuts road, new intersections, etc.) or the schedule changes, it will teleport or sent to the depot. In that way, all convoys will disappear from the line. I think this is the reason that convoy has completely disappeared on some of the Funny company line.

(pmw41) Open Abbott's A's schedule and try inserting waypoints before and after stop a. convoy receives a teleport.


EDIT:
I also think that the times history record is also broken on a line which has such a broken schedule. It is playing in an unstable state, completely destroyed and teleported in some time. At that time it will unfairly report strange distances.

[Ranran]

Freddy's remarks inspired me to discover inconsistent behavior.

I often saw the behavior of reversing at an intersection that turns 90 degrees.

Open this saved game and start the convoy inside the depot. Reversing at the first intersection only once, but thereafter this does not happen.
It reversing for some reason when it first turns east to south like this.


However I think this happens every time the road is changed. I think that [<<] is inserted by it.
Setting the waypoint is especially dangerous as it increases the chances of this happening.
However, there are many examples where the shortest route is not set unless a waypoint is set.

[Ranran]

I have just confirmed on the server what this caused.
Convoy was teleported because this automatic [<<] insertion breaks the calculation of the distance between stations. This often happens in convoy with range limit. It reports strange distances when teleported.

[freddyhayward]

I have just confirmed on the server what this caused.
Convoy was teleported because this automatic [<<] insertion breaks the calculation of the distance between stations. This often happens in convoy with range limit.

I witnessed this happening with your convoys on the server as well. Did you happen to insert a waypoint beforehand?

[Ranran]

I witnessed this happening with your convoys on the server as well. Did you happen to insert a waypoint beforehand?

Yeah, I set a waypoint at the intersection. And [<<] was inserted there. Convoy that reached there was teleported, reporting a strange distance.
I changed the waypoint next to the intersection and it seems to be operating normally now.

[jamespetts]

Thank you for this - this is helpful. I have pushed a possible fix; I should be grateful if you could test this.

What I have done is to change from assuming that an undefined waypoint is a reversing waypoint to assuming that an undefined waypoint is not a reversing waypoint. This appears to prevent the incorrect reversing in the saved game above. However, it is possible that this will result in other problems elsewhere, as I am not able to remember all of the possible remote implications of this assumption. Dealing with having to assume reversing status can cause many problems.

[jamespetts]

Can I check whether anyone is able to reproduce this following my fix?