I want to make an item customization system in which certain aspects of items can be swapped out causing visual changes and stat changes. I have the stat changes covered, but am wondering if it would be more appropriate to have skeletal/static mesh components as part of the items which are set when an item is modified to reflect to the new modification, or if the modifications should be their own separate actors which are then attached to the items themselves? Does anyone have a system like this that would recommend one way or the other?
I am starting to think having separate actors for the modifications make sense since not all items will have modifications by default therefore having premade mesh components would be a bit of a waste since they frequently won’t relevant.
Would probably be less painful to make mods as mesh comps. By being part of the parent actor, they could easily travel with it between levels without having to spawn in new mods every time when changing maps. Even if it’s a single player game with one open world, you might still want to have a character select screen or something that shows player on a level used by the main menu before traveling to game world (or if open world with separate interiors/dungeons like Fallout). Serializing comps to save game would probably be easier too. Would only have to save the id or class soft ref of each comp and have the weapon assemble itself on begin play.
As for weapons that can’t be modded, you could simply have a bool for “can mod?” or some such on the weapon, which if false, skips any logic that updates or calls mod comps. And for weapons that have different numbers of mod slots, you could get all mod comps and foreach the results of that.
I think OP is worried about how the mods affect stats. I see the best way to accomplish this as each mod being a blueprint that can run its own logic on the owner to modify stats. If you were to make the stats modify on a case-by-case basis, you would need a large logic tree to account for many complex stat changes. Doing baseline +attack damage would be easy for all of them, sure, but what if you wanted one specific mod to give you a clown face? You would need to do branching logic. Now multiply that by how many unique interactions a mod can have and you’ve created a massively painful logic tree to handle.
components can have child classes too. The top parent weapon_mod comp class would just need to have a func to return the common values like damage (or sound level for suppressors). Edge cases liek giving you a clown mask could be done in function override of the main get stats func.
I do skeletal mesh merge (modular weapons system) for a few of my attachments. Others just add a static mesh and attach it. Stats are stored and configured in the weapon class… Multiple structs.
On attachment the weapons inventory and stats are updated. Same with detachment.
I have been thinking about this for a couple of days, and I think it does make the most sense to just use mesh components rather than actors since very few attachments will require their own individual logic.
Are you suggesting that static mesh components need to specifically be created before the game starts or just saying to use static mesh components? I didn’t realize you could add mesh components dynamically so now I am thinking that that would be the best solution for me since then they are only even relevant if the weapon has an attachment on it to begin with. Does this still have the associated benefits? I haven’t needed to do any level swapping, but it could be useful in the future potentially.
My current system is to just create a static mesh component when an attachment is added, set the mesh, and then attach component to component on the weapon actor.
By merge the meshes do you mean to use the set leader pose component or is there actually a way to merge them? I always thought that set leader pose was primarily used if you wanted the mesh to deform around something (like clothing on a character), whereas simply using attach component to component was better when connecting something more static to the mesh (i.e. a scope or a grip). Is this not true?
I did some reading on the subject, and it looks like there is actually a plugin already made so I was able to get the blueprint node directly. I applied this to my character model as practice since that was more familiar and was able to greatly decrease the number of components on my modular character which I am very happy with. The only problem I am currently having is that it does not seem to have any collisions despite the UE5 documents page saying that physics should be retained.
In terms of applying this to weapon modifications, however, I feel there are two main issues that I am not sure about. First, it doesn’t look like there is an easy way to unmerge meshes. Given that I would like to be able to swap out modification I am wondering if this will be the best solution since, I will need to destroy the mesh, then recreate it each time I swap an attachment rather than just changing a component mesh. Is this correct? I think depending on how many modifications I want to have available at the same time, however, I think this may be a justifiable tradeoff if there is no simple workaround.
The second issue I am facing (and maybe I just don’t fully understand the process yet) is that if I want to actually use the merge mesh feature in the first place, it seems that I need to have a full skeleton already made which has just been divided into components in order for them to be remerged. To me this means that if I want to have multiple attachments on a weapon, I will need to preemptively plan a skeleton which contains all of these pieces and divide it up into segments. Is this correct? This isn’t necessarily a problem initially, but I am just thinking in terms of reusing attachment parts on multiple models, or having multiple attachment parts that can be connected to the same location, this seems like it would get pretty complex. Is this the case?
Lastly, I noticed in this chart from the UE5 documents page that skeletal mesh merge has a medium game thread cost compared to the leader pose component, which is lower. I couldn’t find a reason for this online, are you familiar with why this might be as it seems counterintuitive to me?
Well, to ensure they all land in the right slot on weapon, you’d at least want to setup base component classes which already have meshes in them. IE, instead of just using vanilla sm comp, make your own attach class using static (or, if feeling fancy, skeletal) mesh comp as the parent. Then in game you could changes the meshes as needed. I’d use a data table containing a soft ref to attachment mesh and any stats, then have the component look up its info there on begin play (or construct script).
