News:

Want to praise Simutrans?
Your feedback is important for us ;D.

"Staff shortages" crippling early game freight in 1750

Started by neroden, April 07, 2023, 02:21:53 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

neroden

Quote from: neroden on May 08, 2023, 02:20:35 PMAgree 100%.  I simply haven't had the bandwidth to modify my patch to replace "7" with something which reads those new simuconf.tab settings.

OK.  So on this topic (the other patch which has to go in to make the early freight game playable), I have a couple of things:

(1) a patch for pak128.britain.  This doesn't actually do anything until the code patch goes in, but should be safe to commit.  (Note that I initially got the name of the config option wrong, but that's fixed now -- there should be two commits in this pull request)

https://github.com/jamespetts/simutrans-pak128.britain/pull/157

(2) an updated patch for the code.  This checks the settings from simuconf.tab.  (And it is now working, once I fixed my naming error in the pak patch.)

https://github.com/jamespetts/simutrans-extended/pull/611

What I have not done here is to store the settings in the savegame file.  I would really rather not store the settings in the savegame file; this is the sort of workaround where a newly loaded savegame should be updated whenever the pak is updated.  If that's OK, I think this should work.  If there's some sort of network sync issue (which there shouldn't be, because everyone should need to have the same version of the pak, right? -- but I don't know) then I'm going to have to leave it to someone else to patch it into the savegame.  I've always had trouble with stuff which involves patching new data into the savegame.

jamespetts

Thank you for that. I do not need you to generate a large number of maps - if you can just upload one map where you can reproduce the problem reliably (even one that you have already generated), that would be very helpful. Even some map generation settings from which you can reproduce the problem reliably would help. I really do need to be able to see the problem myself so that I can see exactly how it manifests and what affects it in order to be able to conceptualise the right kind of solution and calibrate it properly.

In terms of simuconf.tab settings, it is necessary to have these saved with the saved games for network sync purposes: although players should have the same pakset version, players may have customised their simuconf.tab file, so it is always necessary to save any simuconf.tab setting that affects the gamestate in any 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.

neroden

Great.  Then I'm going to ask you to figure out how to save the simuconf.tab settings in the savefile.  This has always been an area of the code I have a lot of trouble with, and it'll be easier for YOU to do it.  For single-player purposes, it's far better to not have it in the savefile so that it's overwritten by a new version of the pak.

In the long run, we really need to separate pakset-specific settings from settings designed to be overwritten by players, which would eliminate this mess, but this is a very hairy problem since they've been totally entangled for decades.

The game is playable (in single-player) with my patch and unplayable without it. If you could make the effort to get my "make the game playable" patch in by adding what you feel you need for network play, I would appreciate it.  I don't have the time.  I will play my "it actually works" version; I do not have the time this year to spend on adding things you want, which do not benefit me, to the patch.  Please add those yourself.  Thank you in advance for doing the work.

I will probably push a branch on my repo called "playable-version" or something for other people who have the same problem.  I'm getting irritated, if you can't tell.

neroden

One of the savegames proving the staff-shortage problem linked at https://nerode.org/temporary/

If it doesn't load, well, that's version incompatbility due to the varioous updates which have happened.  I don't have time to generate a new map.

jamespetts

Thank you very much for that: I have downloaded the map and confirm that I can open it with the latest build. I will investigate this when I have some time.

As to saving new settings, the procedure is as follows.

  • Add the datum for the new setting in settings.cc and the code for initialising the default value and reading/writing this from simuconf.tab (I assume that you know how to do this, so I have not explained this in detail).
  • In simversion.h, increment the EX_SAVE_MINOR by 1.
  • In settings_stats.cc, ensure that static const char *revision_ex[] includes the character sequence for a number at least this high, and, if not add it. This allows the manual selection of this version as a save version in the advanced settings dialogue. (This step is often forgotten).
  • Add a line for reading/writing the value, conditional on the saved game version being at least or greater than the current combination of major and minor save version, in void settings_t::rdwr(loadsave_t *file). For example, if the current major version is 14 and the current save version is 61 (and you have thus just incremented the value to 62 for your new addition), you will need to add the line reading/writing your new datum inside a code block for the following if statement: if(file->is_version_ex_atleast(15,62)). Note that the is_version_ex_atleast() method is relatively new. A lot of code is written in the older style of if (file->get_extended_version() >= 15 || (file->get_extended_version() == 14  && file->get_extended_revision() >= 62). The line for reading/writing the value itself depends on the value type. For example, if the datum were of a uint32 type, then the code would be: file->rdwr_long(new_value);.
  • Add the new setting to the advanced settings dialogue so that it can be changed in-game. Do this in settings_stats.cc. The easiest thing to do here is just copy the code for a similar type of data.
  • Add the getters and setters: I assume that you know how to do this.

A good way of checking that you have added all of the necessary code is just to use your IDE to search for all instances of a pre-existing datum. Once you have ignored all of the instances that are specific to the data type (and these will be few, if any, as the getters and setters will normally be used for actual running code), what remains should be what you need to add for the new value. Note that this only works for step 4 and onwards above.
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.

jamespetts

I have now had the chance to carry out a controlled test of this. I took the saved game, which had the default values, and, using the advanced settings dialogue, modified it in one instance of the save to match Nathaneal's suggested modified values (fixed so that the minimum and maximum were no longer inverted). Note that I had to make a small change to the advanced settings dialogue to allow such large numbers to be inserted manually.

The results are as follows.


The results do show differences between the two, albeit less dramatic than Nathaneal's posts might suggest. At the end of the 6 years, the actual industries served by the transport network had a roughly similar level of staffing, but a number of smaller towns had much better staffing levels in churches and town halls than previously, and correspondingly better commuter success rates for passengers. Overall, staffing rates were higher in a number of places. However, there were still many places where staffing rates were low because there were insufficient workers of the correct level of wealth within range and other places where commuting success rates were low because there were insufficient jobs of the correct level of wealth within range.

I have not yet had a chance to test whether such higher numbers have a substantial impact on performance. Subject to such testing, and subject to any feedback from this result, I am minded to commit the changes to commuting trip alternative destinations that I had implemented in this test scenario. I should be grateful for any feedback on 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.

neroden

Well, that's a pretty good outcome -- one does want staff shortages to happen in the "economically realistic" situations,  just not because everyone is turning down the job at their doorstep.  Better behavior in small poorly served towns is exactly what I was going for, it really helps the early game.