Lifecycle hook to support dependency injection on clients #630
Replies: 2 comments
-
This has been brought up to one degree or another over time. The reason it has not been added yet is because of performance concerns but I believe we have room now where we can squeeze it in without really any impact. A hook into all objects spawned would be easiest. EG: ClientManager.Objects.OnInstantiate. Let me know what you feel is good so we can run it by our open-development channel and get the best outcome. |
Beta Was this translation helpful? Give feedback.
-
If you can modify the latest versions (4.5+) of FN to show how you might implement this and paste the results here I'll be able to get you a better timeline/answer. If possible keep changes simple, that will improve the odds of it becoming official since there will be less to test/review. |
Beta Was this translation helpful? Give feedback.
-
Dependency injection on the server is pretty straightforward. I can just inject a GameObject as part of instantiation, before handing the object to FishNet for spawning. I have not found a robust way to support DI on clients and I think it would be a lot simpler with a new hook like
void OnBeforeSpawn(NetworkObject nob, Scene scene)
, something that provides an opportunity for my code to execute before a NetworkObject becomes active on the client.The client-side DI approaches I have tried are:
Connection.OnObjectAdded
handler - this works for client-owned objects. Tbh I am not sure if there's a way to make this work for unowned objects, but either way it fires after the object is spawned. This isn't great because DI-aware behaviors have to be written to handle container objects not being available until after network start on the client, while they're available earlier on the server. Other approaches like usingOnSpawnServer
would have the same limitation of having DI later in the lifecycle, I think.NetworkObject
s before they become active, consistent with server-side behavior. However, from within theObjectPool
I don't have insight into what scene the object is going to be used for, and it's very reasonable to have per-scene DI containers. This also isn't a particularly clean solution conceptually because my class is mostly a copy/paste ofDefaultObjectPool
with a few lines added; my concern is not directly related to object pooling, this is just a workaround for not having more visibility into the process.Beta Was this translation helpful? Give feedback.
All reactions