Hello guys, is it possible to make units have different maxspeed/turnrate/turretrotationspeed etc.. according to different factors, like : did unit fired/aimed recently or if unit is heavily damaged for example.
I'd like to try to test some stuff making some units faster when out of fight for long enough.
Changing units mobility in real time
Moderator: Moderators
Re: Changing units mobility in real time
Unit speed modification is always between zero and Max in Unitdef.. but yes, you can totally set that in lua script.
Code: Select all
function setSpeedEnv(k, val)
val = math.max(0.000000001, math.min(val, 1.0))
env = Spring.UnitScript.GetScriptEnv(k)
if env then
udef = Spring.GetUnitDefID(k)
Spring.UnitScript.CallAsUnit(k, Spring.UnitScript.SetUnitValue, COB.MAX_SPEED, math.ceil(UnitDefs[udef].speed * val * 2184.53))
end
end
Re: Changing units mobility in real time
Pica
Why is the alteration of speed something that should kill 3k unit battles?
Doo
Basically, i'm saying the part that is to figure out isn't how to slow
Pica
Dont do it in a unitscript then- do it in a gadget..
Doo
Yup, that much is what i suggested, but even then, that would mean either using (ProjectileCreated and watch weapons) or AllowUnitWeaponTarget(modifié)
Triton
what doo said is if unit is aiming => we add it into a table with a start frame then it applies a slow
for each frame and for each unit which already aimed recently, it compares start/current untill current > start + cooldown time
I tried to translate
but ofc, now doo is here
Doo
Which are kinda costly when it comes to multiple units
+ setting up all the different timers. I was mostly saying it wouldn't be worth the trouble
Would prolly hit perfs on BA's huge battles and stuff
Triton
the question is : what is best solution to make units have 2 different maxspeed (turnrate eventually) according to if they aimed or not recently
Pica
Eh, do it in the Aiming thread itself - and have a background thread per unit where its reset after a time off sleep?
or just do it in the aiming thread- and have a gadget that upon fire, takes note of the gameframe and counts down?
resetting upon time ending
How about coding it and just profiling it?
I know- radical
do it in the Aiming thread itself - and have a background thread per unit where its reset after a time off sleep?
=> Could use the RestoreAfterDelay threads, that would be very little addition actually.
"issue" being implementation in all unit scripts (especially cob scripts)
make it in a gadget
timer starts counting after shot has been fired
you have to die some death
Why is the alteration of speed something that should kill 3k unit battles?
Doo
Basically, i'm saying the part that is to figure out isn't how to slow
Pica
Dont do it in a unitscript then- do it in a gadget..
Doo
Yup, that much is what i suggested, but even then, that would mean either using (ProjectileCreated and watch weapons) or AllowUnitWeaponTarget(modifié)
Triton
what doo said is if unit is aiming => we add it into a table with a start frame then it applies a slow
for each frame and for each unit which already aimed recently, it compares start/current untill current > start + cooldown time
I tried to translate
but ofc, now doo is here
Doo
Which are kinda costly when it comes to multiple units
+ setting up all the different timers. I was mostly saying it wouldn't be worth the trouble
Would prolly hit perfs on BA's huge battles and stuff
Triton
the question is : what is best solution to make units have 2 different maxspeed (turnrate eventually) according to if they aimed or not recently
Pica
Eh, do it in the Aiming thread itself - and have a background thread per unit where its reset after a time off sleep?
or just do it in the aiming thread- and have a gadget that upon fire, takes note of the gameframe and counts down?
resetting upon time ending
How about coding it and just profiling it?
I know- radical
do it in the Aiming thread itself - and have a background thread per unit where its reset after a time off sleep?
=> Could use the RestoreAfterDelay threads, that would be very little addition actually.
"issue" being implementation in all unit scripts (especially cob scripts)
make it in a gadget
timer starts counting after shot has been fired
you have to die some death
Re: Changing units mobility in real time
We need something to tie irc and the board together.
Some bot itch as bridge.
Some bot itch as bridge.
Re: Changing units mobility in real time
3000 units
Let's be gracious. Half of them are in combat.
Firing at a rate of 1 shot ever 3 seconds.
that is 1500/3 =500
500/30
Means 16 something firing per frame.
Implement and profile.
Let's be gracious. Half of them are in combat.
Firing at a rate of 1 shot ever 3 seconds.
that is 1500/3 =500
500/30
Means 16 something firing per frame.
Implement and profile.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Changing units mobility in real time
I've found SetUnitCOBValue to be unreliable for this purpose. Use SetGroundMoveTypeData. You should have a look at this gadget and do something like it: https://github.com/ZeroK-RTS/Zero-K/blo ... ibutes.lua
I would do the changes inside the unit script. The script callins are already used for animations so I don't see any significant overhead, except if you need to add a new restore after delay thread. Here is a script which changes the movement speed of a unit for a few seconds after it fires: https://github.com/ZeroK-RTS/Zero-K/blo ... kskirm.lua
I would do the changes inside the unit script. The script callins are already used for animations so I don't see any significant overhead, except if you need to add a new restore after delay thread. Here is a script which changes the movement speed of a unit for a few seconds after it fires: https://github.com/ZeroK-RTS/Zero-K/blo ... kskirm.lua