I recently have been attempting to add multiplayer features, and thus have been using the option to launch multiple debug instances.
After struggling for a LONG time, I recently learned that auto-loaded custom classes or globals, are NOT unique per game instance (but rather are shared by all game instances the engine is running).
I had created a System autoload that I use heavily. For example System.player: customClassPlayer represents the local player, and is where youâd store player attributes and access important player functions etc. When I started adding multiplayer features I made a player manager object as a child of System for centralized player management across scenes.
The fact that the System object is shared could explain many of the problems Iâve been experiencing.
Add-ons are impacted too. For example the Talo Multiplayer add-on uses an autoload, and it seems that session management goes somewhat haywire when two local instances are running as different âplayersâ. (I suspect lots of add-ons run an autoload and would face similar issues).
How can you effectively test multiplayer with multiple local instances if they share these sorts of objects?
This is not true, running mutliple local instances do not share data across each game instance. Globals are per-client, maybe you are misusing them or incorrectly setting authority?
well I was dubious as well, so I made a project to test. it has a single control node scene, and an autoload âSystemâ that stores get_instance_id() to its property âinstanceIDâ, and then echos the property to console. Both instances have the exact same instanceID. I also check windowID (which is normally different - but once itâs set as a System property, its not).
extends Node
# Autoload: System
var instanceID
var windowID
func _ready():
instanceID = get_instance_id()
windowID = get_window().get_window_id()
printt("instanceID", instanceID)
printt("windowID", windowID)
Both instances run _ready() and print output, but the values output are the same.
Right, because each game instance thinks itâs the only one, if they had different window ids then you might be onto something. They all think they are window #1, because they are seperate runs.
extends Node
# Autoload: System
var clicks: int = 0
I might beat @gertkeno to the punch but instance ids are not (randomly) unique and are assigned sequentially. If both processes have the same node creation order then they will likely get the same instance id.
If you want to see how they get assigned here is a link to the github source code. I dont know much about how the ObjectDB is constructed but whenever an object class is created its constructor interacts with the ObjectDB.
It looks slightly complicated in generating an id, but it boils down to just an index to an array that is based on the slot value when the Object is added.
Well I have a few things going on but one of them has to do with unexpectedly invalid sessions/headers etc in the Talo addon. Whenever there are two games running (different talo users logging in), one of the sessions will often get invalidated somehow.
While running that down it I heard that these were shared resources, and thus could explain the wonkiness. When I did the instance_id check and it seemed to confirm that (I thought those ids were unique) I had a bit of a âHow is ANYTHING working!?â moment.
Iâll ping the Talo community for ideas on that problem, and rule out âsharedâ System for the others I guess.