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

Attrition counter widget for teams! (zomg)

28 posts, 2422 views
Post comment
Filter:    Player:  
Page of 2 (28 records)
sort
I've made a little thing that counts casualties and confirmed (in-los, or identified radar blobs) kills and their metal value for 1x1 games.

It currently has some limitations and bugs, or WHAT IT DOES WRONG:

- Any loss of enemy unit is considered your kill, because i can't access this information via sync and kills are detected as "units that entered LOS and then stopped existing without leaving los". (and it is politically impossible to get that info from synced because everybody would just start bertha scouting, i hear). Enemy decides to selfd? Your win. Falls off cliff? Your win. Death by lava? All increases your score.

(fairly legit for 1v1, and doing all those things to yourself will naturally include your own casualty count)

- Some false positives might be listed when a nanoframe is insta-recycled by a factory. Don't know how to fix that.

- It doesn't tolerate luaui reloads too well. All scores will be lost on luaui reload.

- It doesn't respond to changes in spectator state, or in spectate-team, and doesn't display which player "you" are.

- It will not work for team games (because all kills would be counted as yours, including ally casualties). Therefore it disables itself the moment you are discovered to have an ally.

- In FFA, it files every dead unit as something that you killed personally, so is fairly meaningless.

WHAT IT DOES RIGHT:
- It allows you to see at a glimpse if you are failing too bad at tactics and wasting your units to no good.
- It displays a percentage:
- grey N/A when no kills and no losses
- blue PWN! if you're doing the other guy with no losses at all
- green if attrition rate over 100%
- yellow if rate over 75%
- orange if rate over 50%
- red if you're getting massacred two-to one or worse

WHAT IT COULD DO BUT DOESNT BECAUSE I'M A LAZY BASTARD:
- It doesn't declare IMPRESSIVE EXCELLENT HUMILIATION and flash red/green signs when your attrition rate climbs or falls over significant margins.
- Spectator support.

TL:DR https://dl.dropbox.com/u/19320633/attrition.lua
+3 / -0
quote:
Some valid casualties might not be counted because there is no reliable way of determining "casualties" that happen because of morph gadget, and an unreliable hax has to be used. It's somewhat effective when detecting commander morphs, but when applied to all and any units, it can suck.

Btw if anybody has better ideas on how to bypass this, or will bother to reopen the issue for reporting of morphs via rulesparams (closed as wontfix because "engine bug"!), you're welcome.
+0 / -0
11 years ago
What exactly do you mean with "Attrition?" this widget counts how much metal you have destroyed?
+0 / -0
How much you destroyed and how much you lost, in individual units and metal value. To precision allowed you your LOS and assorted bugs and such.

Another possible feature would be to display the relation between those, but i'd rather get it to work accurately first in spite of morphs and such.

On that: i've tried intercepting MorphFinished by doing widgetHandler:RegisterGlobal('MorphFinished', MorphFinished) like the healthbar widget does. But it seems consumed by whoever registers first, and healthbars exposes no way to retrieve that information either - so that path can't work in a non-breaking fashion :(
+0 / -0
11 years ago
Sounds good
+0 / -0
Anarchid, are you sure this widget is detecting Wreckage? because I see here that you detecting units using GetUnitInRectangle(), but wreckage is a "feature" (like trees and rock, and is detected using GetFeatureInRectangle() and such).

I has experience :)
I made this widget: http://springfiles.com/spring/lua-scripts/unit-losses-counter-enemyallyself

P/S: this may explain why you had that strange feeling of missing some unit
+0 / -0
I'm pretty certain it detects corpses, yes. In fact, it seems it also gets UnitDestroyed when said corpses are destroyed, at least in spec mode.

The hax is also pretty much copied from unit_marker.lua, for which the same trick seems to work.

Are corpses units in zk?
+0 / -0
11 years ago
THis is really strange!
+0 / -0


11 years ago
Alas! The wise and mighty King Raptor has overruled his ignorant subjects, and the UnitRulesParam is now in place!

Once next zk is out, i'll patch this up to work properly, with just one hax left (for kills of enemy units)
+0 / -0
11 years ago
Corpse are feature and not unit. If you use get feature then you can detect corpse, I am sure.
+0 / -0


11 years ago
quote:
Corpse are feature and not unit. If you use get feature then you can detect corpse, I am sure.

But then why does it work for unit_morph now? Your logic is convincing, after all units and features are different things. But it doesn't explain current behaviour.
+0 / -0
unit_morph does not make corpses. It make new unit, that's why getUnitInRectangle work. When you morph unit, that unit is pulverized and recreated into new form.

Corpse is really is a feature. You can only get corpse when using getFeature. And when you get corpse, its name contain word like "debris" and "wreckage".
+0 / -0
quote:
unit_morph does not make corpses. It make new unit, that's why getUnitInRectangle work.

That's what i thought it did. But then i looked again, and guess what? 1 unit in rectangle? Unit is dead. 0 units in rectangle? It's a morph. Corpses on morphed unit? Nah, dead again. Don't ask me.

quote:
You can only get corpse when using getFeature.

But it (unit_marker.lua) checks for absence of units in rectangle to validate a morph, not for presence of a new unit, and this works.

(i know the logic is warped, but evidence insists that works!)

Also, you can try to morph a commander with current version of my widget, and it will not report com as a casualty, while it will report any unit that leaves a corpse - as dead.

I do "know" that corpse should be a feature, not a unit, but that does not explain why the current code works (to an extent, for units that die with corpse). And since it does not explain this behaviour, the statement is either incomplete or otherwise erroneous.

Possibly UnitDestroyed also gets fired for features? Or maybe corpse features are also units during the first frame after their createon? :X

Now, this is all hardly relevant, as there's a proper fix on the horizon, but it's still interesting.
+0 / -0
11 years ago
k, after testing this what I got:
using GetUnitRectangle
1 unit die -> detected 1 unitID, unitID same as the destroyed unit.
1 unit morph -> detected 1 unitID, unitID different than the destroyed unit.

using GetFeatureRectangle
1 unit die -> detected 0 feature when destroyed unit.
+0 / -0
Presumably the wreck hasn't been created yet when UnitDestroyed is called.
+0 / -0
There is the stats page after every game ended. There you can see stats for all players how much metal earned, destroyed etc... maybe you can use sth from that? So you don't need to invent things which are already there?! Or should it be a "live widget"?
+0 / -0


11 years ago
quote:
Or should it be a "live widget"?

Precisely. Gameover stats cannot influence your decisions in process of game.
+0 / -0

11 years ago
Okay. But maybe you can use those routines so you don't need to invent it new?
+0 / -0
quote:
Okay. But maybe you can use those routines so you don't need to invent it new?

Nope, they run on synced. It is technically possible to make something in synced that would report kills to widget-space, but that would allow for bertha scouting and such, which is totally cheating.
+0 / -0


11 years ago
Yay! New zk has fix for ugly hax, so here's a version that is a bit more accurate:

MAH WUPGET
+0 / -0
Page of 2 (28 records)