Serious Issue With Energy, probably Metal

[AF]

Argh you've made a pigs ear of explaining it.

Basically here we have a lottery.

Lets tot up all our incomes and say it comes out as 100.

Now lets go through all our units. We start subtracting costs as we go along, building costs, fixed costs, until we run out.

So now that we've ran out we continue going through our list. Any fixed costs that are still in the list after we've ran out are now basically free. Any construction will slow down, and any weapons that require energy refuse to fire.

So basically its a matter of how far along the list you are wether your HLT fires or not. First come first served.

[Argh]

No.

What happens, AF, is that regardless of order, regardless of fixed costs, you can still fire that HLT, so long as nobody is building anything or cloaking.

You can have 20 tanks, all costing 1/3 of your real income in E. Select any one at random, and your chances of it being The One That Can Shoot, according to your theory, are about 1 in 5.

Not so. It will fire, 100% of the time, because fixed costs aren't being subtracted before firing / building / cloaking. I don't know when they're being removed, but it's not even in that sequence.

So instead of just whining about it, I built a system that doesn't require polling everything every gameframe, handles Cloaking, could handle Activation-like behaviors, handles shooting, and is cheaper to operate than Spring's system while correctly factoring in fixed costs vs. real income. The only oddity is weapons behavior, where it appears it runs the Lua twice before the first call-script has returned (which I thought wasn't possible, and makes me wonder if it's running properly in sync).

I haven't factored in building things and subtracting each update, but again, that's trivial, one hit on Create, another on Finished, and in-between, get percentage built, subtract difference and save the remainder. Hell, I'll put that in, just to demonstrate a complete working system. If it works out, I may get rid of Metal, too. But Spring will continue to poll my Units regardless. Maybe what I really need here is a switch that tells Spring not to waste CPU cycles on the default economy...

[AF]

Bullshit


You obviously didnt read my post properly and only read it enough to argue against a few cherry picked points to make it look like you were right and know better.

The spring engine doesn't jumble up and reassign unit IDs at the start of every game frame.

The odd part is, you've raised threads in the past months and months ago, about the same problem, yet you cited a completely different reason, a completely different solution, and you rubbished those reasons in this very thread when they were presented by other people.


Thus we can conclude that regardless of the problem, your insights as to why they are happening and the exact causes and solutions you cite, are nothing but mere speculation that you yourself do not truly understand.

If you are correct, then you should be able to measure and test out your theory, and provides us with something other than words. There is nothing stopping you writting out a gadget to test this and generate tables of results.

Or better yet, there is nothing better than reading the actual code. You cannot argue with me argh because this is not my opinion, this is the actual code being executed.

So here is the code which does something other than what argh says is happening.

( which also leads me to a bug in cunit::slowupdate if (health < 0.0f) { should this not be <= ? units with 0 health are 'alive' atm ).

Argh, refer to line 724 onwards of rts/units/unit.cpp This is how an individual unit handles its resource consumption. You dont need to understand very much C/C++ at all, its all self explanatory.

The SlowUpdate method is called from CUnitHandler on line 281 onwards in rts/units/UnitHandler.cpp

To make your interpretation of the setup correct, you would need to write and submit patches to the engine to make the defective behaviour work as you said it would.

The problem is that resources are nondeterministic. This is because of the 'free cash' problem, in that there is no visible effect to fixed costs of units merely existing, essentially making them free or not free depending on how many units took money out the pot beforehand.

As you can see, unit 2 doesnt care if unit 3 has fixed costs, it takes what it needs out of the resource pool and then the next unit is called. If there isn't enough for fixed costs then hoohaa tough, itll just get it for free.

This is why your HLT always fired, because it was nearer to the front of the queue. It could sap resources before other stuff got a look in.

The solution? Fix the ordering.

Right now:

Code: Select all

for each unit
    do all this units resource logic in one go
end for

What we need:

Code: Select all

for each unit
    add/subtract fixed costs metal decay etc
end for

for each unit
    do construction costs
end for

for each unit
    do weapon/cleak/stealth costs
end

Which ironically is very similar to a theory you declared nonsense. A theory that you yourself originally stated.

[Argh]

Read this, and follow what happens with energyFireCost. It's doing exactly what I said it did. It doesn't check to see if you have enough energy left, it just spends it. It could just as easily check vs. available Energy before allowing it to step, but no, it just spends it immediately. The intelligent solution is to just check if energyPull + energyFireCost > energy, if yes, then don't fire. It's a trivial fix.

I mean like, wow, I do that in the Lua version, and voila, problem was solved. Other than updating only every second, as opposed to every SlowUpdate, and I use a smarter system for all fixed or cyclic costs, so that I don't poll every single Unit in the simulation. The only stuff that should get polled, in fact, is stuff being built, imo.

I think you prolly need to take that page-long rant down now

[Tobi]

Read it better. It does check to see if you have enough energy left.

[Argh]

Code: Select all

 if (TryTarget(targetPos,haveUserTarget,targetUnit) && !CobBlockShot(targetUnit)) {
if(weaponDef->stockpile){
const int oldCount = numStockpiled;
numStockpiled--;
owner->commandAI->StockpileChanged(this);
eventHandler.StockpileChanged(owner, this, oldCount);
} else {
owner->UseEnergy(energyFireCost);
owner->UseMetal(metalFireCost);
owner->currentFuel = std::max(0.0f, owner->currentFuel - fuelUsage);
}

No, it doesn't. UseEnergy isn't applied until the next SlowUpdate; it's dumping a cost forwards in time, instead of vs. current resources.

Should be:

Code: Select all

if (energyFireCost) && (energy - energyFireCost > 0.0)
{
energy -= energyFireCost;
}

That way, that cost is applied RIGHT NOW, and if you fire 10 guns, the first one may fire, but by the time we get to the 10th, we don't have energy left. Immediate events should ALWAYS spend that resource IMMEDIATELY... that's why they're immediate (and something we want to avoid except where necessary).

[Tobi]

Learn to read code.

Code: Select all

 if ((weaponDef->stockpile ||
(teamHandler->Team(owner->team)->metal >= metalFireCost &&
teamHandler->Team(owner->team)->energy >= energyFireCost)))
{

(323-326)

[Argh]

It's still passing that cost forwards in time...

teamHandler->Team(owner->team)->energy -= energyFireCost

Not energyUse

[Tobi]

Code: Select all

bool CTeam::UseEnergy(float amount)
{
	if ((energy - (prevEnergyUpkeep * 10)) >= amount) {
		energy -= amount; // <----------------------------------- LOOK HERE !!!
		energyExpense += amount;
		return true;
	}
	return false;
}

[Argh]

If it returns false, then it's not stopping the shot from happening.

[Tobi]

That is why it is checked beforehand.

I see one bug with it though and that is due to the (prevEnergyUpkeep * 10) term.

[Argh]

I am confused, though. It does look like it should be working overall. You're right. Polling randomness aside. Meh.

[Tobi]

Hmm, the *upkeep stuff isn't even used so with regards to checking resource amount before firing weapons there is no bug.

The only issue is hence that there is no defined order in which resources are used.

[Argh]

The problem must be with my testing procedure then. After reading through all of it, I'm convinced. There must be something else screwing up my results.

[AF]

Ascertaining predictable deterministic results is not possible in a non-deterministic system unless you're willing to sacrifice being right.

Please re-read mine and tobis posts. The answer has been said about 5 times already

[Argh]

Well, I want a very strict system, in terms of order-of-operations. It's an important part of some of the gameplay I want to introduce.

I wrote one; other than covering building costs and storage, it's feature-complete and it's all in one place and it works, and doesn't require this kind of global polling, either. I guess I should complete it and include building and storage, mainly so that it's a demonstration of a complete model.

[Forboding Angel]

To argh's credit, I have experienced the same oddity.

Spring's default resource model has a lot of gaping holes in it.

[AF]

Indeed, I mentioned it long ago since it can make AI algorithms that predict resources problematic

[KDR_11k]

If anyone cares, Gundam's energy system uses priorities to determine which units to de-power first in case of a brown-out, it's a C&C-style "not enough power = stunned unit" system.

[Pxtl]

Couldn't units be programmed on a 2-turn "request/consume" cycle? As in, units only spend resources from _last_ cycle, and don't touch the _current_ cycle stuff? It would mean you'd need a lot of E-storage though, since you'd be storing energy equal to your consumption.