"real unit cost" widget request (updated)

[Caydr]

A widget that displays a completed unit's real cost in energy/metal/buildtime for mod developers would be super-handy.

(exploits possible? maybe have cheating required to be on?)

edit: awesomeness in post 4.

[KDR_11k]

What do you mean with "real cost"?

[KingRaptor]

I'm guessing he means the raw metal and energy costs (and buildtime), rather than the adjusted cost displayed by the tooltip for a unit in Spring.

The tooltip for the buildpics already displays "real" cost, so I imagine it would be pretty easy to write a widget for it.

[Caydr]

I'm guessing he means the raw metal and energy costs (and buildtime), rather than the adjusted cost displayed by the tooltip for a unit in Spring.

The tooltip for the buildpics already displays "real" cost, so I imagine it would be pretty easy to write a widget for it.

Exactly

It's just easier during testing if you can say, "this unit costs this much, this unit costs this much" without referring to the factory/unit that constructs it.

Simple "cost" is imho completely inadequate and useless for any situation, it doesn't tell you anything you didn't already know and it could easily confuse newbies.

"Cost: 10283" could easily be replaced with: 1823 9682 in the appropriate color... it would use the same amount of room. Maybe add build time as well.

FORGET ALL THAT, SUPERTERRIFIC MEGA-GENIUS ULTIMATE SPECTACULAR HAPPY GREAT IDEA HERE:

Push a keystroke while you have a unit highlighted and it makes a semitransparent box with all of that unit's stats (can lua do the arithmetic to determine a units' weapons' individual DPS as well as a total?) which can be moved freely around the screen.

That way you don't need to write the stuff down even.

So you could have like 10 of these boxes on your screen, which say metal cost, energy cost, buildtime, and (low priority since a modder knows this by heart) DPS, if possible divided into all its weapons with a TOTAL dps at the bottom. Any other relevant vital stats could be displayed there too, but don't go overboard. max velocity, turning rate would be good, brake/accel would be somewhat useful.

But the best part - the widget remembers where everything was and restores all the info displays the next time you play. So during testing, you don't even need to build those units again, you can just refer to their boxes.

This too: http://spring.clan-sy.com/phpbb/viewtopic.php?p=205401

[Argh]

Um, I hate to put it this way, but this would still just be a very rough "balancing" widget. DPS is greatly a function of the scripting for the unit as well, then there is the factory's Workertime vs. the Buildtime, the turnrate, the velocity of the weapon, its area, etc.

This isn't a stupid idea, mind you, just not a very complete set of tools for doing real balancing- using simple calculations based off of incomplete data just gives you a very crappy picture of what's actually going on.

Making something that gave you a true balance picture for a unit, however, is possible, but I don't think it'd be practical to make it into a LUA gadget. It'd be easier, frankly, to make something in Excel that would output a complete picture of a unit. I just do it all in my head, and do a lot of playtesting of inter-unit combat to get a better idea of how well something works.

[KDR_11k]

Would still be nice to e.g. compare the exact costs of the two forces you're pitting against each other. Also DPS figures and such would help players figure out what to use against heavy targets.

[AF]

You're somewhat flawed in what you want caydr.

If your request was done,a nd you had this widget, you would eb flummoxed by the results.

You'd soon find that the price of a unit fluctuates based on the economy of the user. When stalling the price fluctuates greatly.

Please go read the big threads discussing how borked springs economy is, explaining how stalling can actually give you free metal and energy and how the ordering of unit costs of different kinds is borked.

[KDR_11k]

Does stalling really give you free resources? I don't think so, the only difference you get is the discrete nanoparticle building that can end up overcharging you on the last nanoparticle unless you make sure all values are cleanly divisible by 32. You certainly don't get free nanoparticles, in CvC factories tended to just lock up completely if your resources never went over their cost for one nanopaticle.

[AF]

It was my understanding that if you subtracted building costs and ran out then standing unit costs would be ignored.

And I was also under the impression that a nanoparticles cost was dependant on the builder it came from explaining why a conbot will give more nanospray and build power than a commander when stalling.

Also IIRC sometimes if a nanoparticles cost cannot be met but say 70% of the required cost is present, the nanoparticles emmitted anyway for free. This would explain numerous circumstances in numerous games.

[KDR_11k]

It was my understanding that if you subtracted building costs and ran out then standing unit costs would be ignored.

Yep but that doesn't apply to weapon costs or anything like that, only artificial costs that don't actually do anything so you're not getting your units cheaper, you're just not paying fake costs.

And I was also under the impression that a nanoparticles cost was dependant on the builder it came from explaining why a conbot will give more nanospray and build power than a commander when stalling.

Yep, cost*(workertime/buildtime)/32. A nanoparticle will not spawn if you can't pay for it so a more powerful constructor may end up not producing any when stalling.

Also IIRC sometimes if a nanoparticles cost cannot be met but say 70% of the required cost is present, the nanoparticles emmitted anyway for free. This would explain numerous circumstances in numerous games.

Unit.cpp AddBuildPower(amount, builder):

Code: Select all

		lastNanoAdd = gs->frameNum;
		const float part = amount / buildTime;

		if (beingBuilt) {
			const float metalUse  = (metalCost  * part);
			const float energyUse = (energyCost * part);
			if ((gs->Team(builder->team)->metal  >= metalUse) &&
			    (gs->Team(builder->team)->energy >= energyUse) &&
			    (!luaRules || luaRules->AllowUnitBuildStep(builder, this, part))) {
				builder->UseMetal(metalUse);
				builder->UseEnergy(energyUse);
				health += (maxHealth * part);
				buildProgress += part;
				if (buildProgress >= 1.0f) {
					if (health > maxHealth) {
						health = maxHealth;
					}
					FinishedBuilding();
				}
				return true;

EDIT:

Hm, UseMetal/Energy will not deduct correctly if the given resource is less than the previous upkeep value*10, AddBuildPower doesn't check if they were deducted properly. Give me a moment, I'll fix it.