Spring's "economy", GET/SET MAX_SPEED

[Argh]

double-post, ack...

[MadRat]

The spring economy doesn't work like a powergrid, it works with a stockpile of resources, this is by design and not a bug. If a unit cant drain its requested amount it won't do so and leave the resource pool untouched and the action will fail. This is true for units with energyuse too, which isn't a true upkeep but instead the unit is expected to have a sideeffect, like making metal which will be shut off in the case of low resources.

The problem is if the resources are not summarized before any expenses taken then you have some units getting resources out of their respective priority. Should it make sense that as an example one could start the loop with a geothermal plant adding in +250 E, then next in the loop is a builder draining 251 E unable to draw their full allotment of energy when its truly there from next energy maker in the loop? Later on in the loop a commander might cloak and drain the energy before it comes back around to the builder. Theoretically the builder should drain its full allotment before the cloak can even happen.

If the resources were divided up after adding up the sum of intake, then its more fair to all of the units. You can discard expenditures that will not have enough allotment - discard enough until the rest are all possible - and keep the resources in the pool, thereby making it possible to fire weapons and move units as a priority over luxuries such as building and cloaking. Maybe its not possible to use a psuedo-lisp system here to sort out costs by their rank. If it is possible then it makes alot more sense than the current system.

[AF]

err we already stated tha if theres 250 in the banka nd somethings fixed cost was 251 then ti would drain 250 and not turn on or have limited/decreased functioning

[PauloMorfeo]

Basically, I'm going to make it go like this, switching the priorities:

1. ...

As you've reached the conclusion, that is a whole new discussion and the priorities need to be discussed. You have been seeing the code, can you post what parts of resources using are separated (and thus could be re-prioritized)?

I didn't understood how you said that it would remain optional for moders.

There is one problem with the whole thing, some units we don't want to have higher priority (metal makers. They are there to give me resources to build stuff. What is the point if they're E use is keeping me from building), while others we want to have higher priority...

Could it be coded in a way that units would have a tag in units (ResSpendingPriority?) to define if they spend resources before or after (before or after the current or a new resSpending priority scheme)?

err we already stated tha if theres 250 in the banka nd somethings fixed cost was 251 then ti would drain 250 and not turn on or have limited/decreased functioning

I have to completely disagree with that.

[Felix the Cat]

That's like going to a fancy restaurant, when you can only afford fast food... ordering everything on the menu, including all of the fine wines... then saying to the waiter, "oops, I don't have any money"... and having the restaurant be OK with that It doesn't work that way IRL, and it shouldn't work that way in Spring, either.

The Internet is not a big truck, and likewise, Spring is not a restaurant.

The best parallel for Spring would be actual war situations.

I see it a little bit differently. If I am commanding an air force, and I have 500 barrels of oil a day coming in, and I have an AWACS plane that costs me 600 barrels of oil a day simply to run, I'm not going to put my entire oil income to that, because I still wouldn't be able to run it. I might as well be burning the oil and having a ceremonial dance around it every night - the value added to the war effort is about the same. Instead, I'm going to allocate the oil to things that I can actually pay for, let's say building a new air base which costs me 250 barrels of oil a day (construction machinery consumes a lot of oil I guess), and converting that oil to bullets using automagical oil-to-bullet converters so that my anti-aircraft guns can fire.

I'm especially bothered by your repeated mention of a desire to have Spring have resource debt. A Spring battle is a closed system. If you spend 5000 energy per tick and bring in 4000 energy per tick, you shouldn't go 1000 energy into debt per tick, because where is that energy coming from? Instead, you go to zero energy... and then everything runs at 4/5 of capacity.

It's a tricky question indeed. There's issues of common sense, mod balance, and simulating flows of resources as accurately as possible. I recognize that you have a good reason for wanting the system to work the way you want - I just don't think that your way models flows of resources very accurately or efficiently.

[Dragon45]

Could it be coded in a way that units would have a tag in units (ResSpendingPriority?) to define if they spend resources before or after (before or after the current or a new resSpending priority scheme)?

Not that simple. Every action that a unit takes may be potentially resource-taxable if the modder wants it - reclaiming, moving, weapons-firing, building, breathing even. Using a hacked in tag system would mean that every action would have to essentially be part of a fucking gigantic priority matrix.

I really think that it should still be possible for Argh to do what we wants even with the current system.

[Argh]

Actually, I think there may be a simpler solution, that will leave nobody unhappy. If anything attempting to draw more than the current available M/E is called, it needs to be sent a Deactivate() command. That'd take care of things. Then modders could use Deactivate() to do whatever they wanted.

[AF]

felix, what if that plane took up 600 barrels of oil by simply existing? Wether it was moving or sitting in a warehouse it would still take up 600 barrels? What about then?

And the diea of goign into debt is that if you go into the negative then your economy stalls and all spending stops untill your back out of the red again. Afterall we're not stupid enough to allow unlimited overdrafts into the negative!

[MadRat]

This is why I suggested some sort of psuedo-lisp prioritization. Lisp programming is enormously efficient for working with flat arrays of objectively measured data. Its not hard on cpu resources for even thousands of items due to its efficient use of pointers and a bottom-up organization of the data elements.

Lets say the metal usage list has four items:

A - using 2 metal units / cycle
B - using 20 metal units / cycle
C - using 200 metal units / cycle
D - using 2000 metal units / cycle

Notice that element A is the smallest and element B is the largest? In Lisp you rank data by its quantitative quality. As more data is added in, the number of elements increase yet the data remains organized the same, bottom-up. Then when you want to use the data it makes it easy for certain conditions.

Let's say you have 2000 units of metal summarily stored. You would compare the value at the A element, note there is more stored than in A, then it would allow your program to subtract 2m and now you have 1998 stored. Since the stored metal is greater than the value of the B element, you continue on. You would get to element D and be unable to carry out the transaction until possibly the next time through.

Now this isn't really a good way to do it if you want to prioritize because you'd have to move through the list several times according to each priority. But by breaking each use of metal down to its own different lisp structure, you speed up the whole process because you are manipulating fewer elements overall. So in this way sometimes as granularity increases efficiency actually increases, too.

[Yeha]

For example, Targeting Centers used to be major costs, in OTA. This came along with a very large benefit, so it was worth it. But if your opponent blew up enough of your Energy production, you needed to shut it down asap to avoid stalling your entire economy.

In the spring system (and i think in ota to) if you don't have enough power it will shut down untill there is enough power to run it for a tick. You can still run a targeting facility on a solar plant, but it will only be on for very brief periods of time.

I don't beleive changing energyuse to an fixed allways on cost is a good idea, its not really the intended design of the economy.
A unit which uses resources but have no beneficial side effect is a bit undefined though and could probably be changed.

Actually, I think there may be a simpler solution, that will leave nobody unhappy. If anything attempting to draw more than the current available M/E is called, it needs to be sent a Deactivate() command. That'd take care of things. Then modders could use Deactivate() to do whatever they wanted.

If you mean sending deactivate if there isn't enough for energyuse/metaluse that would probably work, i don't think you want a unit with a high energy weapon that is unable to fire to shut down completely if it has other uses though.

[AF]

The problem is that these ticks are so minutely small that they're for all intensive purposes non-existent.

A tick should be every 32 frames not every 0.03 seconds.

[10053r]

One small note on priorities:

Clearly the first thing that must happen is resources are added by those units that create resources and do not use them.

Then, I agree the next thing that must happen would be that units that consume resources just to be "on" do so. Those that can not stay "on" because there is insufficient resources turn off.

However, I think the next thing that should happen should be firing weapons. How many times have you raced around turning off building frantically so that your guns will actually work and prevent the one jeffy from raping your base? Can you imagine the opposite situation? I can't either. Or at least, I can't imagine it being an emergency.

Arguments could be made that cloaking is more important than firing. I'm not sure, but it either goes cloaking then firing, or firing then cloaking.

Last comes building. If you really want to build and not fire, you can always ctrl-a and set to hold fire. That is much simpler and easier than selecting all your builders and telling them to stop. And metal makers should be considered to be "building" the metal, if that is possible.

[10053r]

A small note on debt:

There should be no such thing as debt. It is confusing to have negative energy or metal to both the player and modder. Certainly you should be prevented from cheating, but there should be no debt. Things which require resources that are not available should turn into useless hunks of metal, or even die in a huge fireball that takes your base with it, but they should not put you into debt.

(Actually, that's a pretty cool idea. Why don't you change demons so that they demand a "sacrifice" of resources and they self d if they don't get them? It fits the theme of the unit also).

[1v0ry_k1ng]

current method = WIN
0800 debtline = LOSE

[Felix the Cat]

Again, energy and metal debt makes absolutely no sense.

How do you come up with negative energy and negative metal?

Also, AF, debt would imply that everything would operate normally and you would just go into debt. So if I had +200 energy and -400, no problem, I'll just charge 200 energy to my American Express card (accepted at fine powerplants everywhere!) and spend 400 energy! And then I'd be 200 energy in debt.

Look at the US government for what debt implies.

I say, don't change the economy itself, use Argh's second suggestion and have Spring send a Deactivate() command to any unit that does not have sufficient resources to spend its fixed expenditure.

[AF]

err felix,


I AM SAYING
if(energystored<0 ) STALL

YOU ARE SAYING

if(energystored<0 ) energystored = energystored - energycost

I AM SAYING != YOU ARE SAYING

please! I have been trying to ram it into your head repeatedly that what I am saying != what you think I'm saying, and I've been doing this in many many threads where I say one thing and you hear something completely different, not just on the spring board either, you keep doing it on the OSRTS forum, you dont even read whats put into front of you from half of what your saying.

Next time you respond to anything I say reread what you're responding to to make sure what you think you read and what is on the screen are the same thing.

[MadRat]

Nobody is asking for an outright allowance to borrow, Felix, only to borrow against what will be coming in. Its creative book-keeping, I know, but not anything new in the accounting world. It's merely running an accrual-based balance sheet.

[bamb]

*bump*
So, is anything going to be done to this?

It really severely limits modding, it's of no practical use to make units use energy or metal to limit army stockpiling, since building happens almost like usual even if you have +50 metal productionand -200 use (because mainly of unit maintenance), just somewhat slower. In reality, no construction whatsoever should be possible. Such a situation actually shouldn't be possible.

I don't know how spring calculates units doing their things but I imagine it is done sequentially (they don't have their own threads). One need only add one "energy available" public int (or some other way) and then every unit that is going to use energy, first checks if there is enough energy, and if yes, substract the energy used from the variable and do your thing. All happening in a single tick. That is a foolproof system.

Of course then, which units work when power is low is measured by their order in the unit sequence, like the order which they were built in. It'd be a slight headache then to randomize that.
But the place of the unit in the list changes other things too and that's prone to cheating (ie units shooting at each other, the unit who has the lower id in the list gets the first shot). The order should be randomized.

[Argh]

I totally, completely agree with you, but I just haven't had time to recode this, and then I'd have to successfully argue that it was really necessary with the devs. At the moment, I have so many other things on my plate that this has slipped down my priority list, even though its on my Top Ten Things I Would Like To Improve.

Sorry- I'm not lazy, I'm simply too darn busy to get this done at the moment, and this isn't likely to change for some time.

[bamb]

Yeah argh, that's fine, I'm happy to hear it's on someone's mind.

One thing, if there is time, there could be either mod defined priorities (unit tag) or hardcoded priorities on which units use energy first. For example, weapons/fixed energy drain units are highest priority (this should be a no brainer), then radar and shields and jammers, then metal extractors, then builders and lastly metal makers.
That would change gameplay somewhat, as there'd probably be enough energy for d-gun always after start. But you can achieve that anyway by pressing ctrl-a and s, (all stop) with minor inconveniences later.

That'd add another pass though. On first pass you'd sum the energy requests for each category, and then you'd see if some categories would get full energy, if some would get partial and some would get none. You would allocate each category their energy share for the tick, and they'd then subtract from that. (Meaning that if you are a mex, and you need 2 energy, but there's 1 energy left in your category, you can't use it.)