I'm being mathematical about it. I know it's ridiculous to think it would ever happen, but the point is that you want to know your upper limit. If you formulate it so your "acceptable level" is your upper limit you won't have to worry about exceeding your "acceptable level," whereas if your upper limit is a googol kbps, you don't know if you'll exceed your "acceptable level" or not.

(you can blame jK and Licho for putting all this paranoia in me)

Example: some idiot is playing with lua and causes a widget to change his unit selections every frame. Sure it's stupid, but now he's sending tons of data over the network because of your widget. Then poor foreign-joe on his dialup in the 3rd world is lagged out.

There are 32 simulation frames a second, right?

Can it be changed to perhaps only update every fourth frame? 8 updates per second should be plenty. Even updating every 8th frame would probably be more than adequate.

There's a certain amount of communication lag inherent, so even if you update every frame it's not like you're actually going to get a live view of your allies' unit selection.

~~~~

Edit: You mentioned earlier that you weren't getting much of a chance to test your widget. I currently have only v1.7 installed but I just did some simple testing and it's really working perfectly, exactly as I expected and better.

~~~~

Edit: Just tried out 1.9, same story, awesome work. You probably know this by now but you left debug mode on.

Lua messages are guaranteed to go through are they not? So I don't know why there is full refreshes.

One thing you should definitely have is : If adds+removes is greater than the number of units now selected, then just send an instruction to start from scratch and all the unit IDs of current selection.

i.e. If I have 300 units selected, then I switch to just 1 unit, it should just send that 1 unit ID, not 300 removes and 1 add.

This would also remove the need for the periodic full refreshes, as most players would select a small group of units every now and then.

Could do a bunch of optimization for control groups as well.

The first versions worked liked that but I removed it cause I think it makes more sense to send every frame and instead lowering the maxUnitsPerFrame limit (Sure, the header-data/unit-data ratio would get worse, so dont choose a very small value for maxUnitsPerFrame).
I would prefer a steady stream of small chunks every frame over bigger chunks every 8 frames.
But I am not 100% sure about it. If you still want it I will implement it, will be very easy to do anyway.


Yay Thanks. And no: I didnt know about debug mode :/ Its like a bad running gag...

@Niobium:
Great idea, implemented!

Updated to version 2.0...

Can you color code units with orders queued the same way you color code recently used units? Maybe some sort of variable transparency based on the amount of orders queued? Alternately, have the queue display when you select units.

Also, it would be pretty cool to have idle construction units and factories color coded.

This one still crashes from time to time. If someone has an infolog.txt which includes such a crash please post it. Thanks.

@el_matarife:
sorry for late answer, but I am unsure how to code so many different informations just by variing the transparency. Im afraid it would be quite confusing.

Darker ring would mean more orders queued. Anyway, I'd be fine with just some sort of a ring around units with orders queued, and the queue displaying when the unit is selected instead of having to press shift. Idle construction unit and factory highlight would be really nice too.

Well, changing the color to a darker one would clash with other players who use that color.
One option would be to use a second circle/pentagon for indicating queues or drop the "hot-units" feature and use the transparency to indicate queues.

Excuse me, by "darker" I meant "More opaque". The second circle or pentagon or star would be fine actually. Maybe a star for queued orders, pentagon for idle?