Loading...
  OR  Zero-K Name:    Password:   

Help with lua gadgets - Detection target of a shot

25 posts, 1390 views
Post comment
Filter:    Player:  
Page of 2 (25 records)
sort
11 years ago
I'm planning to try to re-write AA micro into a much simpler (and hopefully maintainable) overkill prevention instead of fire control logic.

To do this, I need to be able to detect this:

An AA tower (eg. defender) without an attack order, on fire-at-will, just fired a missile. The call-in that triggers on the creation of a missile needs to be able to tell what the target of the missile is.

I was told that in the unit script, one could do something to the firing event to help this, but I cannot figure out what to do.
+0 / -0
Hi jseah, this example I found in ZKdota:
https://code.google.com/p/zero-k/source/browse/trunk/mods/zkdota/scripts/custom_com_recon.lua#378

you use:
function script.AimWeapon(num, heading, pitch) end

to Allow/Block weapon fire by returning "true" or "false".
and use Spring.GetUnitRulesParam(unitID, tostring(num)) to control them remotely using Gadget.

There's also:
function script.FireWeapon(num) end

and

function script.Shot(num) end

as event used to trigger shot VFX.

if this is useful, give credit to N0U
+0 / -0
11 years ago
Thanks, but not what I'm looking for. I need the target a weapon is intended to hit when its fired. Aka, whatever a homing missile weapon will have its missile locked on to.
+0 / -0
Here's something better for you, and for all of mankind today!
And you can retarget them, too!
+0 / -0


11 years ago
Do not poll the actual projectile targets just for the sake of AI. It sounds very slow.

You should look at unit_dont_fire_at_radar.lua, unit_target_priority.lua, script.BlockShot(num, targetID) and script.Shot(num, targetID).
+0 / -0
11 years ago
quote:
AUrankjseah> The call-in that triggers on the creation of a missile needs to be able to tell what the target of the missile is.


If it got fired in the same game frame, missile->launcher(=defender)->target should point at the target.
+0 / -0
quote:
Do not poll the actual projectile targets just for the sake of AI. It sounds very slow.

Using the new callins linked above, there would be no actual polling.

On projectileCreated: (if in managed weapons table) add target to some targets list so you can manage it; add projectile to another table.

If projectile is a guided missile and you want to do some retargeting logic here: change projectile target.

On projectileDestroyed: remove projectile from list; if no live projectiles still point to target, remove that too.

On unitDestroyed (if in target table): remove (kill or abandon, your choice) or retarget all linked projectiles.

That's pretty much it. Doesn't sound any heavier than, for example, wolverine mines spawning units.

I see no reason to actually manage overkill for rapid-fire non-guided weapons like razorkiss and cobra/copperhead, so most of those would apply to slow-firing guided-missile weapons that shouldn't produce much spamload. (possible exception is wandel, but wandel is also rapid-fire, so could be omitted).
+0 / -0
11 years ago
erm... do we have AA named wandel????
+0 / -0


11 years ago
quote:
erm... do we have AA named wandel????

We have something called Vandal, but that sounds too brutal for the cute puffy thing that can't even kill a bomber for cost.
+0 / -0
11 years ago
""Here's something better for you, and for all of mankind today!""

OMGs, why did I not know of this...
+0 / -0
quote:
OMGs, why did I not know of this...

Because... look closely at commit dates ;)
+0 / -0
11 years ago
Aw damn, this means I need to wait for new engine right? Well, it seems the most elegant method, so I guess I'll wait.

If so, and if whichever engine dev god was responsible is reading this, how many goat sacrifices will be needed to get a new call in for the line of sight calculations? =P

Basically allow HaveFreeLineOfFire and TryTarget in Weapon.CPP to be called by LUA scripts.
+0 / -0


11 years ago
quote:
If so, and if whichever engine dev god was responsible is reading this, how many goat sacrifices will be needed to get a new call in for the line of sight calculations? =P

I'd think that maybe fewer than you think, but you have to do it in a properly sacred place.

As in: engine fora, not zk fora.
+0 / -0
11 years ago
I actually did that some time ago. Last year IIRC. It's off the front page of the Feature Requests section now.
+0 / -0


11 years ago
Oh. That happens too i guess, unless you're as vehement in your clamoring as either Smoth or Forb :D

(though getProjectileTarget and setProjectileTarget were clamoring of mine, just snuck in for the ride)
+0 / -0
Ok, I've written it, it tests out with defenders and screamers vs gnats.

v0.1 has been uploaded to repository. Note that it is ENABLED for testing. I don't have time to play games on the test server with it until friday though.

EDIT: this has also been the weirdest gadget/widget I have experienced writing. Not in my experience of making AA micro has the gadget perform worse in a clean testing environment against a noisy "real" environment sim.

Basically, when I try 6 defenders vs 6 gnats:
Parking the gnats in range, give to enemy
- Without anti-bait, 6 shoot 1 gnat x3, reload, repeat
- With anti-bait, same as above, one turret may shoot a different target in the first or third salvo

Parking the gnats out of range, give to enemy, switch to enemy team, move into range
- Without anti-bait, same as above
- With anti-bait, 4 out of 6 gnats down on the third salvo


It appears to be leaky and doesn't prevent all overkills somehow, I'm working on it.
+0 / -0
Skasi
I luv all your work.
+0 / -0
11 years ago
Notes and observations
I think the problem it has with aa built in one clump is that allow target isn't called just before firing but when the target enters range (i suspect it even happens just before!). If the turrets all fire within the ~10frames it takes before allow target is called again, then it can overkill. Hence the gadget works best when preventing overkill from missiles in flight but not before they are fired.

In any case, worst case scenario is a solid row of mts against a tight clump of air units approaching perpendicular, the turrets all fire at nearly the same time virtually negating any effect the gadget has.

Best case scenario is a few scattered chainsaws against bombers approaching from all directions. Each chainsaw is firing more or less independently of the others and has multiple missiles in flight, retargeting when targets have enough missiles happens often and to useful but not overwhelming effect. Cooperative effects, like adding a screamer in the above scenario, also work well, chainsaws don't shoot bombers already "killed" by the screamer.

Guess which one happens more in practice? =D
+0 / -0
Skasi
11 years ago
Does it take bombers "killed" by Screamer#s aoe into account? :P
+0 / -0


11 years ago
You cannot predict which bombers will be killed by AOE due to lag. Just like you cannot guarantee that a shot from ravager kills a specific glaive: the bitches get to dodge.
+0 / -0
Page of 2 (25 records)