Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
All of my power storage mods are stuck at 0MW unless I manually adjust the power budget, even with the 10% buffer.
12k population runs at 60fps locked, normally.
With this mod 24fps...
This is ridiculous.
I haven't actually tried this version of the mod (just the original, which is now somewhat broken) so it's possible that it doesn't work anyway, but it *definitely* doesn't work with separate power grids.
it is such a nice mod to have....
(Filename: Line: -1)
IndexOutOfRangeException: Array index is out of range.
at Autobudget.Mod.UpdateUI () [0x00000] in <filename unknown>:0
at Autobudget.SerializableDataExtension.OnLoadData () [0x00000] in <filename unknown>:0
at SerializableDataWrapper.OnLoadData () [0x00000] in <filename unknown>:0
Rethrow as ModException: The Mod C:\Program Files (x86)\Steam\steamapps\workshop\content\255710\2803558200 [AutoBudget.dll] has caused an error
Here's the output log
https://ufile.io/8yvrnr0y
"Total Autobudget - FIX - nice fix, I might use it, if it does no eats FPS"
That found at this link: https://steamhost.cn/steamcommunity_com/workshop/filedetails/discussion/2744969330/4731597990011153998/
continued below in sequential order...
which is associated with this thread of mod management he created:
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=2595470859
in case you want to see for yourself... Okay anyway, I thought I'd address that statement and provide a couple of suggestions that might help reduce FPS impact in return for a slightly less optimized budget management.
So, before I say anything, I want to at least say that I've skimmed some of your Github code to get a general feel for what it's doing. I'm not going to claim to know what's going on entirely, but as mentioned, skimmed.
Regarding the heat on/off aspect, the game will cause a bunch of those heat-icon pop-ups above the houses. Give the player an option to auto-suppress those on buildings that the mod is able to affect. Any buildings outside of the range that the heat source can reach, leave as is. This might help a small amount due to the graphical changes having to occur for each and every building. Arguably,
the same thing could be said for the other features, but the heat on is the primary one that should be noticed. Alternatively, you could offer an option for a static frequency of updating the display with said icons... perhaps using system time rather than game time due to mods such as Real Time.
Second, and somewhat related, the probably less taxing feature of "freezeUI = false" could have the option to update less frequently displaying a weighted average instead of current value. The periodic updating display of weighted ratios could be meaningful to the player. For argument sake, let's say a player has been noticing garbage symbols remaining longer than he/she would have liked and thus goes to adjust the budget parameters. A simple or exponential moving average that lags updates will be approximately accurate, contain less noise than constant updating with current values, and let the player judge from a larger sample of data than the current value what to change things from.
The reduction to updating might help improve FPS performance minimally, but the other aspect of what I described might still be a desirable feature.
Third, let the player have an option to scale off the amount of api calls the budget manager performs in correlation to player wealth, income, and city development stages, etc. Obviously, as a player becomes more wealthy and grows net income, giving consideration for variance due to imports/exports, and has progressed the city further to a more stable state, perfect budget management matters less than before. As such, just like before, a scalable lambda value could be offered to the player to set. This lambda value could represent the maximum value to scale off the autobudgetting updates to.
So, for example, say a player has just started and would want this at 100% frequency of updates. Well, the algorithm you create to scale and account for net cash wealth, net income, net cash flows, city size achievements, and city population would at this point be implemented at 100% of frequency of updates regardless of the scale factor input. Basically, lambda would be a decay factor that approaches the set lambda by the player. In the decay process, the calculated lambda value would periodically perform another set of api calls and recalculate the parameter values to rebalance lambda for present conditions. As you can see, this would enable you to scale off the frequency of api calls without completely removing the functionality of the mod as the player theoretically needs it less. If set at 100%, then the mod always works at full performance, and if set at 0%, but still ticked on as a feature to use, then the player simply wants to scale it down to manual management.
Now the algorithm... well, I'd suggest using a bunch of ratios rather than raw api called values. E.g. Wealth / (population + population * exp(EWMA of population rate changes over time)) * weight of relative importance to the algorithm + .... the other ratios however you like to create it. In the portion I was trying to demo above, basically you're taking the PV of Wealth and scaling it against the population plus PV exponentially weighted rate changes to create a moving average factor that serves as an instantaneous rate value. Anyway, the algorithm can be whatever, just providing a starting idea as too what it might look like.
Finally, and this is probably a less reasonable thing to introduce than the other three, and I'm not sure if the game will allow it or not, but you could have the "idle" service vehicles statically patrolling the city keeping approximate equal distance from each other (each other being only other static service vehicles of the same type).
I don't know how it works, but if the game treats the home facility as being static, you could trick the api with dummy values so it thinks those vehicles are within the building and idle to keep costs down. However, upon moments notice that one is actually needed, then it's "deployed" in which you update the game with the coords of the service vehicle(s) nearest to the issue. I left it as vehicle(s) as in some cases, multiple service vehicles may be needed. Anyway, now the game thinks it's been deployed to the new coords and starts charging for it, but time is saved because the vehicles were already deployed and spread out. Thus reducing the time the vehicle is active per se.
I'm interested in hearing your thoughts on any of this. I've never developed a cities skylines mod so I may be naive to what's actually possible with the ColossalFramework package (I didn't read up on the package documentation either to be fair).
However, it doesn't seem to work with the Waste Processing Complex. Keep getting brownouts. Everything is on a single grid with a 5% margin.
Auto-budget is most important early in the game when money is tight, so it's not all that important, but thought I see if others have the same problem.