Whoa, that is awesome, thank you for the solution. I read through your tutorial.
I think GetLocalPlayer will be a reasonable solution, I simply want to use it to discover/complete quests as well as locally update quest requirements for each player.
My only question now is: Would I still need quest arrays? Suppose 2 players are working on the same gather type of quest but Player(0) has gathered 6/10 metal ores, and Player(1) has only gathered 2/10 metal ores. My quest system simply displays a quest update and quest requirement change each time a metal ore is acquired. If quests are globally discovered/failed/ect then the quest requirement changes are also global right? Is it possible for Player(0)'s quest requirement to be changed each time he acquire's metal ore without interfering with Player(1)'s quest progress using the GetLocalPlayer native? And if not, would an array help?
I was thinking as a fail safe a quest could be disabled for all other players and only enabled for the discovering player. The next player to discover it will have discovered the next array of the quest. GatherQuest[1], as oppused to GatherQuest[0].
As for the hazards of this native, there would't be any for me, if I just display the quest requirement change/ update for one player (that is possible right?)
or is it possible that there would be a few seconds of desync before the player sees the quest update as to whether his metal ore he picked up counts towards the quest?
You can use either one. A lot of times I resort to the "failsafe" way of having arrays and one per player. For example, if you have a quest array to refer to one quest, you'll have a bunch of indexes (and instead of doing it as "next array of quest", you would just use the player's id):
For each loop_index from 1 to 12, do actions
--- Set Quest[loop_index] = New quest with title... icon...
--- Disable quest
--- Custom script: if GetLocalPlayer() == Player(udg_loop_index - 1) then
--- Enable quest
--- Custom script: endif
That will be the pseudo code. Then when you have a player update the ore count, you would just make a quest update for the Quest[loop_index]. Like so:
Event: Unit gets ore
Quest - Display quest update OreCount / 10 for Quest[Player ID of (Owner of (Triggering unit))]
Something like that. Obviously, that is pseudo code and probably looks nothing like that actual GUI code. I am just forgetful and don't have the editor with me. You may be wondering,
don't I need to set it locally? Not really. The beauty of having one separate quest for each player is that you only need to use GetLocalPlayer() for disabling/discovering/completing/enabling, but for updating the quest and all that, you don't really need to do anything. It'll also make it easier to perform checks. It is a bit complicated to explain. I'm sure I can paint a better mental diagram, but I'm kind of sleepy so I'll leave it at this. There are benefits to both methods. If you use only one quest and make the changes locally, then you only need one quest. You will likely need to use GetLocalPlayer() a lot more though.
Hopefully I can come up with a working example on Monday (I hope I don't forget). It might clear some things up. GetLocalPlayer() is a kind of weird topic and is difficult to fully grasp without examples.
----
Visual effects normally don't have desyncs. However, there are always sneaky issues that can trick you. For example, let's say you set a quest as complete
locally for a player. Then you check "If quest is complete". It is complete for player 1, but not for player 2. Player 1 will pass the condition, and
only player 1 will actually execute the code in the if block. Why? Because for player 2, it sees that the quest is not complete. So if you create a unit within that if-block, the unit will only exist and will only show up for player 1. And, as my tutorial says, that will create a desync.