Sorry, I can’t pull out the relevant pieces from our project easily. If it’s relevant, our “weapons” are primary data assets that are not always loaded, so it has to go through the Load step on the server and client independently.I don’t know if it’s relevant, but the weapons have meshes, and animations associated with them, and they get spawned on the client locally as well as the server which then spawns an entity to replace the client local version.
When both players switched off the weapon, it was cleaned up so I think it’s probably important that nothing else references the “weapons”
We knew it would crash if it entered this section in PackageMapClient at all while NetGUIDLookup.Contains(Object)
`// Assign the guid to the object
// We don’t want to assign this guid to the object if this guid is timing out
// But we’ll have to if there is no other guid yet
const bool bAllowClientRemap = !bIsNetGUIDAuthority && GbAllowClientRemapCacheObject;
const bool bIsNotReadOnlyOrAllowRemap = (CacheObjectPtr->ReadOnlyTimestamp == 0 || bAllowClientRemap);
if (bIsNotReadOnlyOrAllowRemap || !NetGUIDLookup.Contains(Object))
{`With the repro steps above, does it even enter into this portion of code? (I had added a
ensure(!NetGUIDLookup.Contains(Object)) in that section locally just to confirm that it hit that section of code. If it ever did, I knew the package map was in a bad state. Having said that, the full crash didn’t repro all the time because during level cleanup, if all references to the “weapons” cleaned up correclty, the “weapons” would get cleaned up and no longer crash inside of void FNetGUIDCache::CleanReferences()