(11.3) It might be a bug or the oldest issue in Simutrans, but sometimes my trains (in different, unconnected networks, both normal and narrowgauge) reserve isolated track segments that are miles away from their position, and with other trains between them and that segment, causing giant lock-ups. In particular, it happens to different trains from different lines but at the same points. Changing their destination does nothing to solve the problem, I need the B-tool to fix it.
I've begun to use choose-signals at various stations and I'm not using end-of-choose ones, because I don't really know what they're good for. Could that cause this odd behavior?
Zook2,
thank you for the report. This sounds like a bug - can you upload a saved game in which it can be reproduced at a particular point in time (i.e., a specific piece of track that is not reserved when the game is loaded becomes reserved a certain time after loading the game) so that I can try to track it down and fix it? I should be most grateful.
(Also: you refer to 11.13 - can you test this in the latest version, 11.15, to ensure that it is still present? Thank you).
Before and after a lock-up:
http://freakshare.com/files/evjqkozp/1---Before.rar.html (http://freakshare.com/files/evjqkozp/1---Before.rar.html)
http://freakshare.com/files/x6fq6ch2/Stuck.rar.html (http://freakshare.com/files/x6fq6ch2/Stuck.rar.html)
Take a look at the track at (309,1185). It is reserved by train 1089 at (419,1120). I never noticed a lockup at this place before, but the symptoms are the same. It usually happens outside of stations.
The other place where this happens regularly is the track at (650,192). I hope it's a bug and not my confusion about the game mechanics.
I haven't tried it with 11.15 yet.
I let the game run for several hours and the lock-up at (419,1120) happens regularly, while the one at the narrowgauge track (650,192) didn't show up once. Perhaps it's a traveling bug.
I am not able to reproduce this with the latest 11.x branch (in any of the locations given) - can you see whether this recurs in 11.15?
After letting it run for several hours, it happened again. This time using 11.15 (32-bit). The only change to the config I made was the autosave frequency.
The lock-up happened near the station in (746, 775). That's the savegame where it's already jammed:
http://freakshare.com/files/nrdtddyy/1.rar.html (http://freakshare.com/files/nrdtddyy/1.rar.html)
When you said you couldn't reproduce the bug with the other two files, do you mean you loaded Before.sve and it didn't occur?
Yes - I loaded your "before" save and the reservation of the spurious tile did not occur in either of the locations that you stated, even after fast-forwarding for a long time.
I am afraid that a saved game after this occurs does not assist, as it is not a game in which the actual bug can be reproduced (I need to trap it as it happens to be able to fix it). The only way that I can do this is if I can load a game in which it will happen at some known place and time in the future.
Edit: Even on your "after" save, when I load it, everything unjams itself.
Very occasionally - perhaps 2 or 3 times since I play Simutrans - I have seen this as well, never could reproduce it though. I'm also quite sure that it happened in Simutrans Standard on at least one occasion, James.
Interesting. Thank you for that input. Not easy to solve, it seems.
I still don't have a savegame for you, but after my last such jam (a single tile of track reserved in a station by a train still a mile away), I saved the game, quit and restarted. The reservation was gone and the lock-up unjammed itself. Are track reservations not saved in the file?
The reservations should be saved in the tile, so it is odd that they disappear on saving/loading like this.
At least in standard, reservations are not saved but are build dynamically on loading.
Ahh - I thought that Standard was modified a year or two ago so as to save block reservations? I must have been mistaken.
Could it have to do with me starting the game in 11.14 but then switching to 11.13? It must be something rather unusual or the bug would happen to a lot of others, too.
It is unlikely that that would be a reason for it: the code relating to block reservations has not, I think, changed between the two.
And I'm pretty sure I saw it happen before Experimental 11.13 and 14.
Very curious. Please let me know if anyone can reproduce this reliably.
It still happens all the time in my game (11.18 now). This is a typical case:
(http://simutrans-germany.com/files/upload/simscrbug.png)
Part of a block is reserved by the indicated freight train. Sometimes it's only a single tile.
Thank you for the report. Can you upload a saved game in which this can reliably be reproduced?
We tried that a few weeks ago, see above. Didn't work, because
Quote from: prissi on January 19, 2014, 09:19:37 PM
At least in standard, reservations are not saved but are build dynamically on loading.
And when loading my saved games, you said the bug didn't appear. Which is weird, because since then I've updated both *.exe and pakset multiple times, so our environment should be identical. Did you try the 32-bit version?
If the bug eventually appears in a known place after a known time (which may be approximate) following saving/loading, this is enough for reproducing it. If I cannot reproduce the issue, I will not be able to fix it. I cannot remember now whether I tried using the 64-bit, 32-bit or both version(s); is it the 32-bit version that you are using?
32-bit: Yes. I've uploaded a recent savegame:
http://simutrans-germany.com/files/upload/Lockup2.part1.rar
http://simutrans-germany.com/files/upload/Lockup2.part2.rar
http://simutrans-germany.com/files/upload/Lockup2.part3.rar
The bug can happen anywhere, probably on the main line between Borham and Wingington. I know there are several badly designed places in the network where a lock-up can happen "naturally", but you'll notice the giant traffic jam the bug causes. It might happen soon, or after several months. And if it's caused by the player changing anything (a schedule, new trains, new tracks), you'd actually have to play the game. But the bug never occurs in places where I changed the track layout or built anything new recently.
Zook: I've experienced two years ago a bug with similar symptoms, happening to rail tiles, where a grade-crossing was before. Since there's a road ending near the tile where it happens: was there ever a grade crossing?
Quote from: sdog on February 14, 2014, 08:06:27 AM
Zook: I've experienced two years ago a bug with similar symptoms, happening to rail tiles, where a grade-crossing was before. Since there's a road ending near the tile where it happens: was there ever a grade crossing?
No, in no place where it has happened.
I have spent a long time trying to track this one down, with rather less luck than I had hoped. I was initially able to reproduce a problem whereby convoy no. 586 would reserve some track just outside Parbury Station prematurely, but I could not succeed in reproducing it on subsequent occasions as would be necessary to try to piece together what is actually going wrong. The real problem is that the map is so large that fast-forwarding in debug mode is impractical as the game actually progresses more slowly than in normal mode, not fast-forwarded. Because fixing a bug like this requires the issue to be reproduced scores of times with slight changes to the code or testing variables to establish what the problem is and try to fix it, this is a very difficult problem indeed, and I do not think that I shall be able to fix it in time for the next minor release. Thank you very much for the report and saved game, however.
This issue is reproducible on Pak.CZ demo-map, at Strnadice, Pod Kosíøem, two bulk goods trains will incorrectly reserve their path about and cause a jam. It is reproducible consistently (though you will need to grant access rights to all companies for the trains to run well at first, as it is made for standard).
Ahh, thank you - is this the latest version of Pak.CZ?
It is, yes. 0.2.1, I believe.
At what time does this occur?
Really should be happening after not too long. Leaving it on fast forward should show it appearing, it does for me. It can be fixed only by recalculating the paths but should keep appearing again and again with that specific train (an ore train I believe) so you should be able to have to reproduce for you.
I think that I have managed to find this (pushed to the 11.x branch), although the fix seems to cause a route with an excessive length causing a near infinite loop in the block reserving code. The relationship, if any, between the two I do not understand.
I have now found and fixed the infinite loops, which do not seem to have been related to this issue.