SceneTree without network peer don't act like master

[GagaPete]

Godot version: 3.0.6 + 3.1-alpha1

OS/device including version: Arch Linux

Issue description: When calling is_network_master() without having a network peer assigned to the tree the call results in an error in the debugger (Condition ' !network_peer.is_valid() ' is true. returned: 0) and a result of false. RPC methods tagged as master won't be called neither but those with slave will.
I expected a SceneTree without an attached network peer to act like master so player scenes and alike can be reused in singleplayer modes.

Steps to reproduce:

• Create a new project
• Create a scene with a single node and attach a script to it
• Add a _process method with print(is_network_master())

[Faless]

I expected a SceneTree without an attached network peer to act like master

I partly agree on this, but one thing to note, is that RPCs/RSETs will still not work because there is no network peer.
I think one possible solution to that would be creating a LocalMultiplayerPeer that act as a NetworkedMultiplayerPeer, but does not transmit over the network and process information locally.
I haven't put much though on it yet, but just allowing is_network_master will not solve your problem of local multiplayer.

[GagaPete]

I partly agree on this, but one thing to note, is that RPCs/RSETs will still not work because there is no network peer.

RPC (haven't checked RSET) does work, but it invokes methods tagged as slave, not those tagged as master.

I agree, changing the behavior of is_network_master() wouldn't be enough. It looks like the whole engine currently acts like a puppet without a master if no network_peer is set. My suggestion is to change it so it acts like a master without puppets in this case.
A LocalMultiplayerPeer/DummyMultiplayerPeer could solve this problem but would need to be set explicitly. Would there be advantages over making it the default behavior if network_peer == null?

[Faless]

@GagaPete well, maybe they used to work in 3.0, but they are not supposed to, and does not work in 3.1 after the big refactoring with security enhancement.

extends Control

func _ready():
	rpc("do_stuff")
	pass

puppet func do_stuff():
	print("STUFF!")

Will give you:

E 0:00:00:0495   Trying to call an RPC while no network peer is active.
  <C Source>     core/io/multiplayer_api.cpp:624 @ rpcp()
  <Stack Trace>  Control.tscn::1:8 @ _ready()

Would there be advantages over making it the default behavior if network_peer == null?

Yeah, multiple.

• We don't have to fill the network code with if (network_peer == null) --- else ---.
• We can have dummy behave optionally as either master or puppet so you could use custom multiplayer API for every player, plus one for the server, and use the exact game code you would online but with no network traffic.
• Many behaviours would otherwise need specific documentation for the differences between when network_peer is null and when it's not. (what does get_network_unique_id return, what does set_refuse_new_network_connections do, what does what will the value of get_rpc_sender_id be?). All this is would have much clearer result, if you could create a LocalMultiplayerPeer which can be either a server, or a client, and then behave exactly like other MultiplayerPeer, but with no traffic.