GetLocalPlayer~

[defskull]

Does this causes desync ?

• Actions
  • Set UnitType = No unit-type
  • Custom script: if GetLocalPlayer() == Player(1) then
  • Set UnitType = Paladin
  • Custom script: endif
  • Unit - Create 1 UnitType for Player 2 (Blue) at (Center of (Playable map area)) facing Default building facing degrees
  • Hero - Create Claws of Attack +15 and give it to (Last created unit)
  • Hero - Drop (Last created item) from (Last created unit)

Basically I wanna do a personal storage service that will only appear to the player only.
Each player has their own personal storage, and other player can't see others' storage.

What I did was, creating unit separately from all player, each having their own storage, and the item is stored inside the storage.

Now, the unit is indeed affected by GetLocalPlayer but the item does not.
So, does this causes desync ?

I've tested the trigger above, and yes, you can't see Player 2's Paladin but an item is dropped, meaning that the unit can't be seen but the item is there to be stored.

 

[Tom_Almighty1]

Maybe its because you put that trigger:

Hero - Drop (Last created item) from (Last created unit)

Did you put that on purpose?

 

[TriggerHappy]

I can see it desyncing, however if it's not interacted with then maybe not.

 

[Adiktuz]

Well, item create for unit does still work even for a null unit... or maybe because ur the first player on the loop, so technically there is a valid Last Created Unit...

If you don't want the item to be created too, why not set the item type using the local player block like what you did with the unit type?

though yeah, that might desync

or you can also just check if Paladin has a value, if yes, create item, if not, don't create

PS: though why create them locally?

 

[defskull]

It's not a statement, it's a question, guys @@

I want to know does this approach causes desync ?
And perhaps some detailed explanation on why it does not desync.

Maybe its because you put that trigger:

Hero - Drop (Last created item) from (Last created unit)

Did you put that on purpose?

It's for testing purpose, to know whether a unit affected by GetLocalPlayer can still interact with item that is not affected by it - and it does works.

I can see it desyncing, however if it's not interacted with then maybe not.

What do you meant by "not interacted" ?
If Player A only interact with Storage A, it does not have a problem, right ?

Even so, if Player B interact with item from Storage A (after Storage A has put down the item), I don't think it causes desync because originally, the item is not affected by GLP function.

Well, item create for unit does still work even for a null unit... or maybe because ur the first player on the loop, so technically there is a valid Last Created Unit...

If you don't want the item to be created too, why not set the item type using the local player block like what you did with the unit type?

though yeah, that might desync

or you can also just check if Paladin has a value, if yes, create item, if not, don't create

PS: though why create them locally?

I just want to know either these approach desyncs the game or not - for a long period of time, let's say 30 ~ 60 minutes of gameplay.

I created them locally because I want only Player A can see Storage A, and Player B sees Storage B, and so on.

You own like a personal storage area for you only, others can't access it.

But in the end, the item is needed to be shared by all (other Players can see/acquire/break/interact with the items), only has different way to access it (which is the Personal Storage Area).

 

[Adiktuz]

I think it might be better to just hide/show locally than creating locally

 

[Zwiebelchen]

You can not create any objects that create net traffic locally.
Only purely visual things can be local.

In order to create a personal storage, create one unit for every player, then use Vertex coloring and Unit Scale locally to make them invisible for other players (The scale and vertex color are purely visual and do not affect net traffic, hence it works).
Note that other players can still box-select units made invisible and unclickable like that.
You can avoid that by placing all storages at the same place. That way, when players try to box-select the storage, it will always select their own, as box-selection will always prioritize player units over allied units.

 

[PurgeandFire]

AFAIK the tactic of locally switching the ID only works in very specific cases: when they differ in nothing but rawcode ID and visual details (e.g. model, icon, etc.) but have the same vision, collision, etc. I haven't personally tested it, this is just from memory of what someone said before, so I could be wrong.

Regardless, you have to be very strict about the interactions and what not, and be careful with events. It may be more trouble than its worth.