System GetDelay

[Steel]

Unless you code in some usefulness for this in an actual map, left to their own devices, others won't be able to use this on their own. I can't think of a practical application for this in any way ever. Not only is it inaccurate because it bases delay off of tracking a unit which is even more inaccurate. It doesn't track things in a quick enough interval to be accurate enough to compete with a millisecond comparison in latency.

 

[Jesus4Lyf]

It's the sort of thing you put in a multiboard so you can read it from one game to the next to compare your connectivity to hosts?

 

[Dr.Jack]

Seems to me that plenty of things can affect the outcome.
Can you show us a test that proves this is accurate/reliable?

 

[Jesus4Lyf]

As a player and mapper, sometimes all I want is a way to vaguely compare one host to another. Regardless of the accuracy of this, as long as it returns a higher value for laggier connections, this is amazing.

And I've approved this. The research behind this is too good to lose, regardless. I'm nearly certain I will be implementing this in my maps. But, if we find this to be unaccurate in a makes-this-useless way in the future, we will unapprove this.

Also, you should discuss the "private constant integer DUMMYID = 'h004'" line in implementation. That's a custom unit id which doesn't usually exist, no?

 

[cleeezzz]

thanks

updated 1.0c

1.0c

• System now creates a universal dummy that is reused. It is shown and hidden to prevent players from selecting it when not checking delay. (NO desync in multiplayer, Tested)
• Added Detail to implementation about dummy unit

 

[Jesus4Lyf]

Hm. I meant here:

//  How to import:
//         - Create a trigger named GetDelay.
//         - Convert it to custom text and replace the whole trigger text with this.

But good stuff.

 

[Karawasa]

I also don't see much (if any) practical use for this. It's cool, but what are you really going to do with it.

 

[Jesus4Lyf]

I'm playing Element TD right now ironically, and I was just thinking how awesome this would be in the multiboard because sometimes I lag 5 minutes back in time towards the end. :thup:

(Seriously, that isn't exaggerating at all. My laptop is really old and my game finishes 5-10 mins after my friends'.)

 

[Jesus4Lyf]

Hmm. You should make the calculate delay function private, and call it every time a delay calculation finishes completely.

So in other words, it calculates the delay, and when the last player returns a value (or disappears from the game) it calls it again... :thup:

 

[cleeezzz]

mm sounds good, although ive only noticed this recently in my archer wars map but while im aiming my arrows and any point target skill, the UI will be cancelled because of the selection.

so i think i need to make an update to make sure the player isn't doing anything currently + check delay for an individual player rather than all of them.

 

[Trollvottel]

couldnt you write a GetHost function using this (if it really works, the host always has the smallest delay)?

 

[Jesus4Lyf]

couldnt you write a GetHost function using this (if it really works, the host always has the smallest delay)?

That's the idea kinda. It'd be more reliable than the gamecache stuff, in theory.

 

[Troll-Brain]

Theories are good.
Facts are awesome.

gogo test !

 

[Jesus4Lyf]

I have very limited time spent with actual WC3 these days, but I'll say this:

I know for a fact (tested) that the gamecache synch method is unreliable (even with multiple calls and taking the average).
I have heard that using unit selection is reliable. :thup:

So this would be the same as using unit selection for get host.

 

[Azlier]

I am a magician when it comes to untested stuff. This doesn't even need GetDelay.

library GetHost initializer Init

globals
    private unit U
    private player Host = null
    private trigger t = CreateTrigger()
endglobals

constant function GetHost takes nothing returns player
    return Host
endfunction

private function Click takes nothing returns boolean
    set Host = GetTriggerPlayer()
    call DestroyTrigger(t)
    call RemoveUnit(U)
    set t = null
    set U = null
    call DestroyBoolExpr(Filter(function Click))
    return false
endfunction

private function Init takes nothing returns nothing
    set U = CreateUnit(Player(15), 'hfoo', 10000, 10000, 270)
    call PauseUnit(U, true)
    call TriggerRegisterUnitEvent(t, U, EVENT_UNIT_SELECTED)
    call TriggerAddCondition(t, Condition(function Click))
    call SelectUnit(U, true)
endfunction

endlibrary

 

[Jesus4Lyf]

Surely that desynchs for Macs? Or something.
Just compare if Host != null... Don't destroy it...

 

[Azlier]

Destroying a boolexpr within itself is quite fishy, I admit. I wonder if anything really happens there.

Comment it out, if you want. It'll work fine without it.

 

[Jesus4Lyf]

Bleh.
>[LJASS]call DestroyTrigger(t)[/LJASS]
I don't trust that either. The trigger may be about to fire (if the event has already passed).

I'd wait for 60 seconds and destroy it from the init. (Because you might lag window for that long also.)

I'd also make the selection occur 0 sec into the game, probably. Not on init.

 

[Azlier]

Selection, believe it or not, works fine on Init.

And yes, the trigger is about to fire. Eleven more times. Genius I am.

 

[Jesus4Lyf]

private function Click takes nothing returns boolean
    set Host = GetTriggerPlayer()
    call DestroyTrigger(t)
    call RemoveUnit(U)
    set t = null
    set U = null
    call DestroyBoolExpr(Filter(function Click))
    return false
endfunction

-->

private function Click takes nothing returns boolean
    if Host==null then
        set Host = GetTriggerPlayer()
    endif
    return false
endfunction

Everything else should revolve around that (my opinion).