- Table of contents
- Problems with that
- Facts
- What/How we can improve
- Visibility of this improvement
Problems with that
We define the energy/metal requirements completely different if the weapon is a stockpiled one, a shield or use fuel for bombs (bombers)
And even more different if the unit cloaks, because cloak isn't even in weapon defs.
As far as I know, some feature requests from 2007 still apply:
http://springrts.com/phpbb/viewtopic.ph ... rgypershot
http://springrts.com/phpbb/viewtopic.ph ... rgypershot
Conclusion: Units can only have 1 stockpile weapon and stockpiling can't be assisted, mainly because the silo has a stockpile-time instead of projectiles and silo have workerTime variables, and thus you can't get the engine to support it without lua.
You can make weapons use fuel, but you can not - for example - make cloak or walking slow down the fuel regeneration without many lines of lua.
Fakts
I've read that you can change unit defs with lua before the engine sees them.
That could be used to convert UnitDef tables into engine-supported ones.
And extract all important things into a custom table (or customparams) - for a gadget.
It could also check if it can not waive the hacks - dependent on variable values.
Example failure today:
gun1: 300e per shot, 1s reload 1000 range, 500 damage
gun2: 1000e per shot, 3s reload 500 range, 3000 damage
Can you imagine what happens if you stall energy?
* gun2 will never fire, because gun1 converts energy before unit2 is allowed to.
* gun1 will maybe never fire too, because another unit's weapon converts 10e to 10 damage (a lot worse) before it could even see the 300e in player's storage.
What/How we can improve
The best because simpliest solution would be:
Code: Select all
PlayerDefinition, UnitDef, WeaponDef or AbilityDef ={
...
storage ={
<string: resource> = <number: limit>, ...
},
converters ={
{
cooldown = <number: gameframes> or false, -- if false it is evaluated as often as possible in one step (: =faster :) before evaluating the next converter
importer = <boolean> or false,
exporter = <boolean> or false,
input ={
<string: resource> = <number: amount>, ...
},
inputConditions = <table:{
<string: resource> = {
absolut = <int: value>, -- storedMin = value
relative = <float(0..1): value>, -- storedMin = math.floor(value*storageLimit)
},
}> or false,
output ={
<string: resource> = <number: amount>, ...
},
outputConditions = <table:{
<string: resource> = {
absolut = <int: value>, -- storedMax = storageLimit -value
relative = <float(0..1): value>, -- storedMax = storageLimit -math.floor(value*storageLimit)
}
...
}> or false,
},
... -- more converters
},
...
}
--[[
input enhances the input conditions
if the converter has input (false for generators), output enhances the outputConditions
if the converter is an importer, all input is taken from the next higher obj with such storage
if the converter is an exporter, the output is given to the next higher obj with such storage defined
device < unit < player < team < ally-team < world
Converters in a unit are evaluated in the order they are defined.
]]--You are able to control the energy flow/distribution inside the unit
* set the energy importer of the unit to a cooldown of about 15-30 frames and the device energy importers to 5-10 frames cooldown.
* The lower cooldown let them alternately absorb the supply-spike into their device - they will be idle for some time if the spike is absorbed faster than it replenishes.
This makes reload, stockpile, shieldRecharge, fuel and other redundant implementations obsolete and provides a much more flexible solution.
You could easily implement assisting a silo by adding each assister's "workerTime" resource to the silo-unit's "workerTime" storage:
Code: Select all
converters ={
{ cooldown=0, importer=true, input={workerTime=1,metal=1,energy=1}, output={metal=1,energy=1} },
{ cooldown=0, input={workerTime=1}, output={} },
}Widgets that make cons assisting silos would be a lot easier.
On estall, units which combine shield+weapons can stop charging their shields in favor of fully powered weapons without additional lua.
Abilities like flying/moving/cloaked can decrease the weapon output or shield recharge
-> Unit is more effective when not moving or uncloaked
Everything is unified
* widgets can still access reload time by getting the converter producing the required stockpile-resource and track down more complex behavior easier than it is with custom lua for each unit.
* see Zero-K's defender where widgets show wrong dps because burst is lua-ed to not waste shots after the target dies.
Finally:
* Helps game devs to balance units
* Makes game more interesting
