SC2Mapster

I made pseudo control group hotkeys.

Deselect then Select

But the response time is giving me a pretty game breaking bug.

[1] is for a single unit [2] is army select, excluding the unit from [1]

Works fine slowly but when switching quickly, the command such as move or attack will be carried out by the previous hotkey.

For example, I have [1] selected then select [2] quickly then do the attack move command, [1] will do the command how would I fix this?

Any help appreciated, thanks.

can you give some implementation detail of your triggers?

Quote from FunkyUserName: Go

can you give some implementation detail of your triggers?

Event - Key Pressed

Conditions - Key 1 or Key 2

Actions:

If

Key 1

Then

Deselect all units

Select Unit1 units in entire map-

Skip remaining actions

If

Key 2

Then

Deselect all units

Select Unit2 units in entire map-

Select Unit3 units in entire map-

Select Unit4 units in entire map-

Skip remaining actions

Thats all. ;(

do you recalculate the unitgroup every iteration or do you keep track of the unitgroups and just select the units from a variable?
btw for cleaner code: if there are just 2 keys, put all in one if then else, otherwise use a switch construct. the skip remaining actions is then not needed because there is nothing to skip.

@FunkyUserName: Go

I just took the first two keys for example, I actually have quite a few.

Would using variables fix my problem?

i don't know but it would speed up the whole process (which might be the problem).
you could try to have only 2 units on the map (maybe 3 for attack order) and test if your bug still occurs.

Quote from FunkyUserName: Go

i don't know but it would speed up the whole process (which might be the problem). you could try to have only 2 units on the map (maybe 3 for attack order) and test if your bug still occurs.

ok I did as you said, but the huge delay is still severe (unchanged).

It's not noticeable in a test document, but on bnet its really bad.

The problem is due to physics quite literally.

The event "Key Pressed" requires synchronizing the input key with the server. Because the BattleNet 2.0 servers (the host servers) are located far away for most players (anywhere from 100s to 1,000s of kilometres away) this takes a considerable length of time. This is because data can only be sent slower than the speed of light (usually 1/3 of the speed of light or less as network hops have processing delay) so any distance results in a time and big distances result in more time. It works in the editor because the host server is built-in so has as good as 0 latency.

Since this is a physical limitation there is currently no possibility to fix it (you would need to be able to warp reality to do so and I doubt you would be playing SC2 if you could). As such you need to build around such latency.

In your case the only solution would be to either use the existing "local" groups functionality which needs no synchronization (you can modify units in the control groups) or to abstract orders with some input latency dependent system. The first solution fixes it by removing latency to change groups. The second solution fixes it by abstracting the order from the units to a generic command which affects what ever control group you have selected.

Quote from Forge_User_04585675: Go

The problem is due to physics quite literally.

The event "Key Pressed" requires synchronizing the input key with the server. Because the BattleNet 2.0 servers (the host servers) are located far away for most players (anywhere from 100s to 1,000s of kilometres away) this takes a considerable length of time. This is because data can only be sent slower than the speed of light (usually 1/3 of the speed of light or less as network hops have processing delay) so any distance results in a time and big distances result in more time. It works in the editor because the host server is built-in so has as good as 0 latency.

Since this is a physical limitation there is currently no possibility to fix it (you would need to be able to warp reality to do so and I doubt you would be playing SC2 if you could). As such you need to build around such latency.

In your case the only solution would be to either use the existing "local" groups functionality which needs no synchronization (you can modify units in the control groups) or to abstract orders with some input latency dependent system. The first solution fixes it by removing latency to change groups. The second solution fixes it by abstracting the order from the units to a generic command which affects what ever control group you have selected.

Oh thanks thats quite informative, now I have a better understanding of how this stuff works. Wish I really could warp reality though. I did eventually return to control groups for the better. Actually made it look nicer than before, but it does suck there is that limitation.

Thanks again for information.

Quote:

I highly doubt that the speed of light issue is the same issue you are having. 1/3rd the speed of light is still 100,000 km/s. While Yes, there is an input delay that cannot be avoided, for that delay to be long enough for commands given to be given to a wrong unit group; that just seems like way to much delay.

Ping their server IP with tracert and see. Latency from UK to US should be about 100 ms. Latency from UK to EU about 30 ms. A frame is 62 ms. so throw in computation and you have at least 2 deterministic frame delay. Hence enough for the problem.

Quote:

More than likely it has to do with the triggers in your map, unit count, and other latency-causing problems which are delaying the process. Things like trigger errors can slow the entire process down. You can test your map with the trigger debugger open just to see if maybe there is a lot going on when you use those hotkeys; and maybe find a heavy trigger somewhere.

They do not add latency. They can cause frame drops or slow game speed down in extreme cases. Also the debugger results are not accurate, the times reported include the debugger overhead so are much larger than without the debugger.