Re: [patch] Powerline network stabilization

[jamespetts]

The version on your Github - is that just for Standard?

[neroden]

The version on your Github - is that just for Standard?

Well, yes, not that that should stop you!  You could of course attempt to merge it (I don't know if it merges cleanly -- I was going to try that later, after I'd checked that it worked right in standard, which I haven't done yet.)

EDIT: It works in standard.  I'll merge it to the jp-devel branch now....

EDIT: It seems to interact painfully with the "city supply" code.  I'll see if I can merge that.
EDIT: Worse, it interacts with the "get_electricity_proportion" code.  What is that supposed to do?  I can't merge until I know what I'm trying to do.

EDIT: I think I've got the electricity_proportion; I pushed it down into the fab code, which seems more correct.  I'm now having some subtle problems with the city supply code.  Here's a corner case: is it possible for a substation to *both* supply a city *and* supply a factory which is *not* in that city?  Apparently so.  Ow.  Also, James, note that factories are always located in the city earlier in the city iterator, which is arbitrary and random when cities overlap -- the city electric supply code is probably going to need some work on your part.  (EDIT: Note that a city contained within another city may be *impossible* to supply.   Maybe I need to write that city merger code....)

EDIT: After many hours of work I think I have it merged properly into experimental (jp-devel branch).  Someone should probably test it -- I've been playing experimental with the timeline "before power lines" mostly.  This doesn't address the pre-existing issues with city power supply (regarding overlapping cities) but should address everything else.

EDIT: It's not working.  After building city substations it crashes eventually -- 'fab' is getting set to garbage at some point which I can't find for no apparent reason (after being set to 'NULL' at first).
EDIT: OK, it's working (still with bugs in experimental though, working perfectly in standard).  In a game with the timeline turned off, cities have 0 power demand unless they have factories, however.  Also, the new graphic is working OK for substations.  I still can't figure out what's causing the corruption in the value of 'fab', though -- it may be a pre-existing bug in experimental.

[jamespetts]

Neroden,

thank you for all your work on this. This looks as though it will need a little more work before it goes into a release version. I'm not aware of the problem with the "fab" pointer being set to junk instead of NULL - that sounds like a very difficult one to track down. get_electricity_proportion(), incidentally, is designed to work, if my memory serves me correctly, with electricity.tab to deal with the varying demand and importance of electricity in cities over time.

What are the bugs that remain in Experimental with this? Are they crash bugs? The overlapping issues can be tolerated in the short-term until the city merging feature is complete, but obviously we don't want to release a binary with any known crash bugs.

Does this answer what you need to know for the time being, or do you need anything else?

Edit: I have put your patched version on the -devel branch, but it refuses to compile with this error:

Code Select Expand


1>gui\stadt_info.cc(190): error C2065: 'POWER_TO_MW' : undeclared identifier
1>gui\stadt_info.cc(190): error C3867: 'stadt_t::get_power_demand': function call missing argument list; use '&stadt_t::get_power_demand' to create a pointer to member
1>  settings_stats.cc


Edit 2: How best to merge in Standard, which contains the powerline stabilisation patch in its original form?

[neroden]

What are the bugs that remain in Experimental with this? Are they crash bugs?

Yes, there's one key bug -- the one where fab somehow ends up with a value (but not a valid one) on city substations.  I've been trying to trace it but I can't.  It starts out NULL, but *SOMETHING* causes it to change -- eventually, after long time periods -- and I can't figure out what.

Everything else worked without crashes until I started trying to fix the logic errors in the city electricity use code and now that I've fixed those everything else seems to work, mostly.   Though the per-citizen demand for power needs to be tweaked.

Edit: I have put your patched version on the -devel branch, but it refuses to compile with this error:

This was fallout from attempts to fix the bugs which I finally fixed on the 8.x branch; I have finally got both sets of fixes compatible in the jp-devel branch as of a couple of minutes ago.

Edit 2: How best to merge in Standard, which contains the powerline stabilisation patch in its original form?

I'll do it.

EDIT: Merge from standard completed successfully in my jp-devel branch.  

Also, I think we can live without tracking down the occasional corruption of 'fab' -- after the latest merges I managed to run a game for long periods without encountering the crash, so it was probably fixed by other changes in standard or experimental.

There still seem to be a few bugs in the city power demand code (behavior when the timeline is off seems unclear and questionable, I suspect the quantity of power demand is simply too high, and there's still some question of months vs. quarter-months), but it's fundamentally working at this point.

EDIT: Oh.  And it doesn't behave quite right if a city has two substations, which isn't prohibited.  Simplest solution would be to prohibit that.  There are clearly more complex solutions possible.

EDIT: GRRR, the fab bug is back.  It seems to have happened after deleting a substation.  Is it possible that there's an obsolete (deleted) substation on the substation list when 'step' is being executed?  This would account for the garbage data.

[jamespetts]

Neroden,

I've found the problem with the "fab" pointer: the destructor was not working properly, as it only activated its substantive code if there was a factory to which it was bound, not if there was a city. I have fixed that and pushed the fix to the -devel branch. I have also fixed the power consumption rate, as it was 10x too high for cities: you had, I think, used * 0.2 rather than *0.02 in one particular method.

As to prohibiting multiple substations, this is not a solution, since a substation might be built outside a city, and then the city grows to engulf the substation. What goes wrong if there are two substations in a city? In any event, it should be possible to have two substations in a city: what if more than one player wants to supply electricity to a city, each from a different power station?

Thank you very much, though, for your hard work on this. It is much appreciated. The next question is: should we consider merging this into 8.x before release, given that it's already in the Standard nightlies now, meaning that, because of the change in loading/saving code, 8.0 would not be able to load games from the Standard nightlies if it was not incorporated?

[neroden]

Neroden,

I've found the problem with the "fab" pointer: the destructor was not working properly, as it only activated its substantive code if there was a factory to which it was bound, not if there was a city. I have fixed that and pushed the fix to the -devel branch. I have also fixed the power consumption rate, as it was 10x too high for cities: you had, I think, used * 0.2 rather than *0.02 in one particular method.

Excellent, you fixed the two bugs I couldn't!

As to prohibiting multiple substations, this is not a solution, since a substation might be built outside a city, and then the city grows to engulf the substation. What goes wrong if there are two substations in a city?

Power supply errors in one form or another.  I haven't worked out all possible failure mode.  I will say that it doesn't affect power supply to factories, so it's certainly no worse than any version of standard.

Thank you very much, though, for your hard work on this. It is much appreciated. The next question is: should we consider merging this into 8.x before release, given that it's already in the Standard nightlies now, meaning that, because of the change in loading/saving code, 8.0 would not be able to load games from the Standard nightlies if it was not incorporated?

Yeah, we should.  The city supply problem should probably be fixed though, which is a pain.

[jamespetts]

I've just pushed an updated version to Simutrans-Experimental's -devel branch on Github, which fixes the multiple substations in one city issue. I've also added some translations in the Simutrans-Experimental texts repository. I'd be very grateful if anyone with the time and inclination to compile from source could test the implementation of this patch in Experimental that Neroden and I have been working on to see whether there are any bugs left.

[sdog]

just pulled from your devel, compiled without problems.

most changes are in leitung2.cc i think, so i'll post the warnings too:

Code Select Expand


dings/leitung2.cc: In member function 'virtual void leitung_t::rdwr(loadsave_t*)':
dings/leitung2.cc:455: warning: deprecated conversion from string constant to 'char*'
dings/leitung2.cc: In member function 'void senke_t::step(long int)':
dings/leitung2.cc:718: warning: comparison between signed and unsigned integer expressions


simcity.cc: In member function 'void stadt_t::calc_growth()':
simcity.cc:2037: warning: comparison between signed and unsigned integer expressions
simcity.cc:2040: warning: comparison between signed and unsigned integer expressions
simcity.cc: In member function 'void stadt_t::step_passagiere()':
simcity.cc:2406: warning: comparison between signed and unsigned integer expressions
simcity.cc:2916: warning: enumeration value 'good' not handled in switch
simcity.cc:2411: warning: unused variable 'passenger_routing_longdistance_chance'
simcity.cc: In member function 'void stadt_t::check_bau_factory(bool)':
simcity.cc:3481: warning: comparison between signed and unsigned integer expressions


runing it now:

Code Select Expand


Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe2e8) at simsys_s.cc:720
720 {


i'm starting it with the last release of pak128britain exp.
can't get mose running.

testing power lines


conected a townhall to a substation, demand was 2 MW.
built another substation adjacent to it, both subs at 1 MW each.
the powerplant has 106 MW output, and is supplied with 50/500 t [sic!]* coal

built a sub. at a nearby factory, power droped to 0 MW on all three substations.
after deleting the substation at the factory the subs at townhall provided 2 MW again. the factory was very close to the townhall, about 10 squares, sourounded by buildings.
rebuilding the substation was not possible, since "Only one transformer per factory!" (sounds like a very literal translation from german btw, quite rough and imperative)

now i tried to build a sub. at another not conected factory, deleted it, built one again -- without problems. connected it to a 'dry' line, deleted it, built again, again no problems.

tried again, with a powered powerline, connected a coliery, deleted the transformer, and could rebuild it. now i generate output to the coliery, to make it actually draw power. substation at 1 MW, can delete substation and rebuild. connected the closest cityhall.
substation at the coliery droped to 0 MW. It is possible to raze and rebuild the substation however.

built another sub. near a coliery in the same town, closer to the townhall, it provides 2 MW. the factory has a demand of only 1 MW. the coliery is not producing anything however. it is not possible to rebuild the substation after deleting it.

oh, just found out, the substation to provide a town with power does not need to be next to the townhall anymore.

*it should be either 50/5000 or 50 t/ 5000 t the tons will cancel out in a fraction

[jamespetts]

Hmm - I can't seem to reproduce this one, despite extensive testing. Connecting towns by multiple substations, connecting producing and non-producing industries inside and outside towns to substations does not result in load on the network dropping at all - full supply is maintained. See this saved game in which I conducted my test. Note that you will need the gas power station for Pak128.Britain, a .dat file for which can be downloaded here.

Note that factories in cities are automatically supplied with electricity if the city is supplied, so there is no need to connect them separately. Any substation within the boundaries of a city will provide electricity to that city.

[neroden]

I've just pushed an updated version to Simutrans-Experimental's -devel branch on Github, which fixes the multiple substations in one city issue. I've also added some translations in the Simutrans-Experimental texts repository. I'd be very grateful if anyone with the time and inclination to compile from source could test the implementation of this patch in Experimental that Neroden and I have been working on to see whether there are any bugs left.

James, I think you just introduced two major new bugs, in 5df4211d50f69eb62073722f2f206c774d316ffe .  :(

You caused the multiplication by 4 to happen twice:

Code Select Expand


   fabrik_t * fab = welt->get_fab_list()[i];
   if(fab->get_besch()->is_electricity_producer())
   {
-     electric_productivity += fab->get_base_production();
+     electric_productivity += fab->get_base_production() * PRODUCTION_DELTA_T * 4;
   }
   else
   {
@@ -976,7 +976,7 @@ next_ware_check:
 }

 // now decide producer of electricity or normal ...
- sint32 promille = (electric_productivity*4000l)/total_electric_demand;
+ const sint32 promille = (electric_productivity*4000l)/total_electric_demand;


Note the "*4000".  I think you want to change that to "*1000" if you're using the "*4" earlier?

BTW, call me Nathanael.

Code Select Expand


--- a/besch/reader/factory_reader.cc
+++ b/besch/reader/factory_reader.cc
@@ -292,7 +292,8 @@ factory_reader_t::read_node(FILE *fp, obj_node_info_t &node)
   {
     if(experimental_version >= 0)
     {
-       besch->electricity_proportion = ((float)decode_uint16(p) / 100.0F);
+       besch->electricity_proportion = ((float)decode_uint16(p) / 750.0F);
+       // Reduce factory electricity consumption by factor of 7.5, as it was formerly far too high.
       besch->inverse_electricity_proportion = 1 / besch->electricity_proportion;
     }
     if(experimental_version >= 1)

This is getting into extraordinary hacky territory, and is almost certainly very buggy.

Electricity_proportion should be set in the .dat files in the pak (correctly); if not there, it should be set from the default number (.17).

I don't think it should be saved with saved games at all, actually (factories should 'magically upgrade').  If it *is* saved with saved games, then you want to change the factor when loading *old saved games only*.  Otherwise the electricity_proportion will be reduced by a factor of 7.5 each time you save and load).  

You need to rewrite this completely.

EDIT:
The other commit is even more problematic.

I suspect your city power supply code will be buggy as well due to failing to follow the principles of the power network stabilization: namely, that when we check to see if a power net is overloaded and not supplying enough, we must use *last month's demand*

Code Select Expand


if(supply < (shared_power_demand / (city_substations_number - checked_substations.get_count())))

This needs to use "last_shared_power_demand" (which doesn't exist of course).  "last_power_demand" is close enough though.

You also managed to totally break the case where the substation is both a city substation and connected directly to a factory.

That's OK though.  I'm thinking at this point that the supply code is too complicated.  We need two types of substations: one which connects to factories (and not cities), and one which connects to cities (and not factories).  This will simplify the code *immensely*.  They can be built with the same tool and autodetect based on whether they're next to a factory when built or not, just like sources and sinks are built.

And there's definitely more bugs in the multiple-substation-city-supply code related to the inconsistent use or non-use of load_proportion.

I actually suggest reverting the 'two-substation' commit (92c4475f2e6cdc20bc7027cf0ce0f349773a6611) entirely and trying again after splitting substations into "city substations" and "factroy substations".

Add back the part which worked right:
CHANGE: A downstream substation will now display the city in which it is located.

On an almost unrelated note, I realize that we need to allow multiple substations per factory -- for different players.    That change should go into standard.  Separating city substations and factory substations will make it easier to implement and debug these separately.

[jamespetts]

Nathanael,

Issue 1

Fixed in the latest commit - thank you for spotting this.

Issue 2

This isn't saved with saved games - this is in factory_reader_t, which reads the "besch" (base types) of the industries from the .pak files. The rdwr files load and save things with saved games. This will not, therefore, be reduced by a factor of 7.5 on every load/save cycle. The reason that this is put in is to calibrate the electricity consumption accurately - even at 17% it is far too high, and 17% / 7.5 starts to get to numbers too small accurately to be represented by integer percentages.

Issue 3

I haven't noticed any instability associated with this, despite somewhat extensive testing: see the saved game file that I posted previously. This cannot use last month's demand because that is already set to the shared proportion:

Code Select Expand


last_power_demand = shared_power_demand;


If "last_power_demand" was used, therefore, it would keep reducing the proportion over and over again at each step.

Issue 4

In what way does this not work properly when a substation is connected directly to a factory not in a city and is also connected to a city? Perhaps by far the simplest solution would be to prevent substations in cities supplying factories directly, as it is a very marginal case when a substation in a city can be next to a factory that is marginally outside the city boundaries and thus not supplied by the city's electricity supply itself. That would then obviate the need to have two entirely different sorts of substations, and thereby  make things much easier generally. This would also not require resetting all the work that I have done already in relation to multiple substations in a city.

Issue 5

I'm not sure where the inconsistent use of "load_proportion" is: where ought it be used that it is not used? What is the effect of this?

Edit: I have found some issues in situations where more than one substation serves a city, one of which is connected to a network whose capacity (taking into account other demands) is less than that substation's equal share of power input for that city: that is now fixed in the latest push.

[TurfIt]

It's nice to see this patch being incorporated...

As for the multiple transformer station problem, I encountered 2 main problems when this was allowed.

1) An inconsistency between the performance from the initial construction and the performance after a save/reload of the game.
    The first transformer connected to a fab, when stepped will attempt to supply the entire load. Subsequently stepped transformers will only load if the earlier ones had insufficient supply. IIRC the transformers step newest to oldest after construction. However upon loading, they step based on their geographic location - NW to SE.
    Fixable by iterating along a sorted list rather than a simple linked list. Also would be fixed by default by addressing problem #2.

2) Non optimal use of the total available power across multiple powernets.
    By this I mean the first stepped transformer may supply too large a proportion of a fabs load leaving it's connected powernet short on power and a subsequently stepped transformers powernet with an unused surplus. Something has to coordinate >> This essentially becomes the classical 'generation dispatch' problem in power systems engineering.
    Fixable by implementing a load dispatcher routine that determines how much power is supplied through each transformer. Such routines are classically implemented using linear equation iterative solvers on an equation set representing the entire interconnected power system. The required information to assemble the equation set is spread across multiple classes in the Simutrans code. I think a complete refactoring of the power supply code would be required to cleanly implement a dispatcher, hence why I took the simple route of restricting transformers to one per... I'm also concerned about the ability to create a solver that converges on a globally optimal steady (non-oscillatory) solution in a finite and very short amount of time (will need execution every step) given automatically created seed values for all cases of weird and crazy power system layouts that players might dream up. This seemed a lot of work for no real benefit as in the original thread nobody came up with a reason for multiple transformers. But now...


Multiplayer.

Not something I had even considered. I'm aware of the ongoing work to add multiplayer functionality, but still tend to think of this style of game as best a single player experience. I think this requires some discussion on how things should work in a multiplayer environment.

My thoughts on requirements:
   Powernets remain separate between players. Allowing one player to extend another's network gets too complicated IMO. Partial payments, etc.
   Retain one transformer per factory per player limit. Players should be encouraged to merge their own networks. Prevents one player blocking access by surrounding the whole fab with transformers. Limits complexity in the dispatch routine.
   Senkes only delivery power to fabs - no power flow through a fab. i.e. power will not flow powernet1>senke1>fab>senke2>powernet2. Greatly limits complexity in the dispatch routine.
   Power flow tries to split evenly between players servicing the same fab but the dispatcher will adjust as necessary to ensure the maximum power is delivered globally.
   No UI controls - automatic. Players simply place transformers and lines.

I think the above is fine for a cooperative multiplayer session. For an adversarial competition, not so much. Several avenues of player sabotage available, but then the whole game is full of these in other areas too...


Experimental issues.

I haven't looked into the code too deeply or played with it much but.

Fabs located with city boundaries are automatically  supplied with power if the city is? I would think it best to require an explicit connection with a transformer. If the issue is building a powerline through a congested city to the fab site, getting the powerline tunnel patch completed along with underground transformers would be a good solution.

Nerodens idea of having city supply and fab supply transformers is good. This prevents a city boundary enlargement that encompasses a new transformer from changing the players powernet design.

I think a one transformer per player per city limit should also be enforced. Again limiting the calculations.

What is this 7.5 consumption reduction factor? Right now 1 unit of power can generate 1 extra unit of fab production. Is this now 1:7.5?

I see code added to the senkes to share the load. IMHO this is not the correct place to control the power flow. See #2 above... might help some until #2 or similar can be implemented.

If multiple transformers are to be allowed, #1 must be fixed before release. Loading a game and being met with different results that when you left it not acceptable...

[jamespetts]

Turfit - thank you for your thoughts. I didn't have the time to redesign the power system from the ground up (the work that I did took an entire week-end ad it is), however, what I have done seems to work well enough. I have not noticed any inconsistencies in loading/saving.

As to multiplayer - it will work well if there is a persistent server and people are able to dip in and out of a slow paced, long running game at will, the game being paused when nobody is logged in.

[skreyola]

This is probably a silly idea, but could someone comment on its ramifications?
Can a factory check the unused power on the networks it can access for power and request power from each based on either the amount in MW available or the proportion of available power on each?
Example:
Lumber Mill is connected to power grids A and B. Grid A has 5MW available for immediate use. Grid B has 10MW available for immediate use. Mill needs (for simplicity) 6MW.
Can the Mill request 2MW from A and 4MW from B?
Can the Mill request 5MW from A and 1MW from B?

Could different modes be made available to the player in the factory info window ("Select power mode: * Proportional * Smallest first * Single supply (if adequate)")

I think that whatever balancing is used, this has the potential to become a strategic decision for the player.

[neroden]

Issue 2

This isn't saved with saved games - this is in factory_reader_t, which reads the "besch" (base types) of the industries from the .pak files. The rdwr files load and save things with saved games. This will not, therefore, be reduced by a factor of 7.5 on every load/save cycle. The reason that this is put in is to calibrate the electricity consumption accurately - even at 17% it is far too high, and 17% / 7.5 starts to get to numbers too small accurately to be represented by integer percentages.

This is a painfully ugly way to do this.  How are we supposed to explain to pak writers that the electricity consumption of their factory is electricity_percentage "divided by 7.5"?  That's just stupid.  Make the number per something else -- per thousand, per million, whatever.  Is any pak actually specifying electricity_percentage yet?  If not, then there should be no harm changing it.  If so, then it's pak128.Britain-experimental, and we should be able to just fix that pak.

(EDIT: In other words, if you really want this number, change the place where the default .17 is set, and change the pak.)


Also, .17/7.5 means that adding approximately .0227 * base_production units of electricity (the unit being 1 MW / 2^12) will double production.  (If that's not what it's doing, there's a bug.)  So for a factory with a base production of 1000 units, it will need .005 Megawatts (EDIT: five kilowatts) to double production.  Seriously?  This cannot *possibly* be right.  Are you sure you intend for such tiny electric demands?

Issue 3

I haven't noticed any instability associated with this, despite somewhat extensive testing: see the saved game file that I posted previously. This cannot use last month's demand because that is already set to the shared proportion:

Code Select Expand


last_power_demand = shared_power_demand;


If "last_power_demand" was used, therefore, it would keep reducing the proportion over and over again at each step.

Rewrite the code.

Issue 4

In what way does this not work properly when a substation is connected directly to a factory not in a city and is also connected to a city?

Priority supply is broken.  The computations aren't even right.

Perhaps by far the simplest solution would be to prevent substations in cities supplying factories directly, as it is a very marginal case when a substation in a city can be next to a factory that is marginally outside the city boundaries and thus not supplied by the city's electricity supply itself. That would then obviate the need to have two entirely different sorts of substations, and thereby  make things much easier generally. This would also not require resetting all the work that I have done already in relation to multiple substations in a city.

It's tolerable, but it's a worse solution from a gameplay perspective.  Suppose you as a player *really* want to make sure a particular factory gets fully supplied with electricity.  If you implement things according to your suggestion, there is no way to do this other than to supply the entire city, which could involve adding extra power plants etc. for a big city.  It's desirable to be able to give a factory its own supply even if it is within a city.  Worse, this means that as cities expand to engulf factories, your transformer supplying a particular factory will suddenly turn into a city transformer, forcing you to connect additional power plants.  Worse yet, until city mergers or something similar is implemented, certain cities *cannot* be supplied with power -- I believe the code for choosing which city a factory is in is the same as the code for choosing which city a substation is in, so this causes no immediate disasters, but if the choices ever diverge, factories could end up unsuppliable.

You should be able to reuse most of your code (to the extent that it works) and it should actually become a lot simpler if we create two types of substations instead of one.  The divergence from standard would also be more contained.

Issue 5

I'm not sure where the inconsistent use of "load_proportion" is: where ought it be used that it is not used? What is the effect of this?

I'm sure this is wrong:

   city->add_power_demand((municipal_power_demand>>POWER_TO_MW) * (load_proportion * load_proportion));

There can be no possible excuse for multiplying demand by the square of load_proportion.

The two-pass method for handling multiple substations simply doesn't work, also.  Though you may have addressed this now (with your note below).

Edit: I have found some issues in situations where more than one substation serves a city, one of which is connected to a network whose capacity (taking into account other demands) is less than that substation's equal share of power input for that city: that is now fixed in the latest push.

On another topic, I think TurfIt's ideas are all excellent.

[TurfIt]

This is probably a silly idea, but could someone comment on its ramifications?
Can a factory check the unused power on the networks it can access for power and request power from each based on either the amount in MW available or the proportion of available power on each?

Sure it can. I believe this is basically what jamespetts has done with his sharing code. The problem is the factory can only know the situation right now; Its decision on where to pull the power from might negatively affect other factories.

Example: Lumber Mill is connected to power grids A and B. Grid A has 5MW available for immediate use. Grid B has 10MW available for immediate use. Mill needs (for simplicity) 6MW.
Can the Mill request 2MW from A and 4MW from B?
Can the Mill request 5MW from A and 1MW from B?

Let's extend the example by adding a Mine with 4MW demand connected to grid A. The Mill gets processed first.
1) Mill - 5 from A, 1 from B.   Mine - 0. Not very good, we have 15 MW total supply, only 10 MW total demand, yet are only fulfilling 6MW.
2) Mill - 2 from A, 4 from B.  Mine - 3 from A. Better, but still only supplying 9 MW of our 10 MW total demand.
What's needed is
3) Mill - 1 from A, 5 from B. Mine - 4 from A. Now the entire demand is being fulfilled. But how is the Mill supposed to know it can only take 1MW from A? This is where a higher level coordinating authority is required.

Could different modes be made available to the player in the factory info window ("Select power mode: * Proportional * Smallest first * Single supply (if adequate)")
I think that whatever balancing is used, this has the potential to become a strategic decision for the player.

Again, sure it could. As a player do you really want to have to fart around with details like this? I don't think I would... not fun.
In the multiplayer case, who gets to set the mode? In your original example if grid A and B are owned by different players, surely player A would choose the mode so A:5, B:1, while player B would prefer the A:2, B:4 case. Who arbitrates this conflict?

Turfit - thank you for your thoughts. I didn't have the time to redesign the power system from the ground up (the work that I did took an entire week-end ad it is), however, what I have done
seems to work well enough. I have not noticed any inconsistencies in loading/saving.

Timewise - that I can relate to... I think with all the work going into multiplayer, it's probably worth looking into extending my original patch to handle it better. No promises for any timeline though.
I'll try to compile an experimental build from your devel branch and throw it some corner test cases.

[jamespetts]

Nathaneal,

thank you for your thoughts. Before I respond in detail, can you let me know whether there are any remaining anomalies in practice with my latest revised code?

Turfit,

I shall look forward to the test results :-)

[skreyola]

Let's extend the example by adding a Mine with 4MW demand connected to grid A. The Mill gets processed first.
1) Mill - 5 from A, 1 from B.   Mine - 0. Not very good, we have 15 MW total supply, only 10 MW total demand, yet are only fulfilling 6MW.
2) Mill - 2 from A, 4 from B.  Mine - 3 from A. Better, but still only supplying 9 MW of our 10 MW total demand.
What's needed is
3) Mill - 1 from A, 5 from B. Mine - 4 from A. Now the entire demand is being fulfilled. But how is the Mill supposed to know it can only take 1MW from A? This is where a higher level coordinating authority is required.

Perhaps power should be processed beginning at the plant and radiating outward along the grid?
Again, it may be desirable to make this a strategic decision for the player. I mean, it usually (i.e., unless there are other buildings in the way) won't be very expensive to just link the two grids (they're close enough to power the same factory).

Another option would be to let each factory read a variable telling how many factories/cities are connected to that particular grid, letting them make smart decisions, e.g., oh, hey! I'm the only one attached to Grid B. I'll take all of its power for myself and then tap A if needed.

Again, sure it could. As a player do you really want to have to fart around with details like this? I don't think I would... not fun.
In the multiplayer case, who gets to set the mode? In your original example if grid A and B are owned by different players, surely player A would choose the mode so A:5, B:1, while player B would prefer the A:2, B:4 case. Who arbitrates this conflict?

Different rules would probably be needed for multiplayer (attempt to get 100/n% from each attached substation), or whoever placed the first active transformer would get to choose?
The player wouldn't have to mess with it. Those who didn't want to would just treat it like a fixed paradigm.

Anyway, I said it was probably a silly idea. But there it is, for what it's worth.

[neroden]

Nathaneal,

thank you for your thoughts. Before I respond in detail, can you let me know whether there are any remaining anomalies in practice with my latest revised code?

I could try to set up a test game -- it's actually much more work than it looks to make a good test game, when you don't have a solar plant in your pak.   And there are so many logic bugs which are easier to find by going through the code....

The code works if there's only one substation per city.  (EDIT: And you're handling the problem of using last month's demand by using get_power_load(), which works, so that's good.)

EDIT: I'm not going to point to any other problems with it at this time, apart from the fact that it fails to take demand for a connected factory if it's also connected to a city and there are multiple city substations.  I'm going to simply try to figure out how to separate city substations from factory substations.

OK, I lied.  One problem:

Code Select Expand


                               const uint32 current_factory_demand = city_factories[i]->get_power_demand() * load_proportion;
                               const uint32 current_factory_load = (
                                               current_factory_demand
                                               * (municipal_power_load << 5)
                                               / municipal_power_demand
                                       ) >> 5; // <<5 for same reasons as above, FIXME
                               city_factories[i]->add_power( current_factory_load );

Municipal_power_demand is from *before* the allocation of power to other substations within the same city.  Current_factory_Demand is from *after*.  Municipal_power_load is from *after*.  I would expect every factory to be underclaiming power.

There are really too many problems like this.  I'm very sorry but your multiple-substation code is a bust.  It needs to be completely rewritten.

[jamespetts]

Nathaneal,

as to the test games - there's a reason that I uploaded the gas power stations' .dat file to the Pak128.Britain board recently

I have tested the case in which there are multiple substations per city, both connected to the same network and connected to a different network, and both amply supplied and supply restricted, and I cannot find any issues. That the substation can only be connected to either a city or a factory is not a real issue in view of the fact that factories can receive their electricity supply from the cities.

As to factories underclaiming power - can you elaborate on this? Do you mean that electricity is distributed to cities in preference to factories, or that there is some electricity unaccounted for somewhere: numbers that do not add up to 100%? If it's the former, then that is not a real issue, since, in real life, where there are power shortages, homes and offices are given a higher priority than industries.

But why does that one issue mean that the code needs to be rewritten entirely? Given the immense amount of time that it would require (several weeks of doing little else in my free time), it'd have to cause quite serious problems in practice to justify me rewriting it. It's not clear to me from the information that I have so far that there are any such practical issues.

[TurfIt]

James,

I'm afraid Nathaneal is correct - substations within cities is completely busted.

I supplied a town of 3000 with a demand of 25MW from one well stocked coal plant/one powernet.
Build 1 substation, 25MW loaded. Build a second and load splits 11, 13. Delete the second and the first stays at 11.
Build a 3rd and get 11,14. Delete the first - third stays at 14. And so on... The routine is obviously not recalculating for deletions.

Another case had 3 stations supplying 7, 7, 9. Built a forth station within city limits not connected to any grid, all 4 stations dropped to 0 power.

Also, building a station within city limits adjacent to a factory can only happen once. If you delete it and try to rebuild, it complains of only one station per factory.

25MW is rather excessive consumption for a town of 3000! Especially when most factories are only demanding 1-2 MW. My coal mine with a production of 286 demanded only 1 MW. Once supplied the production only went up to 536 - less than the normal 2x. The mine was well outside of any city. No point in trying any cases of factories with city with the above problems...

Something has also broke with powerline bridges between 7.3 and devel. Build a powerline bridge across a single square of ocean and the two powernets graphically join but retain their original IDs and hence remain functionally separate.

I've also found that if a player tries to build a powerline beside a public service power line, they merge. Two players can build side by side and remain separate. This also happens with Standard...

EDIT: The test game was left running while I composed this message. Imagine my surprise when I tabbed back to the game and found the 4 station case with one disconnected showing load of 8,8,8,0. Deleting stations is also now recalculating properly. Weird. I still stand by 'busted' though...

[jamespetts]

Turfit,

thank you for your testing. Do you have a saved game that I can look at?

[jamespetts]

The issues relating to the power network stabilisation patch integration with Simutrans-Experimental seem to be quite complicated and potentially require considerable re-engineering in the future. However, I am both short of time and keen to release Simutrans-Experimental 8.0 before I go away for just under a week on Tuesday, so the issues relating to the connexion of multiple substations to a city will, I am afraid, have to wait for a subsequent sub-version of Simutrans-Experimental to be fixed, especially since they are, in the grand scheme of things, comparatively minor issues.

I have, however, reverted the division by 7.5 of the industry power consumption quantities, and have adjusted the .dat files of industries for the next release of Pak128.Britain-Ex to modify their individual electricity consumption figures.

Thank you both for your great assistance in integrating the patch and finding issues - it has been most helpful.

[neroden]

As to factories underclaiming power - can you elaborate on this? Do you mean that electricity is distributed to cities in preference to factories, or that there is some electricity unaccounted for somewhere: numbers that do not add up to 100%?

The latter.

[neroden]

The issues relating to the power network stabilisation patch integration with Simutrans-Experimental seem to be quite complicated and potentially require considerable re-engineering in the future.

Yeah.  :-(

However, I am both short of time and keen to release Simutrans-Experimental 8.0 before I go away for just under a week on Tuesday, so the issues relating to the connexion of multiple substations to a city will, I am afraid, have to wait for a subsequent sub-version of Simutrans-Experimental to be fixed, especially since they are, in the grand scheme of things, comparatively minor issues.

The problem is that they completely break electricity supply to factories within cities.

Perhaps a good short-term fix would be to force any substation adjacent to a factory to be a "factory-only" substation.  Then players could (for now) ignore "city supply" completely and have a playable game.  I think I could code that up pretty quickly. 

I have, however, reverted the division by 7.5 of the industry power consumption quantities, and have adjusted the .dat files of industries for the next release of Pak128.Britain-Ex to modify their individual electricity consumption figures.

Excellent. This should give nice results!

[jamespetts]

Nathanael,

welcome back and thank you for your responses :-) Factories in cities get their electricity from the city itself - how is the supply to them broken? They can be supplied by supplying the city.

[neroden]

Nathanael,

welcome back and thank you for your responses :-) Factories in cities get their electricity from the city itself - how is the supply to them broken? They can be supplied by supplying the city.

City supply is unreliable -- and computed wrong --  if multiple substations are present, for the reasons described previously.

[jamespetts]

The only problems as I understand it with city supply are: (1) sometimes too much power is drawn from the network compared to how much is supplied to the city; and (2) substations will not always give equal load as they should. These problems are present only when there are multiple transformers in a city. There is thus no need to make substantial changes to the basic paradigm of industries in a city being supplied by that city. If the bugs as currently exist are really a serious problem in ordinary play, the best solution is simply to permit only one substation per city until they are eliminated. However, the view that I take at present is that the restriction of having only one substation per city would be worse than the bugs as they currently stand, desirable though it is to try to fix them one day.

[deMangler]

Sorry if I posted this in the wrong thread - it seemed like it belonged here.

I built a new coal fired power station using the in-game editor to replace one that closed down at a bad moment.....
I reconnnected it to the already existing grid that is connected to two cities and a colliery and a grain farm.

Now all of a sudden I am getting loads of powerlines revenue, as you can see in the graph below.





Here is a save from before

Here is a save from after

I don't know if it is an issue related to the contents of this thread, but I thought I should let you know.

It is Simutrans 102.3 Experimental 8.2. Release date: 27th of June 2010.
Pak128.Britain-Ex downloaded from http://experimental.[ simutrans [dot] us (site down, do not visit) ]/Pak128.Britain-Ex.zip on 29/06/2010 (I can find no version number)

dM

[jamespetts]

Have you used fast forward? There is a known bug with power line revenue when using fast forward.

[deMangler]

Have you used fast forward? There is a known bug with power line revenue when using fast forward.

Yes, I was using fast-forward both before and after the power station replacement. However the graph shows that there was no abnormal power revenue before the replacement so I thought it may be connected.

dM

<edit>
I should mention that I started a new game, in which I had a power station supplying 2 cities and a colliery. It was ok for a while then I noticed that my powerline revenue had dropped to zero even though there was demand and connected available supply.  Looking into it the only thing I could see that might have effected it was that the city had expanded to include the colliery and it's substation.
I destroyed all the substations and rebuilt a substation in each town, this solved the problem for one town but not the one with the colliery included - I then tried re-adding a substation to the colliery but that made no difference.
I can supply screenshots and before/after saves if required.
I did not use fast-forward in this game.
Hope this information is helpful.
dM
<edit>

[TurfIt]

Have you used fast forward? There is a known bug with power line revenue when using fast forward.

Actually, you don't need to use fast forward to end up with completely wrong powerline revenue. Anything that disturbs the simloops from 5.0 will do...
The patch to fix is sitting in the standard Considered Patches section; Same fix should be suitable for Experimental.