Code: Select all
if(unitDef->activateWhenBuilt)
{
Activate();
}
gs->Team(team)->metalStorage+=unitDef->metalStorage;
gs->Team(team)->energyStorage+=unitDef->energyStorage;Spring's "economy", GET/SET MAX_SPEED
Moderator: Moderators
Further down the chain, we find that critical section about energy being used by things making use of ActivateWhenBuilt. Again, if I'm reading this right, by the time the code loops back around, then it's going to reset everything to zero again.
AAAaAAAAAh. Here is the culprit. Even more than wiping everything to zero! OMG... it totally cheats. I knew it! It really does wipe out your debt, plain and simple! How... lame 
Just rewriting those two loops (and the two for MakeMetal/Energy, which are equally cheating) like this would fix things, and put Spring's gameplay back on an honest footing:
Voila... no more cheating code, covering for players who are spending more than they actually have. I can't believe it was really done this way- there is no fancy balancing algorithm or anything like a economy AI here. It just plain cheats. All so that players who suck won't nanostall, from the looks of things 
Code: Select all
bool CUnit::UseEnergy(float energy)
{
if(energy<0){
AddEnergy(-energy);
return true;
}
gs->Team(team)->energyPull += energy;
bool canUse=gs->Team(team)->UseEnergy(energy);
if(canUse)
energyUseI += energy;
return canUse;
}Code: Select all
bool CUnit::UseMetal(float metal)
{
if(metal<0){
AddMetal(-metal);
return true;
}
gs->Team(team)->metalPull += metal;
bool canUse=gs->Team(team)->UseMetal(metal);
if(canUse)
metalUseI += metal;
return canUse;
}Code: Select all
bool CUnit::UseEnergy(float energy)
{
gs->Team(team)->energyPull += energy;
bool canUse=gs->Team(team)->UseEnergy(energy);
if(canUse)
energyUseI += energy;
return canUse;
}
Last edited by Argh on 08 Nov 2006, 08:19, edited 1 time in total.
That's to prevent an old TA trick when you gave a Moho Metal Maker (or just a lot of normal ones) to the opponent right before attacking his base. What happened was his energy use increased dramatically and more often than not his base went into e-stall, meaning Annihilators and such (and probably even HLTs) could not fire and so your attack went unopposed. As I understand it, this bit of code will turn OFF energy-using units given to somebody else.Argh wrote:And here's yet more hard-coded stuff:Code: Select all
if(type==ChangeGiven && unitDef->energyUpkeep>25){//deactivate to prevent the old give metal maker trick Command c; c.id=CMD_ONOFF; c.params.push_back(0); commandAI->GiveCommand(c);
Last edited by yuritch on 08 Nov 2006, 07:45, edited 2 times in total.
Sure, but why fix it that way? Why not just eliminate giving stuff to non-Allied players?
At any rate, that's just a (very minor) side point. The main point is that Spring's economy cheats. Period. No wonder I was never able to get the results out've NanoBlobs on the economic end that I was originally wanting- gameplay where players would have to ride a knife-edge between Sheep populations and combat fodder Instead, I ended up with what I regard as an inelegant kludge of build-time and other factors to produce a statistically similar result- but it's just not as clean, and relies more on spam than on the threat of running out of resources, because I could never get it working right. Now that I know why I'm doubly-disgusted. I was expecting some elegant load-balancing code or something... with a minor mathematical bork that was somehow spending on things before making the final tally. Instead, I've found that it flat-out gives the player whatever they need stay above water
When I designing NanoBlobs, I wanted players to very actively have to move their Sheep around, to keep them from being spotted and killed, because otherwise their economy would shut down. Porcing would just give the enemy better chances- and AIs could play exponentially and have a fairly good chance against humans, because their Sheep population would explode outwards over time.
That model is impossible- and so are a lot of others- if the economy has this giant crutch built into it If there is no real penalty for spending more than you actually have, other than slowing the pace at which things are built (which does work, but never STOPS and is proportional to the M/E available after cheating has set the balance to zero) ... ugh...
At least now the AI designers know why their GroupAI econ-management tools aren't working right, now.
At any rate, that's just a (very minor) side point. The main point is that Spring's economy cheats. Period. No wonder I was never able to get the results out've NanoBlobs on the economic end that I was originally wanting- gameplay where players would have to ride a knife-edge between Sheep populations and combat fodder
Instead, I ended up with what I regard as an inelegant kludge of build-time and other factors to produce a statistically similar result- but it's just not as clean, and relies more on spam than on the threat of running out of resources, because I could never get it working right. Now that I know why I'm doubly-disgusted. I was expecting some elegant load-balancing code or something... with a minor mathematical bork that was somehow spending on things before making the final tally. Instead, I've found that it flat-out gives the player whatever they need stay above water When I designing NanoBlobs, I wanted players to very actively have to move their Sheep around, to keep them from being spotted and killed, because otherwise their economy would shut down. Porcing would just give the enemy better chances- and AIs could play exponentially and have a fairly good chance against humans, because their Sheep population would explode outwards over time.
That model is impossible- and so are a lot of others- if the economy has this giant crutch built into it
If there is no real penalty for spending more than you actually have, other than slowing the pace at which things are built (which does work, but never STOPS and is proportional to the M/E available after cheating has set the balance to zero) ... ugh...At least now the AI designers know why their GroupAI econ-management tools aren't working right, now.
And... one last and final proof, in case there is anybody wondering why this is at all important, or doesn't believe the code snippets from Unit.cpp I've provided, showing that there is no load-balancing AI and that economic drains aren't random and that Spring cheats to keep players at above zero and that no matter how far in the negatives you go, it does not affect the ability to build, since you're using "positive" resources handed out before the costs of things using M/E Make/Use are included:
In this shot, you're watching my Lord build an Archer- at full speed. There is absolutely no penalty of any kind being imposed, after checking and timing it multiple times (which is exactly what the code says, but some people won't believe this until they see a screen).
In this shot, you're watching my Lord build an Archer- at full speed. There is absolutely no penalty of any kind being imposed, after checking and timing it multiple times (which is exactly what the code says, but some people won't believe this until they see a screen).
How long does it take to cycle through all of the units energy production?
Seems like if you alternated when production and use occur you could avoid this whole problem. The first time through you add up the resources generated and add up the potential usage, the next time through the use of the resources occurs proportionate to the number available. If this is a board game then players get to divvy up resources to their wants each round, but that is too much micromanagement.
Seems like if you alternated when production and use occur you could avoid this whole problem. The first time through you add up the resources generated and add up the potential usage, the next time through the use of the resources occurs proportionate to the number available. If this is a board game then players get to divvy up resources to their wants each round, but that is too much micromanagement.
How come Argh has 994 metal in the bank despite a huge deficit in his expenditure in both screenshots? He should have gone into stall immediatly as soon as those demons where spawned, he shouldnt even be able to terraform the land to build an archer.
Bu arghs code still works, because instead of adding the energy*-1 to the income, it's taking away energy from the outgo so the same effect is observed. It messes with the stats in the top resource bar though =p.
However I agree that unit cost should come before those of units that are on/offable, and then building should come last, rather than them all being randomly done, which is more likely the actual cause of this whole issue, and a huge pain for AI economy management.
Bu arghs code still works, because instead of adding the energy*-1 to the income, it's taking away energy from the outgo so the same effect is observed. It messes with the stats in the top resource bar though =p.
However I agree that unit cost should come before those of units that are on/offable, and then building should come last, rather than them all being randomly done, which is more likely the actual cause of this whole issue, and a huge pain for AI economy management.
In terms of strategy, the rule is simple:
If you're not using all the resources you can, then your opponent might be. TA-style gameplay is defined by exponential growth. Therefore, if you have too much extra resources, they're not being invested, and you're going to grow at a slower rate than your (presumably better) opponent.
Most good TA players will tell you to stay *aggressively* as close to the edge as possible for most of the game (with few exceptions) in terms of metal, and ideally not have a full energy bar either.
If you're not using all the resources you can, then your opponent might be. TA-style gameplay is defined by exponential growth. Therefore, if you have too much extra resources, they're not being invested, and you're going to grow at a slower rate than your (presumably better) opponent.
Most good TA players will tell you to stay *aggressively* as close to the edge as possible for most of the game (with few exceptions) in terms of metal, and ideally not have a full energy bar either.
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
Just out of curiosity, how would you rate yourself as a Spring player? I haven't ever played you or even seen you play a (non-NTai-testing) game.AF wrote:Ideally you want to be continuosly overproducing so that you can continuosly expand to keep up with economic expansion in a runaway growth.
I do know that all of the good players I have watched play - and by good players I mean those who win the vast majority of their games, people like Lion_heart and LordMatt and pr0_randy and the like - are constantly on the edge of m-stall for the vast majority of the game.
If you're overproducing you're wasting resources; overproduction is a sign that you need to spend more.
Felix, how much about coding do or dont you know out of curiosity.. This thread is not about l33t skill, its about how the engine is handling resources.. skill is not what is up for debate, so dont come in here questioning peoples ability to play spring..
The economy does wonky things as you approach 0 and this means that you cannot set up mods to make more use of draining units/weapons.. because of what argh is talking about.. IF you want to attempt to use that stuff you have to use negative storage in order to force 0, because the engine doesnt allow it to actually happen..
The economy does wonky things as you approach 0 and this means that you cannot set up mods to make more use of draining units/weapons.. because of what argh is talking about.. IF you want to attempt to use that stuff you have to use negative storage in order to force 0, because the engine doesnt allow it to actually happen..
felix obviously didnt understand. You overproduce so that you can expand your offensive infrastructure. When you've expanded to fit this overspending you thenr ealize that while you where doing it your ecnomy expanded.
And I have a lot of experience, however I am not an avid AA player, instead I try as many mods as I can, and tend not to play AA against pros, but rather I play AA for fun when there are no other options.
http://en.wikipedia.org/wiki/Ad_hominemJust out of curiosity, how would you rate yourself as a Spring player? I haven't ever played you or even seen you play a (non-NTai-testing) game.
And I have a lot of experience, however I am not an avid AA player, instead I try as many mods as I can, and tend not to play AA against pros, but rather I play AA for fun when there are no other options.
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
Whoa! Who let the attack dogs out?Fanger wrote:Felix, how much about coding do or dont you know out of curiosity.. This thread is not about l33t skill, its about how the engine is handling resources.. skill is not what is up for debate, so dont come in here questioning peoples ability to play spring..
The economy does wonky things as you approach 0 and this means that you cannot set up mods to make more use of draining units/weapons.. because of what argh is talking about.. IF you want to attempt to use that stuff you have to use negative storage in order to force 0, because the engine doesnt allow it to actually happen..
I was responding to AF's assertions regarding the ideal way to manage your economy, not to Argh's assertions regarding how Spring handles zero resources. I intentionally did not comment on that because I don't know enough about the Spring code to interpret the snippets that Argh provided to "prove" his points one way or the other. I'm sorry, I should have been more clear, but where I come from it's common practice not to quote if the post you're responding to is the last in the topic.
(By the way, Fanger, I'll make you a deal: you don't troll me, and I won't troll you. Deal?)
The Ad-Hominem link is getting old. And anyway felix wasn't attacking you, just asking a perfectly honest question.AF wrote:felix obviously didnt understand. You overproduce so that you can expand your offensive infrastructure. When you've expanded to fit this overspending you thenr ealize that while you where doing it your ecnomy expanded.
http://en.wikipedia.org/wiki/Ad_hominemJust out of curiosity, how would you rate yourself as a Spring player? I haven't ever played you or even seen you play a (non-NTai-testing) game.
And I have a lot of experience, however I am not an avid AA player, instead I try as many mods as I can, and tend not to play AA against pros, but rather I play AA for fun when there are no other options.
Please, for the love of Dog, people.
If you are not a programmer or mod designer, or are a programmer who has not read through Unit.cpp yet, stay out of this thread- half these comments are completely irrelevant, and I mean that in the nicest possible way, because I know you're trying to be helpful and I appreciate that
This is not about strategy.
This is not about AIs, although they are profoundly affected by this.
This is not even about theoretical musings about what should be happening, at this point. Now that I know what is happening- it's a bug, pure and simple. The question now is how it gets fixed, without breaking Spring elsewhere Unit.cpp is the core loop.
As that last screenshot clearly shows, even when you should have a negative economy, incapable of doing anything- you can still build, at FULL SPEED. There is no slowdown. It doesn't stop. The costs aren't being calculated properly- you can spend on new stuff all you want.
That isn't even remotely OK. I will sit down with Unit.cpp tonight and attempt to repair this bug.
If you are not a programmer or mod designer, or are a programmer who has not read through Unit.cpp yet, stay out of this thread- half these comments are completely irrelevant, and I mean that in the nicest possible way, because I know you're trying to be helpful and I appreciate that
This is not about strategy.
This is not about AIs, although they are profoundly affected by this.
This is not even about theoretical musings about what should be happening, at this point. Now that I know what is happening- it's a bug, pure and simple. The question now is how it gets fixed, without breaking Spring elsewhere Unit.cpp is the core loop.
As that last screenshot clearly shows, even when you should have a negative economy, incapable of doing anything- you can still build, at FULL SPEED. There is no slowdown. It doesn't stop. The costs aren't being calculated properly- you can spend on new stuff all you want.
That isn't even remotely OK. I will sit down with Unit.cpp tonight and attempt to repair this bug.
Related but not exact, I dont know if it located in the same set of code but you never know, I wonder if in your checking and bufixing if you can confirm or deny whether the engine still requires at least 1 existing metal and energy to even start construction even if the unit has a metal or energy cost of 0...
Otherwise I would love to have actual debt, it would allow us to actually set up buildings and units to force lower numbers based on used resources...
Otherwise I would love to have actual debt, it would allow us to actually set up buildings and units to force lower numbers based on used resources...