UNET ids failing to match on network session

Unity Engine
,
21

Try using HLAPI Pro (free, search on a forum). It’s fixed there.

22

Yep, I fixed this in HLAPI Pro: Mirror - Open Source Networking for Unity
This bug can be triggered in all UNET projects.

1 Like
23

You used my fix? Because I order the list by object name (which isn’t reliable).

just saw your fix and it is based on sibling index. Woundn’t that change uppon adding and removing things dynamically?

Also, awesome work on the HLAPI fix. I have a TON of documentation and assets developed to cope with all the bugs, if you need help, count me in!

1 Like
24

Yes, I tried about 10 different ways and came to the conclusion that sibling index is the best for now, since scene objects have no unique id in Unity. This works reliably now and doesn’t randomly change after restarts.

Any scene change still requires a rebuild yes. Ideally UNET would compare some kind of ‘lastProjectChange’ timestamp in the login handshake - because if you changed something in the client and not in the server then things usually go wrong.

1 Like
25

I thought about hashing each object. It would make the build a bit slower but it would guarantee, almost always, the same order.

26

Won’t work. If you have two monsters (same type) that spawn on the spot, they will have the same hash

27

Wow, this is such critical information about UNet Scene Objects hidden away here in this thread.
It’s unbelievable that games work as well as they do without developers being aware of the magic (or lack of) how UNet is wiring up client and server scene objects.

Thank you @lucasmontec so much for your brilliant investigation and work-around.

I’ve created an additional variation of it, that I attach this script to each of my scene objects:

public class NetworkIdentitySceneId : MonoBehaviour {
    public int SceneId = 0;
}

Then I use your script, but check if it has this ID manually set and I use that instead.

Thank you so much!

1 Like
28

Or you just rework the HLAPI and let developpers specify the scene id of their objects in the scene.
That what I will do.

Same for assetID, so we can communicate between different project.

There is more configuration from developpers but also more freedom.

1 Like
29

My client build can connect to a host if the host is an Editor…but not if the host is a build. I see the “Spawn scene object not found for 1” and 2, 3, 4. What’s going on here…

30

For 50 USD I’ll debug for you. Otherwise, I’ll wish you good luck.

1 Like
31

Will keep that in mind…might take you up on it later. I’m dropping this for now.

But is this bug still not fixed, as of 2018.1?

32

Nothing has changed, as far as I know

33

This same problem occured to me when I assigned a value to the NetworkBehaviour without it being initialized by the server/client. Maybe that helps someone.

Unity 2018.1.0f2

34

And yeah, no – this bug is still not fixed as of 2018.1… As, I found this thread looking up what the heck the new set of errors that I am getting mean. >.<
I just love this… I spend 99% of my day debugging UNITY… Not, my game in unity, but Unity itself. It used to be, I’d sit down, crack open Unity and build a game… now, it’s I crack open unity and see what the latest idiotic bullshit I will have to deal with, in a sad attempt at doing what I love. Oh well, maybe if I say it enough, I will be able to stomach using Unreal.

35

I can confirm this bug is around in Unity 2018.2 still.
And since UNET will be deprecated, the bug is known for what… two years now…, even though they promise support until 2022, considering I have issued a fair amount of bugs, I don’t think they will fix any of this at all.

36

Use Mirror (previously HLAPI Pro). It has this bug fixed in there.

1 Like
37

This happens because UNET’s NetworkScenePostProcess assumes that FindObjectsOfType always returns the same order - but the documentation says that it doesn’t. For this to work, we need to sort the FindObjectsOfType result in a deterministic way. We did that in Mirror and the UNET team copied our fix to UNET, but they did it wrong so the bug is still in there.

2 Likes
38

The fix is: have the same exact build as the server. Then the IDs match.

39

Since unet has been deprecated, reviving this thread is useless. Still, I wanted to respond since having the exact same build is the premise of this entire discussion. The builds where always the exactly identical. The issue has nothing to do with code or setup, but it is caused by the differences in processing internal functions on different processors.

40

For the people asking if the bug was fixed, use mirror. Mirror contains an implementation of the fix very similar to mine (suggested here).

1 Like