As I understand, as long as something isn’t referenced with hard reference it is not loaded into the memory.
Let’s say we have an actor class with replication property set on. Game mode (which exists only on server) references class of this actor with soft class reference. Game mode loads up this class and then spawns an actor out of it. As a result client actually gets to see this actor on their side. I performed the entire test using blueprints.
So my question is why is the client able to see this actor? Did replication in addition loaded this actor’s class into the memory? Or was my testing environment incorrect?
Its a replicated actor, therefore the replication system sends you a command to spawn it using the servers configuration of it. If it’s spawned it is referenced in memory.
Typically when speaking of soft/hard references we are talking about when a class references another. Like character referencing an attached actor or another in the game world.
If my character has a reference to the player controller it’s a hard reference. Meaning the character class reference has the full controller loaded in as well. A way around hard references is to use BP interfaces. The BPI will need functions to execute specific tasks.
For example if the controller needed to call an event on the character class. The normal route is to Get Pawn → Cast to character class → call event. OR cast once on begin play and create a hard reference to the character, use that reference to call the event. Either way you now have added to full weight of the character class to the controller class, plus anything else the character itself references.
The BPI workaround is to create a function in BPI (e.g. Call X Event), then Implement that event in the character class. Call X Event (msg) -> Some Event
Going this route requires you to write a massive amount of BPI events and managing it.
Another option is to modify PAWN parent class (C++) to have all the needed events. This will bypass the need to cast to character etc. You’ll need to modify character class to use the new Pawn events though.
So do I get it right that the moment replication system finds an object that wants to be replicated, replication system immediately establishes hard reference to this object and thus loads this object’s class into the memory?
And I guess I needed to mention this at the beginning, the reason I am asking all of this is because I want to find out what is the better way to set up equipment system for multiplayer. Each equipment piece has its own functionality, mesh, etc. And I want to control what gets loaded into the memory depending on what each player puts on their character. So I am trying to understand what kind of data should be replicated.
Anything that is spawned is loaded into memory.
Anything that is used is loaded into memory.
Equipment added to your character that the other players need to know about needs to be replicated. Thus loaded into memory.
If others do not need to know about it, then sim proxies of you do not need to have it. But this is dependent on what that thing is. Game play relevance is key here.
Sorry for going in circles, I think this is the question I actually wanted to ask.
Let’s say we have Equipment class and three children descending from it: RangedWeapon, MeleeWeapon, SpecialGear. Server spawns MeleeWeapon, and replication system picks it up for clients. Surely clients will have loaded Equipment and MeleeWeapon classes. But will clients have loaded classes of MeleeWeapon and SpecialGear?
Let’s say we have Equipment class and three children descending from it: RangedWeapon, MeleeWeapon, SpecialGear. Server spawns MeleeWeapon, and replication system picks it up for clients. Surely clients will have loaded Equipment and MeleeWeapon classes. But will clients have loaded classes of MeleeWeapon and SpecialGear?
No, they won’t load the other classes into memory.
Equipment (Parent)
RangedWeapon (child)
MeleeWeapon (child)
SpecialGear (child)
Spawning MeleeWeapon will load MeleeWeapon and all the inherited data/code from Equipment.
Equipment should be a Very very limited parent class. Only things needed across all subclasses.
RangedWeapon should be a child class, that parents only ranged weapons. The same applies to the others.
Equipment (Parent)
RangedWeapon (Equipment child)
ShortBow (RangedWeapon child)
LongBow (RangedWeapon child)
These subclasses should technically be config based and all the logic code would be in RangeWeapon.
Long Bow would inherit RangedWeapon and Equipment.
Personally I’d have each of your subs as actual parents vs the long chain inheritance.