Adding support on engine to handle up to 255 resource types

[tizbac]

I'm working on support for more types of resources other than metal and energy.
At the moment i've got it working with more reosurces specified in gamedata/modrules.lua.
I've done it so each unit has a parameter called "productionSource" which specifies from what make resources ( Metal map , Tidal, Wind , Just From resources used , Custom resource maps( still to be implemented )).
There are parameters to specify resource production unrelated to productionsource and resource production related to it and to specify unit resource usage.
Each of these parameters is for each resource.
The current code is at http://github.com/tizbac/spring/tree/abstrRes .
If someone wants to help finishing it and make it not breaking current mods contact me on lobby.

[hoijui]

As the branch name suggests, tizbac is abstracting resources in the whole engine code (and also in the related parts, like eg. Lua interface).
Just saying it also this way cause it sounds more interesting for engine devs (for at least to me).

[tizbac]

it doesn't seem to be interesting...

i'll finish it myself anyway when i've time to do it.

[Satirik]

if you do it well and finish it will just be awesome !!

[Neddie]

So, when this is complete, people like smoth could move their additional resources into the engine and avoid luarules crash cascades at times? This is pretty cool, how much more work ahead?

[AF]

I would advise against such a 'move' until the nondeterministic resources problem is dead and buried.

[hoijui]

even doh i do not know what problem that is, i can not see how this change would make it worse. This change actually simplifies stuff. As algorithms, for example, do not have to be in the code two times anymore, and thus potentially reduces errors:

Code: Select all

newMetal = oldMetal + metalIncome - metalSpent;
newEnergy = oldEnergy + energyIncome + energySpent;
// ... compared to:
newRes[r] = oldRes[r]  + resIncome[r]  - resSpent[r];

i can not see anything negative in this change, except that someone has to do it.

[AF]

The issue is with ordering.

Fixed costs, such as an AK taking 20 energy to simply exist, should always come first.

However if the AK was built after 100 builders all building away, then those 100 builders may get a chance to dip into the energy pool and grab what resources they need. This pool may then run out, but the fixed cost needs to be paid. As a result, it is ignored, and the user gains 20 energy for free.

Because of this, weapons can fire when energy stalling simply because of their luck in being closer to the start of the loop.

This makes spring economics non-deterministic, because some units get given free resources as a gift thanks to this oversight.

Rather than managing all of a units expenditures and incomes on a unit by unit basis, the engine needs to manage each individual expenditure type for all the units it applies to at once, so that we can s

[hoijui]

ahh that one, read about it in an other thread. if this change makes any difference for this bug, then it would be a positive one, as described in my last post.

[KaiserJ]

gogogo! now it's time for a mod that requires 255 resources combined with 256 players, it should make for some very interesting arrangements of ally resource bar widgets.

in seriousness though this is very cool; good job sir

[CarRepairer]

gogogo! now it's time for a mod that requires 255 resources combined with 256 players, it should make for some very interesting arrangements of ally resource bar widgets.

I lolled.

[Licho]

Problem with spring resources isn't that there are too few, its the lack control over them (when how what is added/removed, how is excess handled etc..)

Ideally all engine based resources should be replaced with proper customizable interface for lua, so that mods can implement whatever they want.

[hoijui]

with this change, giving lua more control over resources will be easier, and letting lua have control over how the engine handles resources will be easier too. for example, things like this could be implemented:
The mod removes resource "metal".
The mod removes resource "energy".
The mod defines a new resource "gold".
The mod defines the "metal-map" supplied by the map to be used for gold.
The mod defines a new resource "sulfur".
The mod generates a "sulfur-map", and supplies it to the engine.
The engine can handle all resource management it supports for all resources of the mod, and the mod only has to handle special stuff through Lua.
Skirmish AIs can access all resources and all resource maps, if there are any, without having to communicate directly to the mod (which would require custom code on the mod and AI side).
Maps could supply additional resource maps (some when in the future).

[Licho]

Well in CA we have to do lots of things manually .. for example

- we have extra gadget for energy spending structures to shut them down during stall
- we have to hack wind generators to allow for height dependent wind
- we have to hack all workers to allow building speed/spending throttling
- we have to hack all metal extractors using invisible gaia units (to allow overdrive, communism and still have metal map visible)
- we have to hack all map features and replace map trees with our
- we have complex code in place to manually take over automatic excess sharing (we need to distribute it manually and use excess for overdrive)

More resources wont help here, atm. all engine does for us, is that it sums numbers together and gets into way :)

[hoijui]

yeah, of course it wont help mods like CA a lot, as it uses the default two resources. though, if it gets into your way, as you say, then you can remove all engine resources and handle them completely by yourself (in theory, maybe).
i can see this having some benefit for practically all non-TA mods, if for nothing else, at least for AI support.

[AF]

As I see it, rather than units directly dipping into the resource pool and adding to it in SlowUpdate, causing the bugs with resource access and nondeterminism, e.g. unit A might not have energy to fire, but the next unit processed adds 1000 energy to the pool.

What we should do instead, is having a unit request energy and other resources, with a priority, and then have an object/class that will at the end go through them all one by one in a priority queue, with additions prioritized, and then make a call to the unit saying xyz request was granted, so that further processing can be done, or more requests made for the next game frame, e.g. we needed this 500 energy, and we got it, now we're going to add 20 metal to the metal resource next frame.

This way resources become deterministic, and we have a means of hooking in lua for custom requests and sues for resources, both in the manager for giving the go ahead or not (e.g. a gadget using this to restrict resources based on distance), or in the unit class (requesting 100 energy for our unit morph or LOS machine )

[hoijui]

stop talking about your favorite bug in this thread, it is off-topic.

[AF]

This thread is about a refactor to the resource system for allowing upto 255 resources.

My post was about a change to how resources are handled, which would help solve the problem licho put forward, as well as fix the bug I mentioned, and many others. You are currently working directly on fundamental changes to how resources are handled in order to accomplish your goal.

Therefore I posit that your post accusing it of being offtopic was not correct at all, and my suggestion is entirely relevant.

[SirMaverick]

This thread is about a refactor to the resource system for allowing upto 255 resources.

My post was about a change to how resources are handled

Reading first post this is where you are going off-topic.

[tizbac]

atm most of it it's done , what is missing is just nonlua ui fixes and support for old TA mods