This topic is to record and document the state of known issues/bugs with the version currently running on the server. The intent is to make sure the bugs/issues can be resolved for the next release of Simutrans. The reason for this thread is to bring together multiple bugs and issues so that duplicate reports or overlooks cannot happen.
- Incorrect route calculation logic: Solved for next release. (logic redone)
Average speed and travel time is sometimes computed incorrectly. The result is that lines can be more or less profitable than intended or that goods might decide to take illogical routes due to thinking they are shorter. The issue is mostly when new convoys are added to a line and is worst for lines with long journey times (eg multiple months). - Departure slots do not factor in load time: Unknown.
When assigning convoys with a long load time (ships, aircraft) to a line with a high departure frequency (<< convoy load time) multiple convoys will attempt to depart before they are finished loading. The result is immediate departure once the load time completes rather than anything to do with the departure slots. When starting a line this is especially problematic as the result may be multiple convoys departing simultaneously instead of well spaced out like intended by the departure rate. What should happen is that departure slots are skipped until one is found which offers sufficient time for the convoy to be loaded. All slots skipped during the search are permanently lost (no convoy can take them). An additional time field could allow for tolerances (so a slot may or may not be skipped). - Scheduled lines departure slots can be double allocated: Unknown.
Some times when multiple convoys arrive at roughly the same time they get assigned the same time slot for departure. This mostly seems to happen when multiple loading bays are used to buffer waiting convoys such as a large train terminal or an airport. It has been observed to happen with subway trains and aircraft. At least 2 convoys get assigned the exact same departure slot. The overall rate of departure remains roughly correct as at least 1 departure slot is skipped when this happens. Only can confirm double allocation but have a feeling I have seen triple or more once or twice. - Aircraft randomly skip loading time: Unknown.
Aircraft will sometimes park in a bay, have a 0:00 load time and then depart after correctly taking on cargo. Such aircraft should be subject to a minimum loading delay (30 minutes in this case). Seems to happen mostly when aircraft are not assigned departure slots (eg a line where another airport is responsible for synchronizing departures so they are set to return as fast as possible). Seems to occur more often when aircraft has free capacity and after loads. - Train placement restored incorrectly after game load: Need solution. (possibly from standard)
When the game is loaded trains will sometimes have their position restored incorrectly. The result is that coaches can start to occupy space disjoined from the engine, not match the way art or even appear a considerable distance way from the convoy inside other convoys. This usually auto corrects itself in straight way sections (only 1 way for train to go). At complex way structures like multiple way points or station terminals the disjointed nature of the problem can result in blocks being reserved in an illogical way and thus causing a blockage in the network. I have had this happen a dozen odd times on the server affecting multiple companies. It is at the stage that if you see "stuck" trains then chances are this the cause of them being stuck rather than bad way engineering. This also affects aircraft as I have had two planes (with illogical take-off direction) on a runway after loading the map (only fix in this case was to alter the schedule of the forward one, which advanced it exactly 1 tile at a time). - Aircraft make stupid runway decisions: Discussing solution. (standard bug that has no implications due to mechanical differences meaning only 3 long symmetrical runways are used)
Aircraft will use a runway from one direction even if it is impractical to do so. The result is that you can connect right at the end of a runway so the plane only has to taxi 1 tile to get full runway length for take off but instead it taxies on the runway to the opposite end (several kilometres) to take off in the opposite direction. The result is more time spent taxying and about 1/3 or less of the take-off capacity. One-way signs do not help force a take-off direction, instead they cause a "no route". May also apply to landings as well. The logical direction for a landing or take-off is the one which results in the least amount of taxying to reach the destination. In the case of take-off this would mean going to the nearest part of the runway so that sufficient length exists for take-off. In the case of landing this would mean coming down on the runway such that the plane stops closest to the way off the runway towards a chosen bay. - Conflicting company colours: Solution for both required. (standard bug)
It is possible for companies to select primary colours that are physically different but similar enough that it becomes impossible to tell who is the correct owner from colour. This is especially the case for 2 of the blue colours where stations can be side-by-side and still unable to distinguish the owners apart. The available colour selection needs revision such that choosing any colour clearly distinguishes the company from other companies of any colour. Do note that I am not colour blind and do have good eye sight so should be able to tell colours apart quite well. This must be quite a serious problem for people with worse eye sight. - DC Third Rail Electrification broken on bridge ramps: Solved. (code revised)
Electrifying a section of track with DC Third Rail Electrification that includes a bridge with ramps results in incomplete electrification. Although the ramps are reported and appear as electrified when inspected convoys will not treat them so meaning they cannot route over them. This only affects DC Third Rail Electrification alone, DC Fourth Rail Electrification will correctly provide DC Third Rail Electrification on bridge ramps and so allow DC Third Rail convoys to route over them. The current work around is to use DC Fourth Rail Electrification on bridges. Other sources of DC Third Rail Electrification were not tested so may or may not suffer from this. - Power networks not deterministic between clients: Solved. (the diagnosed cause was multi-threaded initialization after load causing different internal ordering)
The existence of any operational power network can cause clients to fall out of synchronization. As such one is not allowed to use power networks on the server. Inactive power lines do not appear to cause problems however it is still recommended that they are removed to save on maintenance. - Maximum in-transit values do not allow for continuous operation: Solved? (I think algorithm was revised/changed).
For small consumers like corner shops which only use a few dozen units per month the maximum in-transit amount does not allow for continuous operation even if lines are designed to regularly move goods. Such lines involving ships set to wait for 100% loads will often become stuck since not enough can exist at a given time for a full load. This does not affect larger industries like Steel Mills which allow for tens of thousands of raw material units in transit at a time. It should also not affect road convoys which only have very small loads. - Aircraft leaving depot not subject to choose signal: Solution for both required. (standard bug? may have been fixed in standard but unsure)
When starting multiple aircraft from a depot which is connected to their first destination they will all go for the same stop. When aircraft land they choose a free stop unless none are available. What should happen is that aircraft leaving a depot connected to their destination will also choose a free stop unless none are available. Especially important in experimental since each aircraft has a long loading time so many bays need to be used in parallel for high-traffic routes.
Thank you for that list: that is most helpful, both for players on the server and for development works. DO you think that you could perhaps number the list to make it easier to refer to it?
In respect of some of the issues that are bugs in the code that are not yet solved, it may be difficult to reproduce, and therefore fix, these without either a deterministic set of steps to reproduce or a relatively simple saved game in which the problem occurs at a deterministic time and place that can easily be found. If you or anyone else is able to produce such, that would be extremely helpful.
One issue is not strictly a bug, which is the player colour set. This is the same as Standard; I wonder whether some revision should be suggested to Standard, which could then be backported into Experimental when implemented?
The train placement after game loading issue I think derives from Standard, as I remember this issue in Standard games long ago (I think). I have certainly not changed in Experimental the loading/saving mechanism for convoys. Are you aware of whether an issue like this has been fixed in Standard in the last 2-3 years or so?
As to aircraft on a runway, the mechanism here is the same as Standard, except, in Standard, runways are allowed to be very short indeed. However, I am not sure whether this is undesirable, as I think that it represents a real life parameter, which is that aircraft will only take off into the wind. In Simutrans, there is a simulated (but fixed) wind direction, and aircraft will always take off and land in that direction. Changing it to allow them to take off or land in any direction would make the game less realistic. There are remnants of code that suggest that a variable wind direction was once attempted but abandoned many years ago. Simulation of variable wind direction was also suggested a while ago by The Hood in the context of sailing ships, but was not taken up partly owing to the complexity of coding such a thing and partly because of how difficult that it would be for players both to understand and to plan for changing wind direction. The same may well apply to aircraft.
The electrification of bridge ramps (the issue is not just confined to one type of electrification) should be fixed with the next release, as this issue is now fixed in the code.
I think that I have fixed the power network desyncs (in that I can no longer reproduce them on a simple setup), but this has not been tested rigorously.
Any assistance that you or anyone else might be able to offer in narrowing down and/or fixing the bugs reported here would be much appreciated. Thank you again for your help.
QuoteOne issue is not strictly a bug, which is the player colour set. This is the same as Standard; I wonder whether some revision should be suggested to Standard, which could then be backported into Experimental when implemented?
It could be, but seeing how changing colours in multiplayer is not supported in standard it is not really a problem there.
QuoteThe train placement after game loading issue I think derives from Standard, as I remember this issue in Standard games long ago (I think). I have certainly not changed in Experimental the loading/saving mechanism for convoys. Are you aware of whether an issue like this has been fixed in Standard in the last 2-3 years or so?
Do not think so and do recall seeing it from time to time. Especially with more complex signalling systems this could become a big problem for experimental. In standard it mostly auto corrects or results in the occasional block skip resulting in "stuck".
I can flag this up next time I see it on the server for better analysis.
QuoteAs to aircraft on a runway, the mechanism here is the same as Standard, except, in Standard, runways are allowed to be very short indeed. However, I am not sure whether this is undesirable, as I think that it represents a real life parameter, which is that aircraft will only take off into the wind. In Simutrans, there is a simulated (but fixed) wind direction, and aircraft will always take off and land in that direction. Changing it to allow them to take off or land in any direction would make the game less realistic. There are remnants of code that suggest that a variable wind direction was once attempted but abandoned many years ago. Simulation of variable wind direction was also suggested a while ago by The Hood in the context of sailing ships, but was not taken up partly owing to the complexity of coding such a thing and partly because of how difficult that it would be for players both to understand and to plan for changing wind direction. The same may well apply to aircraft.
Aircraft usually take off into the wind because it allows a slower take-off speed since the lift is based on the difference between plane and air velocity (so having the wind going towards the plane decreases the required velocity of the plane). One must remember that some times the effects of wind can be negligible such as on a wind still day. Airports also still function when wind is blowing in the opposite direction from normal (unusual pressure fronts etc) and I do not recall seeing planes having to taxi to the other side of the runway, turn around and then take off in such a case.
I would suggest one of two possible solutions. The first is to keep the current mechanics except place directional arrows on the runway representing the direction of landing/takeoff. This could be a pakset art change, or maybe has to be hard-coded. This would prevent people accidently creating stupid airports thinking the planes would take off in the other direction.
The other solution is to implement smart take off but raise the runway requirements such that it would be suitable for take off with any manageable wind direction. In real life planes still have to take off even if wind is undesirable as long as it is not an extreme weather condition (typhoon, hurricane etc). This would make airport construction easier and allow for neater or more compact airports.
Also there is another issue from standard where airplanes leaving their depot are not subject to a "choose" signal as they are when landing. This makes starting multiple planes at once difficult since they will all run for the line designated stop rather than a free stop.
I had not remembered that Standard does not support transmitting the player colour - that is an interesting point. The colours, I think, are hard coded, and I have never really looked into that part of the code. Do you think that you can suggest some alternative colours? Do you know where in the code that these are represented?
The rail vehicles getting mangled in the way that you describe is a significant problem. I do not think that it is specific to Experimental, but, as you point out, might cause more problems in Experimental than Standard. I wonder whether this is because of the way in which the positions of convoys are saved? Have you ever looked into this part of the code? If it does not save the exact position of each vehicle, but allows recalculation on loading, this might be an issue. If I recall correctly, the problem seems to occur on diagonals.
As to aircraft, we may need more research on this as to whether aircraft do taxi to the other end of the runway; I am fairly sure that they always do try to take off and land into the wind for the reason that you describe. Showing what this is in the GUI somewhere might be worthwhile, but this is fairly low on the list of priorities for my own work, and certainly below things that are critical to balance.
Aircraft not respecting choose signs on leaving the depot is slightly more important; this should probably be fixed in Standard, too, should it not?
QuoteThe rail vehicles getting mangled in the way that you describe is a significant problem. I do not think that it is specific to Experimental, but, as you point out, might cause more problems in Experimental than Standard. I wonder whether this is because of the way in which the positions of convoys are saved? Have you ever looked into this part of the code? If it does not save the exact position of each vehicle, but allows recalculation on loading, this might be an issue. If I recall correctly, the problem seems to occur on diagonals.
Looked at some stations on the server after load. Trains waiting for load had their trailing coaches disjoined from the main engine about 5 or so tiles
in-front of the engine (outside the platform, in fact outside the station area on the incoming track section). These then can block incoming or outgoing signal blocks which is why jams occur (if another train was leaving, hits the coaches block so cannot continue and the coaches are stuck their because their convoy cannot leave while the other train is trying to leave). In the case I observed they occupied the block of the signal for incoming trains to that station. Although it is not perfect in standard the coaches do not disjoin this badly from personal experience (they usually end up at the same tile as the locomotive). What is more strange is as the train leaves the station the coaches appear to move the direction of the train and then warp magically behind to where they should be.
This is a semi-critical bug I would say since it means that loading can break some functional transport networks (not something one wants to happen in multiplayer).
QuoteAircraft not respecting choose signs on leaving the depot is slightly more important; this should probably be fixed in Standard, too, should it not?
Yes it should, it might already be so even as there were changes regarding path finding and lines for planes a while ago after the last standard release (eg you can now select which runway a plane uses). I am not sure and in any case both versions would benefit from it (Experimental especially).
I dunno, I haven't experienced that loading bug myself outside of the multiplayer map (where it seems to happen an awful lot to me in particular...), though I have long ago abandoned playing 11.35 outside of this.
I have noticed that occasionally upon load (with a new compile) signal block reservations will be wrong for reversing services, but they have not been warped as happen on the multiplayer game map.
The locomotive (head) does not warp, it appears in the same place as when it saved. It is the trailing coaches which warp to strange places (possibly with reversing services). It might be your issue with incorrect block reservations even.
Oh -- and by the way, using way points as reversing points, as in a head-shunt, results presently in the train most of the time just "driving through", it does not stop, slow down or reverse, but simply continues as though the way-point was a curve.
Aircraft will typically take off and land in to the wind as air speed, not ground speed, is the determining factor. Taking off in to a strong wind will reduce the amount of runway required to get the plane in to the air. I've been in many situations where the plane will taxi a good 5+ minutes in order to traverse the entire length of the runway to get to the opposite end for takeoff.
That said, the plane will taxi down the taxiway, not the runway, except in situations where it's a quieter airport and the runway isn't reserved by other planes due to take off or land. On a busy runway, keeping the runway clear is important.
Ok I assume the correct behaviour would be a UI change rather than a mechanic change. It should show the user what way planes would take off or land on runways.
Thank you all for your feedback. The most important issue here is clearly the train reservation issue. The airport GUI thing can be dealt with later. (As to changes to airport routing in Standard, does anyone happen to know the date or approximate date of this so that I can look at the Github mirror and find the relevant commit(s)? I think that I have integrated all of the significant applicable changes from Standard, apart from the GUI themes which was a bit difficult but I should like to do one day, but it is not impossible that I have missed one; but if you are testing in 11.35, that will be before these things have been integrated in any event).
In relation to the rail issue, any more detail on the circumstances in which this can be reproduced in the latest devel-new code would be very much appreciated. I did try a basic test last night by saving the game with trains on diagonal track with lots of junctions to neighbouring diagonal track, but this was to no avail. However, there were no signals in this configuration: do people find that this only occurs with signals? It would be extremely difficult to isolate the problem in a game as large as that on the server: if we can find a way of reliably reproducing this issue, it would help. There may be a problem with how block reservations are saved or something similar.
Quote from: jamespetts on August 18, 2015, 09:09:00 AM
In relation to the rail issue, any more detail on the circumstances in which this can be reproduced in the latest devel-new code would be very much appreciated. I did try a basic test last night by saving the game with trains on diagonal track with lots of junctions to neighbouring diagonal track, but this was to no avail. However, there were no signals in this configuration: do people find that this only occurs with signals? It would be extremely difficult to isolate the problem in a game as large as that on the server: if we can find a way of reliably reproducing this issue, it would help. There may be a problem with how block reservations are saved or something similar.
Try making a lot of stations where the trains reverse and/or wait, and save and load this some. It should occasionally display certain oddities, and as Supergood said, this might be the same kind of issue, or at least closely related. Upon loading the reservation will not work right and the train will be unable to depart from the station (occasionally because another train has reserved the block upon which it is, or the approach thereto).
(http://i.imgur.com/iT4iC1p.png)
Two services end and reverse here, and they both end up "stuck" frequently because of reservation issues. I don't have a save where this is presently the case, however, but this sort of layout should experience the issue (there's another where a shared platform experiences similar issues, but it has less traffic so it happens less frequently.)
If you could upload this saved game, it would at least avert the need for me to create this sort of layout from scratch. I could then load and save the game at different points to see the circumstances in which this arises.
http://www.mediafire.com/download/n2f3ph5c6sh2msm/tass7x%282%29.sve (http://www.mediafire.com/download/ndfhriwz8853xpz/tass7x.sve)
Tarmouth Junction sees the reservation issue happen most often. Other places it might appear in are Crosswych (rare) and Longchester.
On the north-east approach to Oldingford railway station, line J 110 will be affected by the 1km/h bug when turning to enter the station (it is the only one to run through on the centre island platform) (there was a bypass track to make it go straight into it, but I deleted it to make this appear again).
Headshunt north of Tarton Junction previously exhibited the error with the waypoint reversing, but when I moved the way point closer to the end of the track, it now performs as expected (might have been replacing the tender engines with tanks though...)
Thank you for that. Can you remind me what you mean by the "1km/h bug"?
When a train going through goes past the "end of choose signal" (which is to make sure no train chooses the two through platforms), it slows down to 1km/h for the duration of the crossing of the signal on the turn.
I can't open your saved game with my version of the pakset: do I need an updated edition of your version of it?
Oh, right, yes, that is quite likely.
http://www.mediafire.com/download/mv8ulzm0r6kwpl7/Pak128.Britain-Ex-0.9.2J.rar
I am currently reviewing old bug reports, and this one seems to have had no obvious resolution. Can I ask what if any of the issues reported here can be reproduced in the latest nightly builds of Simutrans-Extended?