Hey folks, I’ve been looking at adding a couple of network features for an upcoming project, which is intended to use Iris. I had things working pre-Iris but in order to make things work now I’m having to inherit from UNetActorFactory and selectively use our behaviour vs the base behaviour.
This is now all working fine but it requires two _API exports to be added. I’ve created a pull request for this here:
Any chance you’d consider taking this into the engine? to reduce our maintenance cost on keeping up-to-date with engine upgrades, and also to allow other studios to extend the behaviour in similar ways.
I can confirm we’ve received this PR in our internal tracker, and it will be routed to the appropriate subject matter expert for review as soon as possible.
In the meanwhile, I’ve linked to this thread on our internal tracker, so the SME can reach out here if they have any further questions.
The change in NetObjectFactoryRegistry.h seems unnecessary as the function is inlined and should be able to be called from anywhere? Or explicitly mark it as inline instead of exporting. As for the NetActorFactory.h change we cannot use whole class exporting anymore. Instead the individual virtual functions needed to be called will have to be exported. We can of course export all virtual functions. Were you able to make the other necessary modifications to use your custom factory without engine modifications?
Keep the export in the NetObjectFactoryRegistry.h then and do the changes to the UNetActorFactory as you described, exporting each virtual and mark class as MinimalApi.
If I change the function in NetObjectFactoryRegistry.h to be FORCEINLINE then I have to export the NetFactories static member instead or it simply moves the link error. Which would you prefer?
On UNetActorFactory I can absolutely mark all the virtuals for export instead, I’ll have to also mark the class for MinimalApi in order to export the constructor and destructor, is that ok? It essentially means the whole class other than the private members and GetFactoryName function are exported.
And yes, I was a little surprised to not need more modifications, but so far at least these are all that have been required to add some quite complicated custom behaviour!
Ah this bit is a little clunky tbh, this was just the smallest required edit to achieve it. The engine auto-registers the built-in actor and subobject factories, in order to replace the actor one with my own variant that inherits from it I can’t just unregister the original and register my new one instead since it’ll invalidate the factoryIds (which are actually indexes into the array and are invalidated for any later entries if an earlier one is unregistered). My solution was to retrieve the whole list, unregister everything, then re-register with my one in the slot that the default actor one used to be in.
I went with this when creating this pull request as it’s only a very minor change, even if it’s not completely ideal.
An alternative I think would be nicer would be have the types specified in config, I can write that version if you prefer?
Making the base types configurable would be great, thanks!
Very happy to discuss what I’m up to but probably shouldn’t do so on a publicly visible thread! Can you ping me an email to [Content removed] and I’ll talk you through it