News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

[ Nightly 120.1.2 12.9000 - r941d223 ] New routes won't transfer from industry

Started by A.Badger, February 11, 2017, 06:25:01 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

A.Badger

New routes won't transfer from industry to dock

Update: Still occurs with 120.1.2 - 12.9000 - r0a2b67b downloaded on 20-02-2017
Pak: nightly Pak128.Britain-extended downloaded 17-02-2017
Platform: Linux, Fedora 25, x86_64
Play start: 1750

This is my first time playing experimental so at first I thought this was user error (still might be) but I've run into it three times with several differences in how I set up the routes.

* In my first game-month I created a Grain Farm => Windmill => Bakery route via canal boats.  This worked fine.

* After 2 game years, I attempted to expand this so that the Windmill went to 2 bakeries.  I found that the new bakery never requested flour so there was never any new grain shipped.  I tried connecting a route to a different bakery.  Same thing, the bakery never requested flour and only the original bakery was served.

* Went back to an early save and created routes from Grain Farm => Windmill => 3 Bakeries.  This worked fine and served flour to all three bakeries.

* Few game years later, a new Clay => Pottery => China industry chain was generated in very close proximity to each other (In sample map, this is Stomead to Dashport, centered around (400, 374).  The attempted route is not present in this save game, however).  I attempted to connect those via horses and carts.     Once again, the clay pit never sent any of its stored clay to the connected cargo bay so nothing was transferred from there to the Pottery or from the Pottery to Dashport's China Shop.  Dashport is very small so I thought perhaps it was a problem with not enough population in Dashmead to generate demand.

* Reverted to an earlier save where my grain => windmill => 3 bakeries was working well and next tried to create a colliery => coal merchant route via canal & sea.  Once again, the colliery never moves any coal from its internal storage into the linked dock so no coal flows along this route.

Uploaded save game with the Coal => Colliery route to http://toshio.fedorapeople.org/simutrans/Production-will-not-start.sve  The Colliery is served by the Bloxbrook Colliery Dock (589, 717).  A barge is supposed to ship the coal via canal and river to the Linworth Junction Dock (539, 808).  Then a narrow boat is supposed to take the coal to the Wetingston Junction Dock (485, 830) where it's loaded into a Brig and hauled to the Hardwick Coal Merchant Dock (440, 828).

jamespetts

Hello and welcome to the forums. Sorry that you are having trouble. I am staying with my parents this week-end, so am not able to work on the code until next week, but, in the meantime, one very simple thing that might be user error: are the industries actually connected to one another? In Simutrans (both Standard and Experimental), industries will be connected only to specific other industries, not any matching industry.
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.

A.Badger

New data.  It seems that saving and then loading the game resets something so that this bug temporarily goes away.  I downloaded the current version of experimental and loaded my save game to see if the bug might have been fixed in the past few days.  At first I thought it had as the colliery barge filled and left the station.  But then I noticed that the next ship in the route did not seem to fill.  I messed around with the second ship for a while with no success.  Then decided to recreate the Clay => Pottery route to test this.  I went to Stonmead.  Put down one small cargo station near the clay pit.  Put down another small cargo station near the pottery.  Linked them with regular roads.  Added a Stable.  Made a two-horse bulk goods cart and set it to go to the clay pit, wait for 100% load, and then return to the pottery.  Clay did not flow from the clay pit to the station to get this new route started. 

I then saved the game, quit (I believe I could have just loaded the saved game but I wanted to be sure), and restarted.  I loaded the game after restart rather than relying on the autosave.  The clay pit sent cargo to the station and the route started working.

So it seems like there is a bug but saving and reloading the game resets something which allows new routes to get populated.  Perhaps something that's supposed to be on a timer is instead only being triggered when a map is loaded?

A.Badger

Regarding your question about just using industries that are linked, correct, I'm connecting industries that list each other in their information box for suppliers and consumers.

jamespetts

Thank you very much for the clarification and additional information: that is helpful. I will look into the bug when I have some time. I am sorry that you are having difficulties. I should note that a queue of bugs has built up in the last few weeks, so it may take some time to get around to it, but I will post in this thread when I have fixed it.

Thank you for your report.
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.

Junna

I have noticed some weird bugs where I have a lot of goods piling up that is not loaded onto the trains. Also I have a station that has a 9 hour transshipment time?

jamespetts

Quote from: Junna on February 12, 2017, 12:19:02 AM
I have noticed some weird bugs where I have a lot of goods piling up that is not loaded onto the trains. Also I have a station that has a 9 hour transshipment time?

If you could post a separate report for each bug and upload a saved game in which each specific issue can reliably be reproduced, I should be very grateful.
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.

A.Badger

Symptoms here seem the same as this bug from December 2016: http://forum.simutrans.com/index.php?topic=15921.0

This bug report from Feb 4 may be the same as well but there's enough unknowns in that report that I'm not sure: http://forum.simutrans.com/index.php?topic=16647.0

accord2

Is this fixed? I think this keeps happening in my game. The cargo is not transported to the next industry, it isn't produced at all. However, when I exit and enter the game again, everything works fine.
Son of a railroad man,  growing up in train stations, lover of trains

jamespetts

Can you test to see whether the latest fixes relating to cargo transfer and production fix this issue? I should be most grateful.
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.

A.Badger

Retested with: "Simutrans 120.1.2 Extended Nightly development build 12.9000 - rbaa9703"  ;; does not appear to be fixed.

Used the save game posted above and created a route in Stonmead:
* Unsurfaced road connecting Stonmead Clay pit (471, 385) to the roads in stonmead.
* Cargo Bay (small) placed at (474, 385) to connect to clay pit
* Cargo Bay (small) placed at (491, 375) to connect to the pottery at (490, 374)
* Created a small spur and created a coaching stable in stonmead.
* Created a convoy consisting of a pair of horses and a Wagon (bulk goods)
* Scheduled the convoy to travel between the two stops.  Set Minimum load on the clay stop to 100%
* This was completed at the beginning of March, 1752.  Ran the game until the beginning of November and the convoy never picked up any goods.
* Saved and reloaded the game.  The clay pit and pottery windows immediately showed that the two were connected (the little brown icon appeared beside each other's entry in their windows).
* Soon after, the clay pit dumped 20t of clay.
* 1:15 in November (after the reload), the wagon was loaded with its first set of clay and travelling to the Pottery.

accord2

Son of a railroad man,  growing up in train stations, lover of trains

A.Badger

James, do any of the changes you want us to test for this require starting a brand new game?

A.Badger

@accord2, if you start a new game with the current nightly, does this still occur?  I've started a brand new game with a self-compiled checkout from yesterday and so far haven't had this problem recur.  Will have to play for a while longer to see if having more lines or a later year changes things.

A.Badger

Answering my own question, I am now in January 1754.  Created my first grain => windmill route on this map (already have some bulk routes with coal & iron ore; already have "multi-stage routes" (industry1 => industry2 => industry3)  involving livestock => slaughterhouse => market) low traffic routes going to markets) and have encountered this again.  So it's still present.  Still not sure precisely what the trigger is although it is repeatable from a save game (see my above steps with a save game and clay pit).

Currently have 20 routes served by 48 vehicles (all ships).  24 stations.

jamespetts

Thank you very much for your testing and analysis on this. Would you be able to upload a saved game in which this issue can be reproduced (perhaps your 1754 game with an industry route not connected)? I should be most grateful.
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.

A.Badger

It's hard since I need a save game from before I create the route.

Here's the best I've been able to do: https://toshio.fedorapeople.org/simutrans/Production-will-not-start6.sve

This is the Stonmead save game from earlier with a few more things built.  I've managed to create most of the route from the clay pit to the pottery.  It appears that the critical factor to making a save game where the problem is present is whether the station at both the clay pit and the pottery have been created before the game is saved.  So when you open the game, it should be centered around Stonmead.  The route has almost been completely built.  Do the following to finish it and see the problem:

* Create a road cargo bay (small) at the pottery location (491, 375)
* Open the Coaching Stable at (487, 377).  There should be a bulk goods convoy ready to have a schedule configured.
* Schedule the convoy to go to the clay pit cargo bay (474, 385), wait for 100% load, then go to the pottery cargo bay that you just built.
* Finish the schedule (doesn't matter whether you promote it to a line or not)
* Start the convoy.
* The convoy should travel to the Clay pit then stay there because it never has anything to load.

* Other observations: The clay is not even sent to the cargo station.
* If you open the window for both the clay pit and the pottery you will see that neither one appear to connect to the other:
  * The bars underneath their pictures are red.
  * No small icon shows up in the Consumer and Supplier lists to show that they want to transfer goods to each other.
* Saving and reloading the game at this point (or indeed, anytime after you create the second Cargo Station) should allow the industries to transfer goods to each other practically immediately.
* I'm not sure what all the preconditions are for this to start occurring.  When I first start a game in 1750 I am able to create routes without having to save and reload. It's only later (this game is 1752) that this problem starts occurring.  I believe that once it starts, it is a problem for all future routes but I'm not 100% certain.  My current gameplay is to setup routes, save and reload, and then make sure that all my newly connected industries are sending goods back and forth so I don't know if save and reload is needed for every new route that I create.

jamespetts

This is very odd - I am afraid that I cannot reproduce this at all, either with the Visual Studio debug build or the release build downloaded from the Bridgewater-Brunel server. I have tried many times, but, each time, the clay pit starts producing clay and putting it out to the stop a few seconds after starting the convoy on its way. This occurs whether I create a new line in the depot window or edit the individual schedule directly.

I wonder whether there could be some difference between Windows and Linux builds here? That would be exceedingly bizarre, however, as it is hard to see what in the code relating to this that might behave in that way.
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.

A.Badger

if you tell me where in the code the game should be determining whether an industry is connected I could drop some printf()'s in and see if I can find something else.  (Perhaps a thread that updates industry connections is deadlocking on Linux but not under Windows?)

jamespetts

I am not sure that this is confined to industry, actually. A user recently reported the following to me by e-mail:


If one sets up a new line, stops do not
connect to other stops on the same new omnibus line ("no
connection.png), albeit walking connections to other stops are shown.
This results in completely empty omnibuses on the new line.
As soon as the game is saved and then reloaded, the connection is shown
and the omnibuses are filled with passengers.
This is similar to the error I reported on 28. December 2016.
The difference is: This time, I could not reproduce this error when I
set up my first line (an intercity-omnibus line). My second omnibus-line
(within the same city) then showed this error again as reported in December.


As to places in the code, there are a lot of different things that the code does in a lot of different places to which something with these general symptoms might relate, so pinpointing which is the relevant bit of the code would probably involve at least half as much work as solving the problem entirely, and may very well be nearly all the work necessary to solve the problem entirely.

Have a look, however, at simconvoi.cc, path_explorer.cc and simhalt.cc, as these are the main areas of code that are relevant if these two things are indeed one and the same problem.

Thank you very much for your help with 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.

A.Badger

Might not be a deadlock.. Just compiled with:


DEBUG = 3    # Level 1-3, higher number means more debug-friendly, see Makefile
#OPTIMISE = 1 # Add umpteen optimisation flags
MULTI_THREAD = 0 # Enable multithreading


and the problem is still occurring.  I'll look at putting some printf()s into those files and see  if I can find a function that I think should be running that's not being hit in this case.

jamespetts

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.

A.Badger

So far, by turning on DEBUG_COMPARTMENT_STEP and that adding a few more printf()'ing at various spots in path-explorer.cc I've found that
connexion_list[ current_halt.get_id() ].connexion_table->empty()
at https://github.com/jamespetts/simutrans-extended/blob/master/path_explorer.cc#L1041 Returns 1 instead of 0 when we're in the buggy case.  I haven't been able to determine where goods connections are entered into connexion_table, though, (I only found where passengers that can walk to a stop are entered into the able) so I'm not able to figure this out further.  (If this never worked for me, I'd think that goods routes aren't being entered at all but when starting out with a new game it is working.  And obviously if it's working on Windows, that also means the connections must be entered into the connection table somewhere...)

The last time I touched C++ was 19 years ago so I'm probably just missing some detail about how C++ can reference the connexion_table which makes my grep skills fail.

Once I found this out, I did confirm that the user interface shows this to be a problem: https://toshio.fedorapeople.org/simutrans/direct-routes-empty.png

* On the right, you can see that the clay pit stop knows of no direct routes.  It does know that there are two convoys that are serving it, though.
* On the left, you can see the schedule for one of the convoys.  It has the clay stop and the pottery stop in it so the pottery stop should be showing up as a direct route.

jamespetts

What appears to be happening from the screenshot is that the convoy (which is not assigned to a line, it seems) is not being registered at the stops that it serves. As an aside, does this only happen when using convoys that are not part of a line? I always use lines for testing rather than individual convoys (although I did try testing with individual convoys in the test that I described above), so errors with individual convoys might end up being not found as easily.

Convoys (without lines) registered at a stop are logged in the registered_convoys vector in haltestelle_t (simhalt.cc/h). Lines are registered in registered_lines in the same place.

The method for adding convoys to registered_convoys is haltestelle_t::add_convoy, which is called from convoi_t::register_stops and also from tool_stop_moving_t::do_work() (but the latter is a specialist case only used when the player uses the move stop tool).
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.

A.Badger

It happens with both.  I've just verified that the UI reflects the lack of registered lines as well as registered convoys.  Looking through the functions that you mentioned now.

jamespetts

Thank you for clarifying that. It is very odd that I cannot reproduce this; I cannot imagine what could be different between Linux and Windows in this regard, especially since I cannot reproduce it on a cross-compiled build, either.
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.

A.Badger

Just realized I'm going to be out all day.  I'll try to get some debugging time in tonight.

jamespetts

That is very helpful, thank you. Do let me know what you are able to find. I am currently working on importing translations of the code from German to English from Standard to make it easier for people to work on the codebase.
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.

A.Badger

Okay, I think this conditional is the problem: https://github.com/jamespetts/simutrans-extended/blob/master/path_explorer.cc#L774

If I change it like this:

- if ( current_halt.is_bound() && current_halt->get_inauguration_time() < refresh_start_time && current_halt->is_enabled(ware_type) )
+ if ( current_halt.is_bound() && current_halt->is_enabled(ware_type) )


then when I run my test case, the industries connect as soon as I start a convoy running between the two stops.

My first guess would be that get_inauguration_time and/or refresh_start_time is getting its value initially from system APIs and that those types are subtly different on Linux and Windows.  It could be a signed/unsigned problem or the sizeof the type could be overflowing and wrapping around on Linux but not on Windows.

A.Badger

* ./path_explorer.h:              unsigned long refresh_start_time;
  * Side note: been a long time but I think this is nonportable.  http://stackoverflow.com/a/384672 Windows 64bit defines long as a 32bit type whereas all modern Unix defines it as 64bit.

Root of the problem appears to be:

./simhalt.h:    uint32 inauguration_time;
./simhalt.cc:   //inauguration_time = dr_time();
./simhalt.cc:   inauguration_time = welt->get_zeit_ms(); // Possibly more network safe than the original (commented out above)
./simworld.h:   sint64 get_zeit_ms() const { return ticks; }
./simsys.h:uint32 dr_time();


refresh_start_time is a uint32 being set from dr_time().  In my build I'm using SDL2 and that appears to set dr_time as the number of milliseconds since the SDL library was initialized.
inauguration_time used to be a uint32 set from dr_time() but now it's a uint32 being coerced from an sint64.  It's set as the number of milliseconds since the map was created.

It seems like there's two bugs here which can both cause problems: The difference in types (which is what I think is happening in my particular test case) and  inauguration_time and refresh_start_time start having different bases (SDL initialization vs map creation).

jamespetts

Thank you very much for this: that is very helpful. I have pushed modifications to both parts of this. I am not able to test whether this fixes the underlying problem as I have had trouble in reproducing it. I have tested as to whether it works, and it does seem to work. (It does not solve the desync on multiple connexions to the server bug, but that is another matter).

Can you test to see whether this fixes the matter?
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.

A.Badger

Self compiled c2c78c86184da9aefcf946387f0de8cf2e22752f and it works!  yay!.

I do worry that there is a latent bug in inauguration_time, though.  inauguration_time is still a uint32 but it's set from get_zeit_ms() which returns sint64.  So the number being returned can overflow and cause this same behaviour if a game has been played for long enough (This would be exacerbated with an increased ticks per month in config).  Pull request to change inauguration_time into an sint64 here: https://github.com/jamespetts/simutrans-extended/pull/50 which doesn't appear to break anything (I only see inauguration_time being used with the code we've been working on here).


jamespetts

Thank you both for testing, and thank you especially to A. Badger for diagnosing the problem and committing the overflow fix, which I have now incorporated: that is extremely helpful.
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.