Network instantiate confusion

Unity Engine
1

So I was following SteamisM50’s tutorials on youtube - and this code stood out for me in the spawn object:

	void OnConnectedToServer()
	{
		SpawnPlayer();	
	}
	
	void SpawnPlayer()
	{
		Network.Instantiate( player, transform.position, transform.rotation, 0);
	}

What confuses me about this - is that OnConnectedToServer is run on the client, so it appears that the client is requesting an object to be spawned without any need for confirmation from the server - how does the server know the client is allowed to do this? It’s working fine, and the documentation states that whoever calls it is how it’s determined who owns the object, so it seems to be saying the client should be requesting and receiving the spawn, but what about the acknowledgement from the server that it’s alright? I’m still a little bit fuzzy on unity’s networking, so I’d appreciate clearing this up!

2

Not all the time does a server need to know whats going on, it depends on the servers level of authority. Reference articles have quite a write up on this. This is how lots of cheats are readily exploitable through games that dont rely on the server dictating game play.

3

That’s not really relevant to what I asked - I’m aware that some things can be entirely clientside and the server doesn’t need to worry about, and I’m also aware that when the server does not monitor various things it can easily lead to exploits. I’ve read through the reference manual article on network views and network instantiate.

To make my question clearer, this is what I would expect to happen in any network library really:
Client asks to spawn->Server acknowledges that you can spawn->Player is spawned, server replicates across all clients

What is happening right now is this:
Client asks to spawn->Player is spawned, server replicates across all clients

Nowhere in my code does the server side portion seem to need to allow this. I see there’s a function called “OnNetworkInstantiate”, and maybe that’s the proper way to allow or disallow the client to instantiate an object - but it makes it seem like it’s run after the fact and there’s a possibility the object could do something or be seen briefly - like if the object say… is a bomb, and it immediate starts destroying things when it’s spawned, would it’s “Start” code be run before OnNetworkInstantiate or after?

4

Sorry Elspin, willc was 100% correct in his answer to your question.

It’s up to YOU to code the authority level of the server, because in Unity’s networking anyone can Instantiate and object and therefore own it. It has nothing to do with the Server and it acknowledging it, unless you specifically code it that way.

If you want a Client to be able to Instantiate a Network object (and therefore own it), but you want the Client to ask the Servers permission BEFORE it does so, you need to code this into your Network logic yourself. There is nothing in Unity’s networking framework that does this for you.

Cheers :slight_smile:

5

His answers were correct as I stated thanks, but his answer was not what I was looking for and neither is yours. I feel like a broken record here, but what both of you are telling me is “Unity doesn’t regulate it, you need to” - and that much is clear, but what I’m asking is WHERE really. At what point can I reasonably block the client from being allowed to say, instantiate an object. I posed a very clear question in my second post if, for example, I could reasonably block the client from creating the object on the server with the “OnNetworkInstantiate” function before the object being instantiated could do anything.

6

Elspin, you need to calm down. No your question wasn’t cleat at all, your only question posted was “is Start() called before OnNetworkInstantiated() or after”.

You did insinuate what you though SHOULD be happening, but you didn’t ask a question on how.

Most of us here are very friendly and helpful people, up until the point the we get abused or it’s clear the OP isn’t trying to help themselves.

Ok, so to answer your latest question…

You would need to use RPC calls in your method that wants to pre-instantiate your network object… pseudo code example.

  • The player clicks mouse button to spawn bomb
  • The method that catches the mouse click sends an RPC call to the server calling a method that asks permission for the player to drop a bomb (e.g. networkView.RPC(“AuthenticateAction”, RPCMode.Server, Network.player, “CanDropBomb”);
  • Server sends an RPC call back to the client calling the clients dropBomb() method with true or false parameter. (e.g. networkView.RPC(“dropBomb”, networkPlayerID, true);

Cheers :slight_smile:

7

Nobody is “abusing” you or anyone else, there was no flaming. It’s rather silly as well to ask that I “calm down”, when I’m not even angry to begin with - it’s not like you can see me through the tubes and I’m pulling an angry german kid on my keyboard. I did however find it pretty rude that you were trying to claim someone had answered my question, when they hadn’t as that’s not up to you to decide. If you really can’t understand my posts, instead just ask for clarification; there’s no need to be rude about it. If you really are very friendly, show it!

I’ve gone through hours of tutorials, read all the relevant documentation I could find, and tried a few things on my own so if that doesn’t qualify for “trying to help [myself]”, I don’t know what does.

On to your pseudo-code! The problem I have with it is the RPC is informing the client of whether or not they can do something - shouldn’t it be the other way around? At the end of your sequence there, the client is doing something - networking instantiating an object. So what if they just skip the pre-auth step and try to network instantiate? Wouldn’t that then go back to the previous question I had, of whether or not the OnNetworkInstantiate function is too late to stop the explosion or not?

I can definitely see that it’d be easy to say “they didn’t auth, and they instantiated, so ban them”, but by that point will the bomb already have gone off?

Usually if I had a question like this I’d just try it out and see if I can do what I’m wondering, but I don’t really know unity well enough yet, and I figured this would be a quick question

8

At spawning you actualy make the decision of who owns the object. If the client does then OnConnectedToServer is what you need.
If you want the server to be the owner, you put it in OnClientConnected.
You could also just put a button on the screen and let the user click it when he want’s to spawn his player. Then again it’s up to you to make the decision of who will own the object and will execute the Network.Instantiate

9

If you are after. An authoritative server, instantiate on the server and stream movement and action requests from the client.

10

I’m actually partial to not using Network Instantiate at all and instead think it’s better to rely on manually setting up the objects and assigning network views, but that’s a tad more complicated than most of the Unity users would like.

11

Yeah, the documentation got me up to that point - although I’m not 100% sure how much “owning” an object implies, aside from the networkView.IsMine being true on the client that owns it. If the client owns an object, does that mean it’s given less access in terms of what it can do on the server, even if the object has code that supposedly runs on both?

I think you might have answered one of the other things I was thinking about here - I was looking at the network streaming functions and it seems like it you can write the code in a way that the server has to decide whether or not it wants to accept the client input, the code for the tutorial was supposed to be an authoritative server but I don’t think it really is (probably why I’m confused a bit about how this code is supposed to be authoritative)

12

When a system in the simulation owns the NetworkID, they are the only ones with the authority to write to it and those writes are then propagated across the network.

It’s possible to have multiple NetworkID components on an object, which gives some interesting options. If you are interested in an authoritative server, everything that matters in the simulation is owned by the server.

13

I’m just building such a solution now. Its client → server → clients

But I’m not sure it’s completely exploit proof. Truth is I don’t think anything actually is if it lives on the client’s computer. Full authority seems a little over the top in my case, but would probably be the best option to remove exploit possibility.

What I’m going to try and do is have the server check and authorize rpc requests before sent out to the connected clients. This way I’m assuming the client can actually instantiate items and not rely on the server. If an exploit is made then the cheaters client will be out of sync and not affecting other connected clients.

But all this is in theory at the moment, however I am getting good results so far.

The objective is to have a thin server to handle client communication and eating a low amount of resources.

14

Actually I just did some testing and an authoritative server is much better than my solution. So authoritative is probably the best way to go.