Add session-id CLI Argument to Allow for Debugger Session Identification

[Eoin-ONeill-Yokai]

As discussed in godotengine/godot-proposals#3357 , I have added the ability for Godot to be passed a session identifier which is then used by the debugger whenever there are multiple debugger sessions launched (Debug > Multiple Instances configuration larger than 1.)

The Engine class has been modified by adding two methods: set_session_id and get_session_id; For each one I've added the appropriate documentation for their purpose and utility.

While using Godot's multiple-instance debugger, users can call Engine::get_session_id to branch logic for their needs. For example, the session id can be used to tell one instance to host a server while the others establish a peer connection. This is a nice quality of life feature for developers of multiplayer games where they might want to start a server and multiple clients simultaneously. Or you could use session ids to branch between two different gameplay configurations such as character walk speeds or jump heights. This is a nice way to compare and contrast two drastically different gameplay scenarios for game testing.

Here's a simplified idea on how this is supposed to be used within the editor.

# ...

enum NetworkRole {
	SERVER,
	CLIENT
}

func _enter_tree():
	if "--server" in OS.get_cmdline_args() or Engine.get_session_id() == 1:
		print("Server Start")
		start_network(NetworkRole.SERVER)
	else:
		print("Client Start")
		start_network(NetworkRole.CLIENT, "127.0.0.1")

# ...

From here, assuming multiple instances have been enabled by the user, the debugger window will open two or more windows with one instance hosting a server while the others connect as peers. This is essential for quickly testing networked multiplayer games.

Terminology Note

This patch refers to each Godot instance launched by the debugger as a "session", which is what they're called in the tabs above the debugger. However, in the Debug drop-down menu, these are referred as "instances". Since get_instance_id is already used extensively in the engine code, using the word session here seems appropriate. It might be worth considering changing the terminology in the debug menu to be consistent with the debugger tab at the bottom (i.e. Run Multiple Sessions / Run X Sessions.)

[Eoin-ONeill-Yokai]

I've rebased the commits to fix a merge conflict.

[kdada]

It seems that it's more simpler to add --session-id here.

[kdada]

The session ID (or index) may be not equal to the session index of RemoteDebugger because of the execution order of connections.

[Eoin-ONeill-Yokai]

@kdada does #68054 make this PR obsolete or are these two PRs slightly different from one another?

I still think that some command line options for session id might not be a terrible idea for testing outside of the editor, but perhaps that can be added on top of your PR?

Otherwise, I can fix up and rebase.

[Calinou]

@IDreamInCode Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

---

Regarding the PR itself, I wonder if the CLI argument should also send the total amount of instances, so you know how many instances were created even on the 1st instance. This may be useful if you want to apply different (faster) graphics settings when running more than 2 instances, and have these settings apply to all instances.

To avoid adding yet another CLI argument, the --session-id argument value could be formatted as follows: current/total, e.g. --session-id 2/4.

This isn't critical so it can be left to a future PR, but I thought it'd be worth mentioning.

[IDreamInCode]

My apologies, I will use the thumbs up in the future!

…

On Sun, Apr 28, 2024, 11:07 AM Hugo Locurcio ***@***.***> wrote: @IDreamInCode <https://github.com/IDreamInCode> Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead. — Reply to this email directly, view it on GitHub <#64913 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNNAAP3Q7F3BFKZVPAQLE3Y7UNDHAVCNFSM57VN27SKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBYGE2TGNJTHEZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>