hi i'm making a plugin that adds a few prefabs to a scrapcopter.
dissapears 
everything is working great but the prefabs i've added stop drawing on the client side after travelling a certain distance in the chopper. you can interact with the attached entities but visually they are goooone.

i saw similar issues in this This Post but haven't been able to solve the problem.

does anybody have any tricks / examples of how to keep an entity visible on a vehicle that's travelling?

thank you

there is a plugin that attaches 2 extra chairs to a minicopter maybe you can look at it for tips

The client culls certain entities visually when they are not near the origin cached in the client. See what happens if you leave the area completely, so that your client destroys the parented entities, then return to the area so it will recreate them. If the entity renders after returning, then it means you can use a hack where you destroy and recreate the entity on each subscribed client. Just destroy the entity on clients (by sending message to them); no need to destroy the entity on the server as that wastes performance and could destroy container contents and such.

If the entity does not render when you return, it either means you didn't go far enough away to destroy them, or because of an issue with specifically parenting, where clients cache the original networked position as the world origin. Normally people work around that issue by spawning at the desired world position and then parenting, but that doesn't work for new clients who did not observe the entity spawning, or for clients who leave the area and return. I have an experimental plugin on my GitHub called ParentedEntityRenderFix which I have not finished, that attempts to address the parenting issue for initial spawn and repeat spawns, but it doesn't yet do periodic destroying/resending of entities, and it would have to be coded for specifically the entities you are having issues with.

ahh thanks for the low level info. i was assuming it was something like that from what I gathered ;)

I don't see your github repo, am I able to fork your repo and play around, or is that a private one?

Goldie

there is a plugin that attaches 2 extra chairs to a minicopter maybe you can look at it for tips

Thanks, I checked it out and appear to be doing the same thing as them (other than the different prefabs). I'll try adding using the passenger chair prefab to see if it's the prefabs I chose that don't like moving just in case.

yoinks

ahh thanks for the low level info. i was assuming it was something like that from what I gathered ;)

I don't see your github repo, am I able to fork your repo and play around, or is that a private one?

Thanks a lot i'll take a peek as well.

Would it be crazy bad performance wise to do this as an alternative - seems to work initially?
- check / store the copter position on enginestart
- check current position (while engine on) vs. old position that is stored
- if distance > XXX do this
- set stored position to new current position

I'm not sure what the max distance is before the prefab will vanish, but it seems to be fairly consitent. If I could figure out the proper check-distance interval and the max distance (or close to) then I feel like I could run this timer bandaid w/o many issues??

I have this running right now, and it doesn't seem to cause me and FPS drops or anything bad server side but not sure how it scales and if perhaps I'm overlooking something huge due to my lack of c# experience :)

Depending on the root cause of the issue for your case, you may have to combine both the parented entity render fix, and periodic client-side destruction.

Your description of the algorithm is exactly what I was going to suggest.

great, thanks again. i'll post an update when i sort it out ;)

I have wondered if it is the client choosing to ignore / remove the objects, or if it is the server choosing to stop networking them.  Anyone dug into this?  I'm not sure if the client really destroys the object.  I attached SimpleLights to a MiniCopter, and they would still light up the ground, even though the lights themselves were invisible.

I dug into it a few months ago when I started that plugin. They are still being networked and the client is aware of them, but it simply culls rendering of them. For example, switches will still show prompts even though they are not rendered.

They become invisible when the client moves a sufficient distance from the location the client cached for the entity's origin, which it caches when creating the entity. The distance is a bit inconsistent, as well as the rendering which may only cull parts of the entity. Additionally, moving the entity or client back does not seem to always restore rendering.

There's an additional bug with parenting where if an entity is created on the client while it is parented, the client does not take into account the parenting when determining the spawn origin so it assumes the networked position (which is actually local position) is the world position. This is why spawning entities like switches while parented to turrets will often render them invisible unless you are near the map origin, since the local position is so low that its somewhere near 0,0,0.

The workaround for the parenting issue, where you parent after spawn, only works for clients who observe the initial spawn and remain in the network group. My plugin aims to address this by ensuring the first time a parented entity is networked to a particular client, that its networked as unparented and then networked as parented immediately after. It keeps track of when players change network groups to reapply this mitigation the next time the same client subscribes to the entity.

Any idea of how the client chooses which objects to stop rendering?  Certain components perhaps, ones that it doesn't expect to be mobile?  Would be nice if it was possible to just trick the client into always rendering it.

I stumbled upon a IsMobile property in BaseMountable, not sure if that's anything related, but could explain why the chair prefab works with the extra mini seats plugin. It's checked in FixedUpdate() as well.

I assume it's probably hard coded client-side per prefab. If there is a property that can be tweaked for this purpose, it would have to be one that is networked to the client. There actually aren't that many networked fields. I didn't see any last time I looked that resembled this. You can browse them in the ProtoBuf.Entity class. The server also communicates with the client via RPC calls which are much fewer.