Preventing Persistence Exploits from Multiple VRChat Instances
Trudolph
The ability to open two instances of VRChat in separate windows under the same account, each being a different instance of the same world, creates significant issues for any game world that relies on persistence.
I'll refer to the two windows as "Window 1" and "Window 2." Both are running the same world but in different instances.
If a player performs an action in Window 1, such as getting a reward or losing progress, and the world saves that, they can simply close Window 1, switch to Window 2, and wait for the world to save their data. This will entirely overwrite the changes from Window 1, restoring their progress as if nothing had happened.
This exact issue happens very commonly on mismanaged Minecraft servers, where you can have two instances open on the same server but in different subservers. This is most commonly used to duplicate items, which no RPG-style game world wants.
An example in VRChat would be the world "Project Aincrad". If, in Window 1, Player 1 trades 10,000 in-game coins they have to Player 2 while Window 2 is up, then at the end of the trade, when the game forces them to save their persistence data, Player 1 in Window 1 will have 0 coins, Player 2 will have 10,000 coins, but Player 1 in Window 2 will still have the 10,000 coins, meaning that 10,000 coins have now turned into 20,000 Coins.
I'm not very technical, so this is more of a guess for a potential solution, something like only allowing Window 1, or whichever window was first in that specific world, to be capable of changing the persistence data for that user and world.
Log In
FTWGaming0
Having two instances of VRChat running simultaneously on the same account shouldn't be allowed at all unless the clients are running in offline mode. The website should be able to keep track of this because to go to any world, the game has to make a request to travel to the world, and the current instance where the user is in-game can be seen on the website as well. I don't think persistence data should be writable if the user's current location does not match the instance it's being saved from.