Currently I am attempting to improve the power system based on the current system and trying to address some flaws. It seems to be harder than I thought and it is messing up the master branch significantly. So I have moved my progress to a new branch which you can pull from my github.
Github power branch
The system will still be the same where all structures (either power producers, consumers and storage) within the same ownership area are connected, that is they form a network. Within this network all power is shared in one big pool and distributed among the consumers, according to priority. Moreover, which is new, the producers also have a priority such that for example a steam engine would not start delivering power when only a windmill is needed. I don't want to detail the full structure of the set-up here, since most of it can be found in the code of the libraries.
To ease the testing I have set up a testing scenario which consists of a set of unit tests of the power system. These tests run automatically and tell the user at the end whether all tests succeeded, this can be useful as a unit test for the release. Currently these unit tests are rather simple and I have summarized them below. It would be helpful if some suggestions would be made for different tests.
Case 1: A steady power source (wind generator) supplying an on-demand consumer (workshop).
Case 2: An on-demand power source (steam engine) supplying a few on-demand power consumers (sawmill, armory).
Case 3: An on-demand power source (steam engine) supplying a few steady power consumers (pumps).
Case 4: A steady power source (wind generator) supplying a steady power consumer (pump), while an on-demand consumer (elevator) is turned on and should be prioritized.
Case 5: A steady power source (wind generator) supplying a steady power consumer (pump), while an on-demand consumer (double elevator) is turned on and should be prioritized.
Case 6: A steady power source (wind generator) connected to a power storage (compensator) which are both needed to supply a steady consumer (workshop).
Case 7: An on-demand power source (steam engine) whose over-production gets stored by power storage (compensators) which should provide a steady consumer (workshop).
Case 8: An on-demand producer (steam engine) as back-up for a steady producer (wind generator) with for steady consumers (pumps).
Case 9: An on-demand producer (steam engine) always provides power to an reduced on-demand consumer (wind mill).
Case 10: Network 1 (steady producer (wind generator) supplying steady consumers (pumps) connected to network 2 where steady producers (pumps) supply an on-demand consumer (sawmill).
Case 11: Two connected networks by different allied players with the elimination of one of the two players.
Case 12: No power need rule and no power need script functionality tested for a simple network.
Case 13: Flagpole which connects two networks is removed and created again to test network merging.
Case 14: Massive amount of power structures to test the performance of the power system.
Case 15: A supported (wind generator) infinite pump loop, with two pumps pumping in opposite directions.
*Power system stopped working in a save game (#1158).
*Battery does not work in corner case (#1103).
*Wind mill should only provide power for itself (#979).
*Give scripter an interface to give no power need to a structure and fix the no-power-need rule.
*Energy symbol visible through fog (#1229).
* Remove all the if (!link) checks, they are not needed in principle but errors arise when they are removed.
* Fix overproduction if a request is not met, e.g. compensator trying to supply a workshop alone (partially fixed).
*Implement network separation on hostility changes.
* Check savegames and multiplayer save games and player removal.
More reports on issues with the current power system or unexpected behavior are appreciated!
Github power branch
The system will still be the same where all structures (either power producers, consumers and storage) within the same ownership area are connected, that is they form a network. Within this network all power is shared in one big pool and distributed among the consumers, according to priority. Moreover, which is new, the producers also have a priority such that for example a steam engine would not start delivering power when only a windmill is needed. I don't want to detail the full structure of the set-up here, since most of it can be found in the code of the libraries.
Test cases
To ease the testing I have set up a testing scenario which consists of a set of unit tests of the power system. These tests run automatically and tell the user at the end whether all tests succeeded, this can be useful as a unit test for the release. Currently these unit tests are rather simple and I have summarized them below. It would be helpful if some suggestions would be made for different tests.
Case 1: A steady power source (wind generator) supplying an on-demand consumer (workshop).
Case 2: An on-demand power source (steam engine) supplying a few on-demand power consumers (sawmill, armory).
Case 3: An on-demand power source (steam engine) supplying a few steady power consumers (pumps).
Case 4: A steady power source (wind generator) supplying a steady power consumer (pump), while an on-demand consumer (elevator) is turned on and should be prioritized.
Case 5: A steady power source (wind generator) supplying a steady power consumer (pump), while an on-demand consumer (double elevator) is turned on and should be prioritized.
Case 6: A steady power source (wind generator) connected to a power storage (compensator) which are both needed to supply a steady consumer (workshop).
Case 7: An on-demand power source (steam engine) whose over-production gets stored by power storage (compensators) which should provide a steady consumer (workshop).
Case 8: An on-demand producer (steam engine) as back-up for a steady producer (wind generator) with for steady consumers (pumps).
Case 9: An on-demand producer (steam engine) always provides power to an reduced on-demand consumer (wind mill).
Case 10: Network 1 (steady producer (wind generator) supplying steady consumers (pumps) connected to network 2 where steady producers (pumps) supply an on-demand consumer (sawmill).
Case 11: Two connected networks by different allied players with the elimination of one of the two players.
Case 12: No power need rule and no power need script functionality tested for a simple network.
Case 13: Flagpole which connects two networks is removed and created again to test network merging.
Case 14: Massive amount of power structures to test the performance of the power system.
Case 15: A supported (wind generator) infinite pump loop, with two pumps pumping in opposite directions.
List of Issues
*
*
*
*
*
* Remove all the if (!link) checks, they are not needed in principle but errors arise when they are removed.
* Fix overproduction if a request is not met, e.g. compensator trying to supply a workshop alone (partially fixed).
*
* Check savegames and multiplayer save games and player removal.
More reports on issues with the current power system or unexpected behavior are appreciated!
![[de]](/mwf/flags/de.png "Germany")
I'd still say a complete rewrite might be easier and/or yield cleaner results as the old power system was not created with the current requirements in mind. That could f.e. be the opportunity to split the power stuff from the ownership stuff>More reports on issues with the current power system, or unexpected behavior are appreciated!
The now removed
SetNoPowerNeed was needed so that a developer could set certain structures to not require power while editing a scenario in developer's mode.
> The now removed SetNoPowerNeed was needed so that a developer could set certain structures to not require power while editing a scenario in developer's mode.
I will restore that before merging.
>I'd still say a complete rewrite might be easier and/or yield cleaner results as the old power system was not created with the current requirements in mind. That could f.e. be the opportunity to split the power stuff from the ownership stuff
What do you have in mind when you say separating the two? I still feel that the power system should work with some form of connection between nodes. And ownership areas make a lot of sense for that in my opinion. I like the system where the player does not need to worry about some nifty details and just everything in an ownership area is covered.
On a script level I do want to fix some parts of the interface, for example the flagpole library directly accessing local variables in the power_library, but rather build an interface which allows the flags to merge two networks when to ownership areas are merged.
>What do you have in mind when you say separating the two?
That's a good question. I guess I am just still a fan of the proposition where power-nodes (with radii) are per-se neutral and the owner is decided by a connected flagpole, because I am still looking forward to making real base-melees possible and fun for the first time in the history of Clonk :)
I am just a bit scared that if we ever decide to try that, it would require a complete rewrite of everything again, because the parts would be too intertwined
Very cool!
Added a new test (Case 8 in first post) where a windmill supplies five pumps which pump water up, in a different network five other pumps pump down that same water to produce power for a sawmill.
I am still having trouble with the pumps and the power storage to correctly implement them within this framework, it will probably just require some time to see what these object scripts exactly do.
I am still having trouble with the pumps and the power storage to correctly implement them within this framework, it will probably just require some time to see what these object scripts exactly do.
Did you want to change how the power currently works? I mean, currently power is not "stored" at all. It's either there and can be used or it isn't there.Did you want to change that and implement real storing like in CR? If so, why?
No, with storage I meant structures like the compensator (the only one currently).
Mh, yeah. I guess that's one of the points where I'd rewrite parts of the (current) power system, too. I don't have all the adjustments you already made in my head, but I'd probably split up the consumers/producers into different priority queues, add sleeping queues for both and differentiate between actual producer (MakePowerProducer) and potential producer (OfferPowerProduction) where the latter would just add the producer to the sleeping queues. Whenever the balance is below 0, producers from the sleeping queue could be woken up (steam engine and compensator for example).
And since the queues would be priority queues, the power system could simply wake up as many producers as necessary until the required power is reached. And everything would be simple, clean and everwhere would be unicorns and rainbows.
Update!
I fixed all the buildings (especially the compensator now works as intended!). Now moving on to the savegame code and then it will be soon in master.
I fixed all the buildings (especially the compensator now works as intended!). Now moving on to the savegame code and then it will be soon in master.
Since it is now a clear improvement over the old system I have put all changes into our master branch. Please let me know if there is any unexpected behaviour or bugs.
I have ran into the following problem:
on a hostility change the some flagpoles need to change the network they make, that is for example power structures which were in the same network before are now not connected any more. However the only hostility change callbacks from the engine are made to scenario scripts, goals, rules and environment objects. So a flagpole including the flag library would not such a call unless it is a C4D_Environment category, which might not be optimal. Currently I only found an issue with scenario saving, but maybe there is more.
Anyone an idea?
on a hostility change the some flagpoles need to change the network they make, that is for example power structures which were in the same network before are now not connected any more. However the only hostility change callbacks from the engine are made to scenario scripts, goals, rules and environment objects. So a flagpole including the flag library would not such a call unless it is a C4D_Environment category, which might not be optimal. Currently I only found an issue with scenario saving, but maybe there is more.
Anyone an idea?
Since hostility changes don't happen that often, you can change the engine and add the callback to all objects I guess, then schedule a network update for the next frame if it wasn't scheduled yet (to avoid updating the network n times).If engine changes are not an option, you can always do a runtime hook:
if (!hostility_change_hooked)
{
this.Scenario_OnHostilityChanged = Scenario.OnHostilityChanged;
Scenario.OnHostilityChanged = this.OnHostilityChanged;
hostility_change_hooked = true;
}
func OnHostilityChanged(...)
{
// your code
// ...
// inherited
if (this.Scenario_OnHostilityChanged) return Scenario->Call(this.Scenario_OnHostilityChanged, ...);
return true;
}
Although I'm not really a fan of this. The engine change would probably be easier to understand and maintain.
I thought about it a bit and making flags C4D_Environment isn't that bad either: OnTeamSwitch is probably also needed to catch all possibilities.
But flags wouldn't be sufficient? Everything that has a power radius would need that callback.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
