I have a prefab that has a hierarchical structure. On some of the children, I have Unity.Physics-related authoring components. Currently, these components are also sent to the clients.
However, I’d like that aspect not to be sent to the clients so that the physics system on the clients does not pick them up and process them. I only need the physics systems on the server to process them and their Translation/Rotation to be sent to clients.
But I cannot deselect it in the editor UI, see image below. How can I deselect the physics components in children for the client?
From my current understanding, only the components marked in bold get synced over network (and of these only the properties that are shown when expanding the component). So your physics mass shouldn’t be synced over network. If you modified or even removed the component from the Entity on the client it should still be in its original configuration on the matching server entity.
That’s at least what my current testing shows. If you want to add something use the Manual Field Checkbox or the [GhostDefaultField], the component then becomes bold and is also added to the generated ghost code.
Thank you for the infos! I have the same understanding from the generated code – in my case only Translation/Rotation gets synced (from *SnapshotData).
The syncing/not syncing is less of an issue for me. The issue is more the existence/creation of the component on the client side. I think I may have misunderstood what the checkboxes are for. Back to the manual…
Edit: No, the description is “Expand the components in the list to select where they should be present.” So the checkboxes determine where the component is present. I’m wondering how I can uncheck the checkboxes on children (adding a ghost authoring component on a child and unchecking there did not help).
Aw, too bad, I was hoping it would work. So currently it’s not possible to have child entity components removed after the entity conversion (not just to not send the component, but to not have it exist as in the root’s case).
This is my case (simplified here): A parent car entity with four wheel entities that each have physics components on the server, but should not have them on the client. I need the physics system to run on the client (for some client-only effects), but to not have the car and wheels be handled on the client.
Is there any way I can do this via NetCode or do I have to remove the physics components myself, for example in a client-only system that matches certain entities’ components? (car, wheels) And will the child entities at some point in the future be also comfortably be checkbox-selectable, and it’s only now not comfortably possible?
I think you can remove the physics components if you override the methods UpdateNewPredictedEntities and UpdateNewInterpolatedEntities in a partial class like:
public partial class CarGhostSpawnSystem : DefaultGhostSpawnSystem<CarGhostSnapshotData>
{
protected override JobHandle UpdateNewPredictedEntities(NativeArray<Entity> entities, JobHandle inputDeps)
{
inputDeps.Complete();
//Get wheels from entities by LinkedEntityGroup
//remove components from wheels
}
protected override JobHandle UpdateNewInterpolatedEntities(NativeArray<Entity> entities, JobHandle inputDeps)
{
inputDeps.Complete();
//Get wheels from entities by LinkedEntityGroup
//remove components from wheels
}
}
Right now it is not possible to do it in netcode so you have to do it yourself. The way the checkboxes work is that we do a entity conversion, then remove the component which should not be present for the type we are currently converting too (server, interpolated or predicted client), When doing this stripping we are only considering the main entity at the moment, so it is not just a matter of enabling the checkboxes.
I’ve filed a bug so we can have a look, keep in mind that ghosts with multiple entities is significantly more expensive on the server than multiple ghosts though - so you should only use it when you really have to.
Yes, that makes sense. Thanks for looking into it (I’m currently evaluating feasibility for my game and estimating how much work is needed).
Yes, I assume to collect all the data, entity components need to be collected via child-parent relationships. I don’t see a way yet to avoid these parent-child relationships. Unless I could put a ghost on each child comfortably – that would work for most cases (see cases below).
Given “keep in mind that ghosts with multiple entities is significantly more expensive on the server than multiple ghosts”, would it be a possibility to instead of using one ghost on the parent have multiple ghosts on parents and children?
I’ve collected my parent-child cases and how I’d like to process them in NetCode, trying to minimize data sent and processing power. Perhaps you can use this as input on the “bug”. The thing with the four grey things attached represents a car.
Case 1 is probably quite standard. The parent-child connection could even be severed in this case, since its transform could be sent from the server (avoiding work in parent-child transform systems on the client – this may already be the case, I’ll have to check).
Case 2 is where I do not even want to spawn an entity for the server child entity on the client.
Case 3 is where the child entity does not need to exist on the server, but it needs to react to physics on the client.
Case 4 is a case where I could either have parent-child transform systems on both ends do the work, and send nothing via NetCode (to avoid costly data collection), or collect the data and send it over the wire, as in case 1.
Currently, I’ll be doing this via my own systems, but of course it would be great to have client/server existence checkboxes on child entities plus being able to have the server/client pred/client interp. checkboxes for child entities. Not saying it’s absolutely necessary, but to cover my cases above it would be more comfortable
Yes, we are planning to add a such a mode for ghosts with multiple entities. They would still be spawned as one unit, but they would be synchronized individually do reduce the cost. The current behavior will remain as an option.
No, it is still on our backlog but I don’t know when we will get to it.
What do you need it for? It will not allow you to do anything you can’t do today - it is an optimization mostly for CPU time on the server and we do have some other send optimizations coming which could help if you have performance problems.
Ok. I was just wondering if it’s already there and I missed it. I won’t really need it, but as it currently stands synchronizing children is bugged beyond usability.
I’m not aware of any bugs related to synchronizing child entities, only some limitations in what you can do with regards to removing components from them and similar things. What bugs are you seeing?
