Having a Ghosts with linked entities that has the same component (and one marked as ghostfield) will cause badly generated code in the TGhostSerializer, as multiple GetComponentDataFromEntity with the same type will be used. (caused InvalidProgramException: Passing an argument of size ‘10032’.)
1 Like
@Jawsarn How did you resolve this issue? I may have the same error message, although I never had an issue due to what you describe (however, the multiple GetComponentDataFromEntity are pointless).
1 Like
what did you put in place of the badly generated code?
also my ghosts are just plain prefabs, not sure what you mean by linked entity.
i just get this error when i go over 10 ghosts
@florianhanke @Stroustrup So I haven’t really resolved this in any good way, but waiting for a fix from unitys side. Currently I go in and manually fix the serializes. I’ve been away for a while, so not sure if there is any fix yet.
1 Like
I see that they haven’t fixed this yet. And saw that they had closed the issue on github with response of
“… Recently we’ve been working on rewriting CodeGen for ghosting, so I’m closing this issue as should be fixed in the upcoming versions (the one which will be public after “0.3.1-preview.4”).
…”
2 Likes
@Jawsarn Thanks for getting back to us. I generate my Ghosts automatically, and I “solved” it by removing all Translation/Rotation components of children that are attached to the parent entity (thus reducing the size). My biggest problem currently is that I have to replace all [NativeDisableContainerSafetyRestriction] with [NativeDisableParallelForRestriction] whenever I regenerate the Ghost code, which is often, for Unity not to hard crash. I’m quite worried that a fix will not come soon, since the NetCode release cycles are rather large.
1 Like
You can replace them directly inside the CodeGenTemplate from which the serializer does get generated if you have NetCode added as a local package.
The Template is located under com.unity.netcode@0.2.0-preview.5\Editor\CodeGenTemplates\GhostSerializer.cs
2 Likes
Thanks for the reminder! 
2 Likes
@florianhanke Nice that you could solve it by removing some components. I once asked regarding FPS sample if it was better as they did to group up data into components which are sent, or keep it grouped with functionality, and they said it should be better with functionality. But now in my case I have components with some data that is sent, and some that is local, and 24 different ghost types. So I’m a bit of a icky situation how I can solve this. Should I refactor components to only contain sent data & local? Set the project on hold until new netcode update?
1 Like
Apologies if this is a silly question: why does it matter how the sent fields are grouped into components when – in the generated code – they are “mushed” together anyway? I have only 8 ghost types, but I expect to have around 40, with quite a few components whose set of fields is only partially sent.
1 Like
@florianhanke No you are very much correct in that it didn’t make any difference if you add more local variables to the components, silly me. But if you combine sent fields into components you get less fields of ComponentDataFromEntity which reduces the risk you will bump into this bug. So if you end up with your 40 ghost types before the update, I think you’ll hit the problem again.
2 Likes
I did post a patch which gets rid of multiple ComponentDataFromEntity of the same type on serializers.
That partially fixed it for me. But i also try to keep synced component counts as low as possible.
We’ll have to wait for the next drop so that we finally get an official solution.
2 Likes
That helped me as well, thanks again, and I also was trying to reduce the amount of generated (and run, and also useless) code. Let’s hope for a close 0.3.0.
2 Likes
unity sure do like their #region statements
what’s the point of collapsing a line of size 1?
1 Like
Regions inside the NetCode codegen are marking the beginning and end of fragments.
So when generating code you call GenerateFragment which copies the content of the region into the file.
All of those Whatever_Identifier inside the region do get used as keys for the dictionary that you pass into the GenerateFragment method, the identifier will than just be replaced with the value inside the dictionary
.
The codegen for NetCode is pretty solid.
3 Likes
it’s very neat, i wish they would release a quick patch a day after a breaking issue like this is spotted though
3 Likes
Me too. I get the impression some Unity dev teams don’t make heavy use of the latest methodologies like automated integration etc. testing and CI/CD. If they were, then we’d see shorter release cycles. To be fair, it’s probably not too easy either. But yeah, it’s sometimes a bit tough going from N releases a day with thousands of tests in my professional environment to waiting weeks for a Unity package.
Anyway, I hope a goal for Unity is to get up to speed re automated testing (and dependency management, where they seem to invest some resources), especially in experimental code, as it makes the devs and the users’ lives so much easier.
2 Likes
To be honest with the release cycles and iterations we see on NetCode it feels like the NetCode team is just lacking tons of resources. I mean four months is a giant release cycle for a preview package which is supposed to be the future of multiplayer in Unity. I feel like the devs should just put out hotfixes or minor features every two/three weeks. At least from my point of view that would build a lot more trust.
3 Likes
Yes, I’d very much prefer a 2 week release cycle where even one release is buggy, I know I can just go back to the second most recent release and wait another two weeks. (I’d also already be happy with the current cycles, but with minor releases in between for fixes)
3 Likes
We stumbled upon the same kind of issue for our DOTS project but for a different use-case (not using Unitys Netcode). Not to I just thought I’d add the knowledge I gained from the error when working with it if anyone else finds this thread when searching for information about this Exception:
InvalidProgramException: Passing an argument of size ‘10032’
The main problem was that our job struct simple became too large, as we were including TypeHandles for a ton of components (I believe it was somewhere around 150 TypeHandles). When the job struct eventually reached somewhere around 10k bytes, this error began throwing. We will solve it by rewriting our code to not create massive job structs, instead creating a ton of smaller jobs.