[Snippet] Thread

[Nestharus]

This resource has moved here.

--

gone

 

[Troll-Brain]

Mouahahaha i'm wondering where comes this idea

So, set threadSyncer = CreateUnit(Player(0), UNIT_SYNC_ID, 999999, 999999, 0) doesn't work as the same as your code ?

 

[Nestharus]

Troll-Brain, ur idea was a bit different. Actually, it was a lot different. I was struggling to find a way to sync the threads up and the sync selections thing was perfect for that (first got idea from azlier, already well aware of it when u were discussing). As I said myself, the strength of sync selections is that it operates as soon as it is sync'd =).

 

[Troll-Brain]

Well i don't care that much from where the idea is coming or not.
I care much more about the answer of my question (since i can't test it myself).

 

[Nestharus]

It doesn't work the same because the pathing will make it so that the units are side by side rather than on top of each other. You need the SetUnitX/SetUnitY : )

 

[Troll-Brain]

You've tested it, right ?
Not only assuming ?

But that makes sense anyway.

 

[Nestharus]

I know that if you place two units on top of each other, they won't be on top of each other unless u use SetUnitX/SetUnitY because of wc3 auto pathing for create unit and set unit position.

 

[Troll-Brain]

Random suggestion, i've not really thought about it, but instead of a boolean you could use a static real and then use the real variable event.
This way you will know exactly when it will be synced, on event, but maybe it will kill all the purpose of it.

Oh and i would still love a test of my solution, it could be the best option if you only need to sync one or few small integers within a short delay (let's say real case), because the sync time could be the least, it could also be the worst but a test is needed.

 

[Nestharus]

Troll-Brain, I can sync 1200 integers instantly with gamecache. The later ones don't sync uber fast because of wc3 data limit across network set up by Blizzard.

 

[Troll-Brain]

We don't have the same definition of instantly because it's delayed, right ?
If it's not then it's truly awesome, but it can't be.

 

[Nestharus]

The sync booleans using unit selection are delayed as well. They are the exact same speed, the sync boolean just lets you hook in the instant it is sync'd, making it perfect for thread syncing.

 

[Troll-Brain]

I know, but i believe your way is bit more delayed because you're likely to use one more TriggerSyncReady as needed, i mean the loop will be ended a few time after the sync was done.

Now if the delays of unit selections are added rather than be done "at the same time", then it's obvious that my way sucks hard.
But you just can't guess, a test is needed for that.

 

[Nestharus]

Troll-Brain, yours has mass syncs for each integer. It may be viable for syncing booleans, but I think that a near instant sync of 2500 32 bit integers trumps 32*2500 syncs of the same amount of data using unit selections (each sync also having an associated firing trigger). And yes, I am talking about syncing -(2^31) 2500 times >;o, all 32 bits filled rawr.

 

[Troll-Brain]

Troll-Brain, yours has mass syncs for each integer. It may be viable for syncing booleans, but I think that a near instant sync of 2500 32 bit integers trumps 32*2500 syncs of the same amount of data using unit selections (each sync also having an associated firing trigger). And yes, I am talking about syncing -(2^31) 2500 times >;o, all 32 bits filled rawr.

Theroritic cases are so fun, give me a map where you need an "instant" which is not instant at all btw, sync of 2500 integers, and more 32 bits one.

You're not going to convince me until a test is done.
For now i still think that my solution could be the fastest in term of sync time, but yes it should be the least efficient one and it could also be the slowest in term of sync time.

The funny part is that actually i hate my way and love your's, but that doesn't change the fact that a test is needed.

 

[Nestharus]

Just do 80000 unit selections on a unit with a registered trigger and see how long it takes. If it beats 16 seconds (which is what 2500 took), then it wins. If 40000 beats 1.5 seconds (which is what 1250 took, 2500 is slower due to wc3 cap limit on data), then 40000 wins.

And yes, those are recorded numbers. In my tests, I watch the download rate and have a timer running in the background to see how long the complete download takes =). The cap is 60 syncs/second after you do your initial burst (yes, that is recorded as well).

 

[Troll-Brain]

You keep to ignore what i'm saying.

I'm talking about syncing one or only few integers within a short delay (let's call it real case), and check in how much time the sync occurs.
80 000 trigger evaluation is obviously going to lose, it will lag as hell ...

 

[Nestharus]

ok, I'll check out how long it takes for the selection event to fire. From there, I'll check out 80 selection events to see if it does a huge burst or not ^_^. This is ofc given that the one selection event is fast =).

 

[Bribe]

This is how I see your library, without the "Nestharus nonsense"

library Thread /* v1.0.0.0
*************************************************************************************
*
*   This script allows one to sync up threads between players. It is most useful for
*   preventing players from desyncing due to heavy local code blocks as well as syncing
*   up large streams of data.
*
************************************************************************************
*
*   SETTINGS
*/
globals
    /*
    *   This unit can be retrieved from the map attached to this thread. Copy and paste
    *   the unit in the map into target map and then put the unit type id of that unit here.
    */
    private constant integer UNIT_SYNC_ID = 'h001'
endglobals
/*
************************************************************************************
*
*   struct Thread
*
*       readonly boolean synced
*           -   Loop until this is true
*
*       static method create takes nothing returns Thread
*       method destroy takes nothing returns nothing
*
*       method sync takes nothing returns nothing
*           -   Call from local player when that local player's operation is complete
*
*   Examples
*
*       local Thread thread = Thread.create()
* 
*       loop
*           if (GetLocalPlayer() == targetPlayer) then
*               //the hefty operation here should segment how much it does per iteration
*               //too much per iteration and slower computers will desync from the sheer magnitude
*               //of the operation
*               //this will have to be fine tuned based on the size of the operation
*               if (doHeftyOperation()) then
*                   call thread.sync()
*               endif
*           endif
*
*           call TriggerSyncReady()
*           exitwhen thread.synced
*       endloop
*
*       call thread.destroy()
*
*************************************************************************************/
    struct Thread
        private unit threadSyncer
        
        private static trigger syncThreadTrigger
        readonly boolean synced
        
        static method create takes nothing returns thistype
            local thistype this = allocate()
            
            if threadSyncer == null then
                static if LIBRARY_UnitIndexer then
                    set UnitIndexer.enabled = false
                endif
                
                set threadSyncer = CreateUnit(Player(0), UNIT_SYNC_ID, WorldBounds.maxX, WorldBounds.maxY, 0)
                call SetUnitUserData(threadSyncer, this)
                call PauseUnit(threadSyncer, true)
                call SetUnitPosition(threadSyncer, 99999, 99999)
                
                call TriggerRegisterUnitEvent(syncThreadTrigger, threadSyncer, EVENT_UNIT_SELECTED)
                
                static if LIBRARY_UnitIndexer then
                    set UnitIndexer.enabled = true
                endif
            endif
            
            return this
        endmethod
        
        method destroy takes nothing returns nothing
            set synced = false
        
            call deallocate()
        endmethod
        
        /*
        *   Call within a local block
        */
        method sync takes nothing returns nothing
            call SelectUnit(threadSyncer, true)
            call SelectUnit(threadSyncer, false)
        endmethod
        
        private static method syncThread takes nothing returns boolean
            local thistype this = GetUnitUserData(GetTriggerUnit())
            
            set synced = true
            
            return false
        endmethod
        
        /*
        *   Struct Initialization
        */
        private static method onInit takes nothing returns nothing
            set syncThreadTrigger = CreateTrigger()
            call TriggerAddCondition(syncThreadTrigger, Filter(function thistype.syncThread))
        endmethod
    endstruct
endlibrary

 

[Nestharus]

Yea, I'm keeping it as it is.

 

[Troll-Brain]

That wouldn't be Nestharus so, he will never change his mind.

 

[Zwiebelchen]

Hmm, I'm very confused about this resource. I don't quite get why you would need that or even what it exactly does?

Can you give an example situation where this might be useful?

 

[Bribe]

Can you give an example situation where this might be useful?

That wouldn't be Nestharus so, he will never do that.

 

[Nestharus]

Hmm, I'm very confused about this resource. I don't quite get why you would need that or even what it exactly does?

Can you give an example situation where this might be useful?

if you don't know where it would be useful, then you personally have no use for it =)

I already explained where it would be useful in the docs. If you don't understand, go study more JASS =).

 

[MapperMalte]

You seriously need a hobby

 

[Zwiebelchen]

if you don't know where it would be useful, then you personally have no use for it =)

I already explained where it would be useful in the docs. If you don't understand, go study more JASS =).

Wasn't meant as an offense ... I just don't know when you would have "heavy local blocks" that desync... usually all stuff you do locally is fast as hell anyway. Don't know. Maybe its interesting for your external data read stuff. Can't really think of a situation.

 

[Nestharus]

Consider reading 1000 files from a player's hard drive. That player is the only one with those files obviously, so it's a local operation. You also have to process all of that data (120*12 chars per file) and transmit it all. It's an operation large enough to cause op limit if you don't do it properly. It would obviously also cause a desync.

 

[Troll-Brain]

It's funny how you keep to avoid the question.
Basically we are asking for a concrete example of usage.

 

[Nestharus]

It's funny how you keep to avoid the question.
Basically we are asking for a concrete example of usage.

Already answered. Question wasn't avoided.

Not going to waste my time on this any further. I've learned in the past that this all leads to absolutely nothing but hours and hours of pointless debate.

If you don't know what to use it for, don't use it, that's my advice. If you don't like that answer, live with it, cuz that's the only answer you're getting =).

 

[Troll-Brain]

It's not because you are able to sync hundred integers that you will find a concrete usage of it.
So yes, the question was avoided.

Ofc i could be wrong but so far it just seems to be an other resource, just because you can.

 

[Magtheridon96]

The point of this resource is to make the other one more modular.
That's all there is to it.

I only like this one because without it, the Data Sync lib would be more of a monstrosity.

 

[Troll-Brain]

No you don't get it.
Give a map where you would need to sync hundred of integers.

Or in other words when you're doing heavy jass stuff in local block.

 

[Magtheridon96]

Give a map where you would need to sync hundred of integers.

Any ORPG map.
SotP has some hundreds and hundreds of integers that get saved for the user,
so a multiplayer ORPG map with things like Talent tree systems, custom inventories,
custom stats, custom player xp, custom player level, player statistics (like wins,
loses, total playtime), etc... would need hundreds of integers too. Maybe close to
a thousand.

I was working on a map that needed to store all of the above and MUCH more (like
items, abilities, quests complete, quests pending, quests undiscovered, etc...)

 

[Troll-Brain]

Ok, finally an answer.

I don't play that sort of maps, i could explain why, but that would be totally off-topic.

 

[Magtheridon96]

Well, I think this is worthy of an approval.
Any objections?

 

[Bribe]

Code looks o.k. but I am never on battle.net so I cannot test it.

 

[Magtheridon96]

My Warcraft III is pirated, so I can only do tests on Garena.

I guess I'm going to test this as soon as I can contact geries since he's always up for some testing and benchmarking

edit
Oh my God, he sent me a VM directly after I made this post and he was silent for the past few days xD

 

[Nestharus]

There is no need to test this. I have already tested it and use it for perfect data synchronization.

It works.

 

[LeP]

There is no need to test this. I have already tested it and use it for perfect data synchronization.

It works.

lol.

 

[Nestharus]

lol.

???

I used two machines across Garena + got other people to help test. I spent probably 40 hours testing this code and other related code (4 days, all day each day). I tested many, many different scenarios and used users that had both low pings and high pings. We also did things like pausing the game. Furthermore, I also tested this with tons and tons and tons of other synchronizations (100,000+).


The only thing I haven't tested is when a player has 12 units selected. If Mag was going to test something, it'd be that ; ).

 

[Bribe]

It is possible to add a 13th unit to the selection by triggers.

 

[Nestharus]

It is possible to add a 13th unit to the selection by triggers.

Which is what I remember from a long time ago, but I wasn't sure since it was so long, so I didn't mention that.

Given that, there are no problems with this since that was the only thing I didn't test as I assumed that that wasn't an issue ;p.

 

[Magtheridon96]

I like how the attached map has absolutely nothing in it

 

[Nestharus]

It has the unit object..

 

[Magtheridon96]

I was expecting to see some code and something to actually test the system =o
I guess I'll write that myself.

 

[Nestharus]

I was expecting to see some code and something to actually test the system =o
I guess I'll write that myself.

If you wanna waste your time testing something that has already been tested in a hardcore fashion, go for it. You even sat in on a few tests for stuff using this.

 

[Magtheridon96]

Tested.
Working when you select 12 units.
Approved.

 

[Nestharus]

Added thread.wait() and SynchronizeThread()

 

[Magtheridon96]

*   */uses/*
*
*       *  Alloc  *         hiveworkshop.com/forums/jass-resources-412/snippet-alloc-192348/
*       */ WorldBounds /*   hiveworkshop.com/forums/jass-resources-412/snippet-worldbounds-180494/

I think we both know what's wrong here.

 

[Nestharus]

???

Absolutely nothing, for vex's vjass, modules that don't have keywords do not have to be in a library to be used. Only cohadar's does not allow this, so as a result, you can comment out the library usage : ).

This works in vex's

struct Test extends array
    implement I
endstruct
module I
endmodule

 

[Magtheridon96]

But there's no harm in keeping it, I mean, currently, it could cause some confusion (Some people might think you that you commented out the Alloc part because you don't require it in there)