[Trigger] GetLocalPlayer disconnects... WHY?

[SupremeGrandRuler]

For some reason, this disconnects other players. Not sure why.

• Custom script: if GetLocalPlayer() != GetOwningPlayer(GetTriggerUnit()) then
• Animation - Change (Last created unit)'s vertex coloring to (100.00%, 100.00%, 100.00%) with 100.00% transparency
• Custom script: endif

EDIT: Fixed.

 

[defskull]

Eventhough I see the words fixed there, this is how you should solve the problem;

• Actions
  • Set TransparencyValue = 0.00
  • Custom script: if GetLocalPlayer() != GetTriggerPlayer() then
  • Set TransparencyValue = 100.00
  • Custom script: endif
  • Animation - Change (Last created unit)'s vertex coloring to (100.00%, 100.00%, 100.00%) with TransparencyValue% transparency

This way, you are creating the actions outside the GetLocalPlayer block, which will never cause a desync.

What you did was creating handles/actions inside the GetLocalPlayer, which possibly could create 2 split servers each time you repeat that action.
Remember, each time.
Imagine if you have repeat that trigger for at least 10 times ?
It would create a possible of 20 split servers, that's why desync occurs.

But by following this method, it would never cause a desync because you actually create the handles/actions outside the GetLocalPlayer which does not create split server.

Only selected player(s) will get the values inside the GetLocalPlayer block.
Note, setting variables inside GetLocalPlayer does not create a split server, that is why it is safe.

Method Explanation:
1. First, you set 0.00 values for all Players.
2. When you go inside the GetLocalPlayer block, only selected player(s) will get the new set values which are 100.00
3. When you exit the GetLocalPlayer block, simply use the action.
4. Remember, all players initially sets value to 0.00, only player(s) inside the block will get 100.00
5. Which in this case, GetOwningPlayer(GetTriggerUnit()) -> GetTriggerPlayer() gets the 0.00 value, while other player other than GetTriggerPlayer() will get the value 100.00.

 

[SupremeGrandRuler]

Eventhough I see the words fixed there, this is how you should solve the problem;

• Actions
  • Set TransparencyValue = 0.00
  • Custom script: if GetLocalPlayer() != GetTriggerPlayer() then
  • Set TransparencyValue = 100.00
  • Custom script: endif
  • Animation - Change (Last created unit)'s vertex coloring to (100.00%, 100.00%, 100.00%) with TransparencyValue% transparency

This way, you are creating the actions outside the GetLocalPlayer block, which will never cause a desync.

What you did was creating handles/actions inside the GetLocalPlayer, which possibly could create 2 split servers each time you repeat that action.
Remember, each time.
Imagine if you have repeat that trigger for at least 10 times ?
It would create a possible of 20 split servers, that's why desync occurs.

But by following this method, it would never cause a desync because you actually create the handles/actions outside the GetLocalPlayer which does not create split server.

Only selected player(s) will get the values inside the GetLocalPlayer block.
Note, setting variables inside GetLocalPlayer does not create a split server, that is why it is safe.

Method Explanation:
1. First, you set 0.00 values for all Players.
2. When you go inside the GetLocalPlayer block, only selected player(s) will get the new set values which are 100.00
3. When you exit the GetLocalPlayer block, simply use the action.
4. Remember, all players initially sets value to 0.00, only player(s) inside the block will get 100.00
5. Which in this case, GetOwningPlayer(GetTriggerUnit()) -> GetTriggerPlayer() gets the 0.00 value, while other player other than GetTriggerPlayer() will get the value 100.00.

Thanks, great explanation

 

[Troll-Brain]

But the first code shoudn't desync, setting unit color in a local block should be safe, are you sure it is fixed ?!

 

[defskull]

But the first code shoudn't desync, setting unit color in a local block should be safe, are you sure it is fixed ?!

Yeah, but it is better safe than sorry

Although just set the unit color does not even create a handle.

 

[Troll-Brain]

My point is that unless there is a bug with this function or is there is some crazy GUI stuff involved, it shouldn't desyn if it's used in a local block.
Hell, iirc we even don't have any function to get how a unit color is setted, so it should be 100 % safe.

So the desync problem is probably somewhere else, you even don't have to use GetLocalPlayer to make a desync, some datas are already localized, such as cameras.

 

[defskull]

Yeah that's why it rises a question too, that action does not create a handle, how come it can desync ?

And Supreme, how can you be so sure that trigger is causing the desync ?

 

[Troll-Brain]

You don't need to create an handle to make a desync, but actually, as said it shouldn't desync in the first place.
(or there is a vJass hook on this function or whatever, but i'm not even sure that a TriggerEvaluate in a local block could make a desync, i've never tested it)

 

[Fingolfin]

What you did was creating handles/actions inside the GetLocalPlayer, which possibly could create 2 split servers each time you repeat that action.
Remember, each time.
Imagine if you have repeat that trigger for at least 10 times ?
It would create a possible of 20 split servers, that's why desync occurs.

I think this is a misleading way of explaining it. First of all, you can ofcourse not have more than one split server per player, so 12 would be max. A server split occurs when some data in one (or several) players game differ from that of the others. If a local block fires when GetLocalPlayer() == Player(0), than this can only ever cause player 1 to split from the others. If it fires when GetLocalPlayer() == Player(0) or Player(1), it might cause player 1 and 2 to split onto their own server part from the others.

 

[edo494]

its most likely not in the code,

function SetUnitVertexColorBJ takes unit whichUnit, real red, real green, real blue, real transparency returns nothing
    call SetUnitVertexColor(whichUnit, PercentTo255(red), PercentTo255(green), PercentTo255(blue), PercentTo255(100.0-transparency))
endfunction

function PercentTo255 takes real percentage returns integer
    return PercentToInt(percentage, 255)
endfunction

function PercentToInt takes real percentage, integer max returns integer
    local integer result = R2I(percentage * I2R(max) * 0.01)

    if (result < 0) then
        set result = 0
    elseif (result > max) then
        set result = max
    endif

    return result
endfunction

nothing potencionally causing desync

 

[WaterKnight]

This way, you are creating the actions outside the GetLocalPlayer block, which will never cause a desync.

But by following this method, it would never cause a desync because you actually create the handles/actions outside the GetLocalPlayer which does not create split server.

Again, that is not true. Setting a variable is also some kind of action. Even if you only set the variable in the local block, you can cause a desync in case you use this async variable afterwards in a matter that should be sync.

set boolVar = false

if (GetLocalPlayer() == Player(0)) then
    set boolVar = not boolVar
endif

call PauseGame(boolVar)

desyncs.

 

[SupremeGrandRuler]

Yes the problem was I was adding creating a special effect inside a local player block that I didn't see in another trigger that happened at the same time.

 

[Fingolfin]

A good idea to solve that is to use a string variable for the path and set it as an empty string in a local block for the players who aren't supposed to see it (and as the model path for those who are), and then create the effect for everyone, using the path variable.