Resources abstraction

[zwzsg]

As this is true for everything, you should write the whole engine in Lua and use that.

Hey, that's my line! I just stopped using it for a while because some higher dev expressed its annoyance at my repetition of it.

Anyway, since many mods have already switched to not using engine coded resources, they can't get broken by whatever abstraction engine coded resource are changed into. I now realise my objections have no point.

[AF]

It may be of note to those who didnt see the blindingly obvious but in lua unitdefinitions you can rename tags to whatever you want and use whatever structure you like, all you need todo is make a few assignments at the very end of the file so that its all linked up.

Since this happens normally when an API is changed and si offered as a temporary fix for those who cba changing their code, I fail to see why you cant apply the obvious to lua unit definitions.


As for resources. I would support this suggestion wholeheartedly, BUT, energy and metal should not become defactor alias. If a mod does not have an energy resource then the engine should not track one. This si only going to serve as a piece of cruft, a quirk, a special case, and they are never good when a generic alternative exists.

[zwzsg]

BUT, energy and metal should not become defactor alias.

And break every mod that does not immediatly comply with the new scheme in the process?

[AF]

BUT, energy and metal should not become defactor alias.

And break every mod that does not immediatly comply with the new scheme in the process?

TDF files are already parsed via lua, theres no reason the lua that comes with the spring engine cant account for this.

[zwzsg]

Ah, ok, so the engine would be untainted by the "metal" and "energy" name, but default base archive would contain all the lua to keep compatibility with unmaintened mods. Sounds good.

[AF]

I would argue that the likes of metalmaker logic and things like solars only powering things when turned on and open and stuff should be ported into a lua gadget. The engine should not handle the economics of energy and metal resources unless its willing to handle them all.

So metal extraction and the metal map should be decoupled and the link between the two implemented in a gadget.

A clear and neat distinction should be made if we're ever to get a clean and generic system that gives us maximum benefit. This should also allow those mods usign energy and metal to manipulate the way their current game emchanic works without having to re-implement the energy and metal resource, and some hacks such as tieing thigns into the existing framework could be done simple clean and fast, rather than requiring more hackish kludges.

Flexibility ftw Special case logic ftl

[imbaczek]

the proposed system looks pretty generic to me.

btw while we're at it, you can add tags for upfront unit, like in starcraft. this way we can have TA payment, SC payment or mixed easily.

[AF]

Such tags and engine code would be unnecessary fi the logic in question was all in lua land

[Argh]

btw while we're at it, you can add tags for upfront unit, like in starcraft. this way we can have TA payment, SC payment or mixed easily.

I implemented SC payment at one point. It causes serious logic problems with Repeat Build.

You can re-queue or cancel the building, etc. but then it causes other major logic problems.

If we're going to put that into the engine, Repeat should probably be disabled by default on factories if using that style of resource management.

[AF]

Argh that would not be an issue if my suggestions were carried out.

The way resources are actually used generated and manipulated are dependant on game mechanics and as such do nto belong in the engine because anything which deviates fromt eh default implementation of energy and metal has to do hacks and fail safes, which is a horrible way of doing it when we should support a flexible system from the start.

[Argh]

Argh that would not be an issue if my suggestions were carried out.

Er... do I really have to explain why there are logic problems with SC + Repeat? Again? You were around when I performed that experiment... I should have released a mini-mod to demonstrate

The very short version is that there are no good ways to determine whether an expense is valid.

Think it through- you're near-empty on resources, have a constant income, and have three factories on Repeat. One is building very expensive tanks you need as soon as possible, two are building not-expensive soldiers that are, from a play perspective, a secondary priority.

Which will invariably be built, in that situation? How can any piece of software possibly make the right choice, without foreknowledge of player priorities?

That is why there is no Repeat Build in most RTS games.

You pay up front, to add things to a queue, and that's it. We can have one system or the other, but there isn't any way to reconcile these things. I even tried a weighted-priority system, and it still caused major problems, because no matter how you weight it, you run into the same issues. I did not build a "maximum priority" control, which is another approach, but frankly that just adds yet-another level of UI mess.

Anyhow... personally, I think that SC-style systems are easy to implement in Lua, and don't really need engine-side stuff.

[AF]

As I said, those problems are in the code that handles energy and metal consumption and production.

Under my proposal, this would be moved out into lua and the only responsibility of the engine is to track in and out as dictated by the resource management logic in the lua.

So your longstanding problem you refer to would finally be 'fixable' because the code that is the culprit would be within your grasp as a gadget.

[Argh]

As I said, those problems are in the code that handles energy and metal consumption and production.

No, they're just basic logic problems.

The code that handles production is fine- you produce stuff, it gets stored. I'd like off-board storage, instead of the OTA model where it's tied to Units, but that's a minor wrinkle and again it's easily done with Lua.

Again, AF: if you have three things enter Repeat queues, and costs:

100, 30, 30. You have 75 resources, and an income of 20. Which gets built? If those three things repeat forever, does the item costing 100 ever get built?

You can queue them, so that it's in order of request.

But then you desperately need to build something that costs 50, but the item that costs 100 is in queue. Do you have to shut down that Factory? How does the program determine what's a priority, when they're all just Commands?

Are you starting to see why there are major issues there? No matter how you slice it, it causes huge problems for players and coders.

[aegis]

how will this account for metal maps and such? will each resource be able to have differently-colored areas on the map?

[Argh]

That's an excellent question.

Better yet- is Lua going to have direct access to the metalmap and the color value? Can it be manipulated by Lua (finally)?

[AF]

Argh, your not listening to me.

Your problem here is to do with code that is currently in the engine. I am saying move it out of the engine into lua gadgets, this would allow lots of things including removing your problem entirely by putting the relevant code within your grasp.

Under my proposal these things that are broken would be fixable by you using lua, because they're implemented in lua, and you can meddle in how they work. How construction consumes resources would not be implemented by the engine but by lua gadgets. All the engine would do is track the amount stored and total storage, increasing and decreasing that value as the lua gadgets say so.

[zwzsg]

You're not listening to him either. Whether it's engine side or mod-lua side doesn't change that there is a basic logic problem with SC payment + Repeat.

[Argh]

You're not listening to him either. Whether it's engine side or mod-lua side doesn't change that there is a basic logic problem with SC payment + Repeat.

Exactly.

The problem is just simple game logic- the reason why most games don't have Repeat Build is that it simply isn't compatible with a wait-and-save economic model.

I've juggled various ideas for how to combine the two, but I haven't been able to think of any logic that would solve all of the problems.