Bizarre TargetRpc Issue I'm getting, null ref being called from within the Network Behaviour code.

[mighty flicker]

All I'm passing in is the network connection of the player, and a unint netId. I tested both within a Debug.Log message right before calling to see if they were the issue, and they appear not to be. I attached an image of how the offending code looks. Here is the error message:

Mirror.NetworkBehaviour.SendTargetRPCInternal (Mirror.NetworkConnection conn, System.String functionFullName, System.Int32 functionHashCode, Mirror.NetworkWriter writer, System.Int32 channelId) (at Assets/Mirror/Core/NetworkBehaviour.cs:467)
SlimeGrabber.TargetReceiveBowl (Mirror.NetworkConnectionToClient target, System.UInt32 bowlNetId) (at <6f5127e1f588453d80187bca6532ce93>:0)
SlimeGrabber.Initialize () (at Assets/Scripts/WorldItems/SlimeGrabber.cs:24)```

I've used Mirror in my project for several months and have never had an issue like this. I can't seem to figure out what is causing it, since it doesn't obviously seem to be any of my input.

Unity version is 6000.0.32f1
Mirror version: not installed as a package so I'm not 100% on how to verify

[cyan jetty]

Mirror ships with a text file in the root that holds the version number if installed with the Asset Store or the unitypackage. Idk why chose a different install option in the first place?

[cyan jetty]

For your other problem indeed the component is null. Is your Prefab correctly set in the NMs spawnable prefab list and indeed does have a NetId component attached to it?

[mighty flicker]

was someone who used to be on the project who installed it, I'm not sure why he did many things... I see a text file in the root, but it only says Unity 2019/2020 and doesn't provide a specific version number.

[mighty flicker]

ohmygod this is the issue thank you

i mean i assume it is I'll go check but I assume that is probably the problem

weird that it still outputted a valid netId in my debug message but whatever

thank you!

[cyan jetty]

worked? error resolved?

[mighty flicker]

checking now

ah unfortunately that didn't work

in the worst case i can do a command requesting an assignment, I just think the targetRpc on startup way of approaching it is cleaner because it has less calls..

[cyan jetty]

does your bowl object gets disabled / is it disabled in the hirachie? Does GetComponent<NetworkIdentity>(true) result in the same nullref?

[mighty flicker]

currently it just gets yeeted really far off screen when it isn't being used by the player. I'll try running that code

oh also currently "{bowl.GetComponent<NetworkIdentity>()}" does not return a null value in the previous debug.log message, not sure if that changes anything

im getting a compile time error for trying GetComponent<NetworkIdentity>(true). no overload takes 1 arguments

[cyan jetty]

my bad wrong method

currently it just gets yeeted really far off screen when it isn't being used by the player. I'll try running that code
oh also currently "{bowl.GetComponent<NetworkIdentity>()}" does not return a null value in the previous debug.log message, not sure if that changes anything

Lost track of your setup. Not enough information provided. When exactly is Initialized called? How is your overall setup (NM, scenes, etc.)

[mighty flicker]

let me know if I'm not explaining something adequately, I haven't seen other Mirror setups in unity so I'm not sure how mine differs.

• Two scenes, offline scene and online one (this is in the online one).
• This method isn't called immediately, only once the quest item is needed by the game, often a few minutes into the online scene. it is never called during the offline scene. It also doesn't need to be executed in any particular order, so long as it happens before the player interacts with the item (this is guaranteed).
• Basically this sequence only happens so that there is a bowl spawned per player, so if each player were to interact with an object that would give them that bowl, they each get their own bowl (and can see that everyone else also has a bowl).
• this quest is randomly selected from a group of eligible quests each round, so it's not guaranteed that these bowls will be needed, hence why I don't spawn them in immediately.

what i was explaining in the earlier message is that i never set the bowl inactive, (it gets deleted much later in the game [which is not the source of this issue]), and that the debug.log message in the line before the erring line doesn't show any of the input values in the erring line to be null, which is odd.

[cyan jetty]

Ok so if:

• ItemPrefab has a NetworkIdentity Component attached
• Bowl has it attached also in the Hirachy
• Bowl is active in the Hirachy
• Bowl is a root object and not a child of anything
• ItemPrefab is correctly assigned in NMs registered spawnable prefabs

and it still wont work than my knowledge has come to an end

[mighty flicker]

yes all of those things are true.. ah well, thank you for your help anyway!

i will try an alternative approach to the issue

[fleet flame]

wrong folder...version.txt in Mirror folder (not project root). We've included that or a long time. You can also look in project settings -> player -> compiler symbols and see what versions are there.

[fleet flame]

TargetRpc called from same method/frame as .Spawn is a race condition...the Rpc got there first because the Spawn message got queued. If each player gets their own bowl, add the connectionToClient of the player as 2nd param to NetworkServer.Spawn to assign ownership, and then on the bowl you can override OnStartAuthority that will only fire on the owner client and get rid of the TargetRpc

[mighty flicker]

i did check the mirror root in the previous message! the version is not there. in the project settings, it shows this:

[fleet flame]

You probably have the asset store release...that's fine.

[mighty flicker]

oh awesome great. i didnt know about assigning ownership, that's quite nice. I'll need to look into it more on the docs tomorrow.

do you recommend reinstalling?

[fleet flame]

Nope - you're fine where you are...96.x

[mighty flicker]

i was wondering if it was a race condition but figured since targetrpc is called server side and the error was given on that line instead of the line on the client's side that it wasn't that, but i also am not familiar with how mirror resolves calls so im glad you could clear that up for me

ill mark the issue as resolved, thanks so much again!

[fleet flame]

Also for future ref, inside a TargetRpc you're in client context and should never refer to NetworkServer anything...NetworkClient instead.