Ally Selected Units

[very_bad_soldier]

You basically have to use CommandsChanged if you want a callin for when the selection changes.

Awesome, thanks! Makes things much more efficient.
Added to wiki btw...

Interesting idea but yes this could end up with strange errors if something goes wrong.

How about this: Maybe the best of both worlds: Send only differences but send, lets say, every 10 seconds a full update?

Here is a small update. Still not tested by me . Any bug reports are very welcome.
What changed:
-Units selected by teammates are locked (cannot be selected by yourself)
-Callin driven (less cpu load)
-Sends max 300 (is it too much?) units per update interval (100ms atm). If more has changed, it gets split up over multiple frames.
-Sends full refresh every 10 seconds
-"Hot" units: Units that received a command in the last 7 seconds (customizable) will get a red circle which fades away within those 7 seconds.

One thing:
I assume the callin "UnitCommand" is also called when a teammate gives a command? The "Hot"-unit stuff wont work if thats not true. Maybe someone who knows for sure about it can tell.

[Niobium]

One thing:
I assume the callin "UnitCommand" is also called when a teammate gives a command? The "Hot"-unit stuff wont work if thats not true. Maybe someone who knows for sure about it can tell.

Yes, it will. It gets called for every command that is successfully issued. Including those done by widgets, so your widget would mark AutoSkirm'ing widgets as hot.

[Caydr]

So far I've only tested your previous version (1.4?) and I had no problems that weren't related to my secondary testing computer being a netbook...

[very_bad_soldier]

Nice to hear. Still hoping to try it out myself someday

Another version:
How about this? Hot units stuff is not anymore about units that received a command lately but rather units that were selected lately.
So a unit will be "hot" for 7 seconds as soon as a teammate deselects it. You will know then that this unit has been "used" recently.

Or is this whole "hot"-unit concept of no use??

[Caydr]

I think the "hot" concept is very interesting, it isn't hard to think of ways it would be useful. You said it would render in red, right? Personally I would probably set it to be the same color as normal, just fade out. Or maybe have it immediately jump to 70% transparency as soon as it's deselected. If you just want to test the widget we can have a compstomp in BA or your mod of choice if you want.

Sorry for my ignorance of such things, but would it be possible for you to make units selected by allies displayed as well? If possible, in another color.

[very_bad_soldier]

I think I like the idea. Here is a try of implementation (did I mention already that its untested??):
-units selected by allies get a triangle (instead of a circle, to distinguish from coop-selection) in team color
-"hot"-units keep the color but instantly go to 50% transparency

PS.
Renamed to "Allied Selected Units" (if you search it in the widget list ingame) for the moment.

[KaiserJ]

not sure if this goes here, but for those mega co-op games, it would be pretty awesome to have allycursors display the name of the player the cursor belongs to somehow.

[CarRepairer]

Sorry for my ignorance of such things, but would it be possible for you to make units selected by allies displayed as well? If possible, in another color.

Yes it's possible and you'd know that if you read the thread.

[very_bad_soldier]

Sorry for my ignorance of such things, but would it be possible for you to make units selected by allies displayed as well? If possible, in another color.

Yes it's possible and you'd know that if you read the thread.

Erm, I implemented that just yesterday. Before it was only meant for units selected my coop-teammates.

@KaiserJ:
Would be nice indeed. AlliedCursors is jk's widget. Maybe display the names only when META (Space) is pressed? Maybe I will give it a try by myself...

[CarRepairer]

Sorry for my ignorance of such things, but would it be possible for you to make units selected by allies displayed as well? If possible, in another color.

Yes it's possible and you'd know that if you read the thread.

Erm, I implemented that just yesterday. Before it was only meant for units selected my coop-teammates.

@KaiserJ:
Would be nice indeed. AlliedCursors is jk's widget. Maybe display the names only when META (Space) is pressed? Maybe I will give it a try by myself...

But the way he said it was as though I'm invisible, when I stated I had already done it months ago

[very_bad_soldier]

@KaiserJ:
I gave the AllyCursors a try (is in SpringDownloader). Press META to show player names.
I hope jK wont cut me in pieces for it...

The good thing is: I have found jK's magical secret function for CPU culling in it and added it to various widgets of mine (speeding stuff up noticable).
I dont want to update each thread for it, but there are new versions of:
DefenseRange, AllySelectedUnits, GhostSite (+fixed buildings in progress) and GhostRadar.

@CarRepairer:
Yeah sorry, I didnt want to redo yours and make it needless or something. But I could only find the sending side (selectionends.lua). I could not find the stuff where the selected units get actually marked. Maybe we can still merge our code together to make one uberversion?

[very_bad_soldier]

updated...

[very_bad_soldier]

updated...

[Licho]

Selected ally units are visible in selectioncircles2 and selectionhalos2.

If possible use same sending part so that they are compatible :)

[CarRepairer]

Yeah I've been over it with him. But he's sending every unit (possibly 700-800) and I'm sending max 10. He's sending every 100ms and I'm sending every 1s. Also his accounts coop mode in BA by showing difference for people on the same "Team" vs. people on the same "Allyteam."

[very_bad_soldier]

Hm... AFAIK the CA-sending-method relies on regularly sending the complete selection information up to 10 units (and receiving so). Mine only sends differences when the selection changed (and full updates every 10 seconds), which is hopefully quite bandwidth efficient.
And I added zip-functionality from the current spring Lua API for message payload >130 bytes.
So I dont think there is an easy way to make them compatible.

@Car:
Its a bit different: Its callin-driven, I will only send when selected units changed. So I will even send every frame if you manage to change your selection every frame (but I doubt) :)
But I dont send more than 300 units per frame (600 bytes). If there is more it will be split up across multiple frames.

[Caydr]

I think most peoples' connection can handle that... Mods in general are/need to be optimized not to require so many units on a regular basis anyway, for obvious performance reasons.

I mean, almost any computer can handle 300 units, but not necessarily 300 units trying to pathfind around one another.

That said, this is probably the most bandwidth-intensive widget I'll be including in AA so I'm curious, now that you've implemented zlib compression have you done any testing to see how much bandwidth is saved?

Like, before/after... anything like that? I'm just curious.

[CarRepairer]

@Car:
Its a bit different: Its callin-driven, I will only send when selected units changed.

How? If selectionchanged is broken...

So I will even send every frame if you manage to change your selection every frame (but I doubt) :)

I did this at first too, but I changed it to prevent it. My advice to you is don't assume anything

But I dont send more than 300 units per frame (600 bytes)

600bytes + lua header(I think jK said it's approx 14 bytes but not sure) per frame.
that's (600+h)*32 = 19,200+32h b/s
So your upper limit is over 19.5 kbps upload.
In an 8 player game that's an upper limit of 153kbps download.

I realize upper limit is nearly impossible, but it can show you close to what you could reach.

[aegis]

why not send things like "selected box x, y, width, height" or "selected all units of type X" or "selected all units"?

should apply to all units selected by natural means, and will never use very much data...

though the select box command would only work if long as the sim state was identical on the target computer when it received the command as the sending machine's when the command was sent...

can possibly do unitid ranges, exclusions, and custom compression techniques too...

[very_bad_soldier]

That said, this is probably the most bandwidth-intensive widget I'll be including in AA so I'm curious, now that you've implemented zlib compression have you done any testing to see how much bandwidth is saved?

Like, before/after... anything like that? I'm just curious.

I know I should have but I didnt. Since there is no way to tweak it anyway I am just happy about every bit I save. Maybe I will do it at some time since I am curious too...

@Car:
Its a bit different: Its callin-driven, I will only send when selected units changed.

How? If selectionchanged is broken...

By using CommandsChanged... Hint from Evil4Zerggin here in the thread.

600bytes + lua header(I think jK said it's approx 14 bytes but not sure) per frame.
that's (600+h)*32 = 19,200+32h b/s
So your upper limit is over 19.5 kbps upload.
In an 8 player game that's an upper limit of 153kbps download.

I realize upper limit is nearly impossible, but it can show you close to what you could reach.

Common Car, thats not exactly fair. Sure thats the theoretical upper limit. But isnt it a bit toooo far off? 8 players selecting 300 different units 32 times per second
I would tend to say: There are no players who would change their whole unit selection (300 units) more than three times per second. I would even say that this is already a worst-case assumption (8 players at the same time?).
But dont get me wrong: I dont want to "defend" that 300 units-per-frame limit. It was just arbitrary. Maybe its really too much and should be lowered, I have absolutely no problem with it. I just would want to base it on a more realisitic measurement/experience.

Anyone who is afraid of the bandwidth usage can lower

local unitLimitPerFrame = 300

to a more suited value. I will do too as soon as I am conviced that it caused a single lag in real game environment.