Bulk goods fail to load/unload

[freddyhayward]

I don't know whether this report should be under the Pak128.Britain-Ex board. No reproduction case yet. This occurs frequently on bridgewater-brunel, both with convoys full of bulk goods and never unloading them at their destinations, and empty convoys never loading them at stops.

[freddyhayward]

this seems to occur at stops where the convoy requires more station tiles than are available. I don't know why I've only observed this with bulk goods.

[Ranran(retired)]

Does that mean that the length of the convoy exceeds the required length?
In extended it should be "no route". Therefore it cannot stop at the station.
It may be because I fixed an issue that caused no route due to incorrect length calculation.

Do bulk vehicles have a "mix load prohibition"? In the case of that option, processing may have been skipped.

[freddyhayward]

Does that mean that the length of the convoy exceeds the required length?
In extended it should be "no route". Therefore it cannot stop at the station.
It may be because I fixed an issue that caused no route due to incorrect length calculation.

Do bulk vehicles have a "mix load prohibition"? In the case of that option, processing may have been skipped.

I did not get a "<convoy> is too long for its next stop" message. The current behaviour for other vehicles is to give that warning but load anyway, probably with an increased loading time. Increasing the stop length for canal barges fixed the problem, and I can't remember what happened to the trains.

[Ranran(retired)]

I did not get a "<convoy> is too long for its next stop" message.

Unfortunately there is a trick there. Because convoy has two tile lengths. It is the "true tile length" which is the total length of the vehicle and the "(fake) tile length" (get_tile_length) which is the sum of the maximum 8 margins used in many functions inherited from standard.
I suspect that these differences are causing this issue.
Because it is an extended specification that a convoy that exceeds the length of the tile cannot stop at the station, and there is no processing when the tile is exceeded in the extended. This behavior is different from the standard, but extended may change the orientation of the vehicle, also, the specification of the stop position is different from the standard. so we need to write own code. Neroden, who previously tried to change it, left only a comment. So I don't think convoy which longer than station tile can load / unload correctly even if it stops illegally at the station.
Also, in the bulk goods example, it is due to the inclusion of vehicles with a length of less than 8, and I presume that this is not a problem limited to bulk goods.
(Maybe fake tile length exceeds station tile, but true tile length does not exceed station tile.)

Maybe I made it possible to stop at the station with the true length, but hat_gehalten didn't correct the length determination correctly.

[freddyhayward]

It's no reproduction case, but just an illustration of the problem.

[Ranran(retired)]

I may not understand the description of prissi correctly and this can be a complex issue related to the standard specification. It is recommended to have a margin of 0.5 tiles when incorporating a small wagon into the convoy.
In any case, if this problem is not resolved, the recombination system will have major problem.

[freddyhayward]

I may not understand the description of prissi correctly and this can be a complex issue related to the standard specification. It is recommended to have a margin of 0.5 tiles when incorporating a small wagon into the convoy.
In any case, if this problem is not resolved, the recombination system will have major problem.

whatever the specification, it should never prevent the entire train from loading. and in this case, the train is 4 tiles long, the station is 5 tiles long.

[Ranran(retired)]

whatever the specification, it should never prevent the entire train from loading. and in this case, the train is 4 tiles long, the station is 5 tiles long.

The original bug was that the train would stuck (got no route) when such convoy reversed.
I just suspected that it might not load as a result of removing such a stuck, but I'm not sure if it's actually the cause.
If length doesn't matter, it's probably another matter.

For example, even if there is a cargo attribute, if the capacity is 0, the cargo will not be loaded. Similarly, if the cargo stored at the station exceeds the capacity, it will not be loaded. I know the coverage constraint of 3 tiles for cargo may not actually be 3 tiles. Recently, just_in_time has changed. Consider these possibilities.

[freddyhayward]

even if there is a cargo attribute, if the capacity is 0, the cargo will not be loaded

The capacity is 10 for each wagon, so this should not matter.

if the cargo stored at the station exceeds the capacity, it will not be loaded.

That doesn't make sense at all, since pack horses with a capacity of 1 can easily load cargo from amounts far greater.

I know the coverage constraint of 3 tiles for cargo may not actually be 3 tiles

I'm not sure what this means. What coverage constraint?

Recently, just_in_time has changed

That shouldn't matter at all.

Sorry to sound so angry :(

[Sirius]

Well the point freddy made (at least I think he did, correct me if I'm wrong) is that goods are generated and routed, but then pile up at the cargo stations and won't load onto the car that should transport these.
The other way round, some cargoes were loaded on a train but the whole train won't unload these at their next transfer.

Ranran, the points you have made seem to assume that cargo is not generated at all, i.e. it is never transfered from an industry to the cargo station.
That's not the issue Freddy raised here.

[Ranran(retired)]

I think this is a routing (choice of which line the cargo will use) issue.  I have experienced this anomaly on birdgewaterserver for quite some time and reported it in another thread.
I sent an extra lineless convoy to carry a large pile of mail, but it never loaded the mail.
I thought it strange, but on another occasion I checked the reverse route button and found it to load.
Oddly enough, schedule reverses around there, but there is a decision as to whether it is reverse or not.
Cargo may be waiting for a reverse route that does not arrive endlessly.

The capacity is 10 for each wagon, so this should not matter.

What I wanted to say is that either station is congested or has zero capacity (but has cargo attributes) and cannot accept cargo.
I made a freight station with only goods siding, but it is not judged to be connected even if it is connected.
The player is fooled by the display. The factory never use that station.

I'm not sure what this means. What coverage constraint?

The information on whether the factory and the station are connected is ambiguous (diagonally) and it is uncertain whether the 3 tiles ahead are connected.
Sometimes it looks like it's fooling the player.

[freddyhayward]

What I wanted to say is that either station is congested or has zero capacity (but has cargo attributes) and cannot accept cargo.

well the station is certainly congested, because it had accumulated thousands of tons of coal that wouldn't be loaded.

The information on whether the factory and the station are connected is ambiguous (diagonally) and it is uncertain whether the 3 tiles ahead are connected.

Wouldn't it be connected given that goods were generated?

Cargo may be waiting for a reverse route that does not arrive endlessly.

This might be a possibility. I wonder if the intended route could be displayed in GUI? That would be useful information for players even when there are no errors - for example, to see whether passengers are waiting for an express train.

[jamespetts]

Thank you for your report. If you are able to upload a reproduction case, that would be most helpful.

Ranran - can you remind me of the thread in which you reported what you believe to be a related issue relating to convoy choice for freight loading?

[Ranran(retired)]

Ranran - can you remind me of the thread in which you reported what you believe to be a related issue relating to convoy choice for freight loading?

https://forum.simutrans.com/index.php/topic,20116.0.html

I may have posted something about siding goods in the factory GUI thread.

[Matthew]

I believe that I have a Bridgwater-Brunel save where this bug occurs repeatedly. I know that B-B saves are not ideal, but this case is simpler than the others, because it only involves a single destination factory served by a single short line. This screenshot shows the context:



Top right: Ironworks (7493,1458) has no coal in storage. Even if it is not producing, my understanding is that coal that has started on its journey towards that factory should continue on its way.
Top left: Chatingpole King Edward VII Dock has 1,447t of coal ready for loading. The chart shows that this situation has persisted for almost a year (in fact, many years).
Middle left: Bulk goods convoy 10110 has departed King Edward VII Dock unladen.
Bottom left: The only other stop on that line (INC Chatingpole Bulk Wagons) is the one serving that Ironworks.
Bottom right: That line has not delivered any goods for three months.

For some of those months, the line was set to wait until 100% load at King Edward VII Dock, but the convoys just sat there, so this setting does not appear to be significant.

The savegame (419MB) is available here and I believe the screenshot contains all the information needed to locate the offending convoys. Play on / fast-forward from here and watch the convoys fail to load coal. Left to themselves, the next convoy loadings should be at roughly 3:28, 3:40, and 3:50, though you may be able to reduce that by redirecting them to the Dock at game load.

The convoys are all 1 tile length, so the platform length issues reported earlier in this thread should be irrelevant. I added a single-vehicle convoy just to make sure and it made no difference.

As always, if this is not a bug but my mistake, please point out my error! This is a complex simulation and it's very possible that I've missed something.

[Ranran(retired)]

Has the factory or related factories been upgraded in the past? (It's just a speculation of possibility.)

[Matthew]

Has the factory or related factories been upgraded in the past? (It's just a speculation of possibility.)

I think it's very likely that this factory has been upgraded in the past, but I am not certain. As you know, Bridgewater-Brunel has thousands of factories and the Towns log only includes recent changes. It has not been upgraded recently.

[Matthew]

I replaced the steam lorries with a dedicated narrow-gauge railway, but the issue re-occurred (see my previous post for explanation of each window's relevance):



Interestingly, the 'waiting time' for the route is very high, even though the new railway convoy had been running back-and-forth non-stop since its creation, so that waiting time was completely inaccurate.

I forgot to check whether the Ironworks has been upgraded recently though.

I very tentatively speculate that the platform length issue is a red herring. Maybe it is something to do with the way that the Platform Explorer handles bulk goods paths??

[freddyhayward]

A potential issue (or another potential red herring) also brought up here is the mixed load prohibition that only applies to bulk goods.

[Sirius]

Yes, that's what I guessed some time ago on Discord. Might be these thoughts were lost, I'm sorry about not posting it in the forums :(
We shoul try to temporarily remove that restriction from bulk cars to verify this.

[freddyhayward]

If you were talking about mixed load prohibitions, I believe Ranran has mentioned it earlier in the thread.

[jamespetts]

Thank you for posting this reproduction case; apologies that I have not had the chance to look into this yet; I have been very busy at work this week.

Can I check that we have eliminated the mixed load prohibition as being a (legitimate) cause of the reported behaviour?

[freddyhayward]

Can I check that we have eliminated the mixed load prohibition as being a (legitimate) cause of the reported behaviour?

No, it is still a possible cause, but there is no strong evidence for or against it.

[Matthew]

Perhaps it might be possible to make a test build without the mixed load functionality.

Ranran, it appears that these are the commits that implemented the mixed load prohibition:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/7218d0b78a07e9dcda78efa5895a487f4ac911fb
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/c0d649f80afdea3c17d92bc71be6494bbe9066c5
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/4d323ad381923b6f54cf75380c8c11b3c01fa7d5

I realize it was a long time ago, but please share any helpful knowledge.

Also, I feel bad asking you to help remove your commits from the game. It is like asking you to hurt your baby. But your baby is crying. We need to open her and check she is OK inside. So please help me anaesthetize her for the debugging surgery!

Off-topic: I was thinking about this post and I suddenly thought of a good name for your baby. The mixed load prohibition, your CHILD, means that you can NOT mix TWO loads in one WAGON. So the baby's name could be 車·不二子 (EN: Kuruma Fujiko).   

And then I remembered that the mixed load prohibition is only for bulk goods, which often come from coal and iron mines. So your CHILD can NOT mix TWO loads from different MINEs. So maybe the baby's name should be Mine Fujiko (JA: 峰·不二子）。And that is why the wagons do not have loads. The coal and iron has been stolen!!   

[Sirius]

I'd first test this on a pakset base, simply commenting out the load prohibition on those cars. If it works, we know it's most likely related and it's worth to have a more detailled look in this direction.

[Matthew]

I'd first test this on a pakset base, simply commenting out the load prohibition on those cars. If it works, we know it's most likely related and it's worth to have a more detailled look in this direction.

D'oh! You are right, that's a much easier way to do it. I will give that a try.

BTW, a possibly relevant observation. Here are the two stations on my simple bulk goods line serving a single factory, which runs every 3 hours:


The destination end correctly records the waiting time as half the service interval. The departure end has an absurdly large waiting time estimate.

[Sirius]

Oh yes, I had observed something simmilar on some passenger routes on stephenson-siemens, but couldn't isolate the cause nor reproduce it reliably.
There were different waiting times reported to destinations along that route, where there was only one route serving these.
Also, different stops along the same route reported different times to the same destination.
Those differences were not as masive as seen on your screenshot, but still definitely more than a rounding error.

[Matthew]

It's the mixed load prohibition, at least in part. 

I tested using the same save and line as in my post above. Those lorries had the mixed load prohibition so we will call them MLP lorries.
I edited the 4t version of the lorries to remove the mixed load prohibition. We will call these free-loading lorries. I built free-loading lorries and added them to the same line.

MLP lorries were not loading at the King Edward VII dock. Free-loading lorry no.1 loaded correctly. Free-loading lorries 2 to 5 did not load. Free-loading lorries 6 to ..... did load correctly, as did free-loading lorries 2 to 5 when they return to the dock for later journeys. MLP lorries still did not load.

The Path Explorer did not pass over the bulk goods category during the test.

I do not know why free-loading lorries 2 to 5 did not load. Possible factors:

• An MLP lorry was waiting at the choose signal as they arrived at their loading bay.
• Lorry 1 went to the scheduled loading bay; lorries 2 to 5 were directed to other empty loading bays by the choose signal.

I recreated these conditions but the free-loading lorries loaded correctly. So I do not understand why these lorries did not load. It as though the stop was switching between two states, but I do not know any such state mechanism for stops.

So removing the mixed-load prohibition from all vehicles in the pakset should also remove this bug. (Note to self: try to do this by adding (# + searchable phrase) so the prohibition can be easily reinstated.)

But maybe there is also something else happening.

[Sirius]

That's good news! Now we know it's very likely a bug in mixed load prohibition, so it should be easier to fix.

I'd expect your observations about the first few lorries to be related to the line preference feature.. Even if there are multiple routes in between two stations, pax will only use a line that differs from the calculated "optimal" one in some cases. From my experience, this feature does usually work well, but there are some cases where it fails.
If everything loads fine now, it indicates that your new route is now considered to be the best option.

[Matthew]

That's good news! Now we know it's very likely a bug in mixed load prohibition, so it should be easier to fix.

I'm glad it's useful.

I'd expect your observations about the first few lorries to be related to the line preference feature.. Even if there are multiple routes in between two stations, pax will only use a line that differs from the calculated "optimal" one in some cases. From my experience, this feature does usually work well, but there are some cases where it fails.
If everything loads fine now, it indicates that your new route is now considered to be the best option.

The free-loading lorries were added to the same line. So I don't think your explanation applies, does it?

[Ranran(retired)]

If mixload prohibition is the cause, it's usually not seen, so it's important what condition triggers it.
For example, choose signal, standby by schedule, if the loading process is different, I may not have added the mixload prohibition loading process to that part.

EDIT:
May be the second half of fetch_goods()

[Matthew]

If mixload prohibition is the cause, it's usually not seen, so it's important what condition triggers it.
For example, choose signal, standby by schedule, if the loading process is different, I may not have added the mixload prohibition loading process to that part.

Thank you for this response, Ranran.

I observe the bug on two different lines. One was a truck line using a choose signal. One was a narrow-gauge railway line that did not have a choose signal. So I do not think the choose signal affects this.

I also tried running both the truck line and the narrow-gauge railway line with and without a schedule. The bug continued. But I did not change the line. So I will do some more testing here.

[Ranran(retired)]

I've done some testing too, but so far I haven't been able to reproduce this bug on a small map so I can't figure out the cause. (´・ω・｀)

[Matthew]

I have been able to reproduce this bug on a small map! 

The save is here.

The Douggairn Coal Line runs from Douggairn Cathedral Railway Station to Douggairn Coal-fired Power Station Stop.

The railway station has 76t of coal for the power station, but it does not load onto the Coal Line. Note that the power station has no coal in storage.

The bug occurs on both Linux and Windows. This save was created using an older build and pakset, but the bug still occurs in the latest commit #a32b62c and the latest pak128.Britain-Ex.