KPDN
Member
I've recently been working on the ItemSetManager integration between UIS and UCC. Following the official integration tutorials, the basic setup works fine, but it’s far from meeting my project goals. I have a critical question: is the ItemSetManager redundant when using UIS & UCC together?
Let me first outline my framework requirements:
Weapons must be linked to UIS items and support customization. This requires weapons to initialize on spawn and attach modular attachments based on item data.
I plan to use ItemSlotCollection to store UCC’s left/right hand slots. In theory, this means UCC only needs to reference UIS item slot collections and their associated bindings. Additionally, the system must manage weapon instance spawning/destruction and weapon equip/unequip logic.
Given this setup for UCC & UCC, is ItemSetManager overkill?
The original purpose of ItemSetManager appears to be managing rules for picking up items with left/right hands across multiple item sets. However, with ItemSlotCollection, all slots are strictly limited (essentially just two slots: left and right hands). In this case, the entire ItemSetManager and its dependent classes feel unnecessarily bloated.
I’ve been reviewing the related code recently and found that all equip/unequip functionality revolves around ItemSetManager queries — even ItemSetAbilityBase.EquipUnequip performs queries on every equip/unequip action.
My current pain point is that I want to implement a UIS-centric weapon equip/unequip system. The default UIS-UCC bridge works, but it forces all data flow through ItemSetManager to control UCC’s weapon handling. To me, ItemSetManager is overly complex, and I haven’t fully grasped its internal logic.
My ultimate goal is to directly control UCC weapon spawning, equipping, and unequipping from UIS, bypassing ItemSetManager entirely.
In my view, ItemSlotCollection can already fulfill most of ItemSetManager’s responsibilities — all that’s needed is a dedicated controller to manage spawned weapon objects.
I’d like to discuss: is this approach feasible, and what implementation paths are available?
Theoretically, I only need to handle weapon spawning, weapon control, as well as equipping, unequipping and switching weapons. I can let **UIS** manage which weapon is equipped, instead of delegating this logic to `ItemSetManager`. The upper-level data flow can be fully controlled by myself, making the intermediate `ItemSetManager` completely redundant. The downstream layer only needs to focus on actual weapon instantiation, animation management and concrete implementation logic. Is this design approach feasible?
Let me first outline my framework requirements:
Weapons must be linked to UIS items and support customization. This requires weapons to initialize on spawn and attach modular attachments based on item data.
I plan to use ItemSlotCollection to store UCC’s left/right hand slots. In theory, this means UCC only needs to reference UIS item slot collections and their associated bindings. Additionally, the system must manage weapon instance spawning/destruction and weapon equip/unequip logic.
Given this setup for UCC & UCC, is ItemSetManager overkill?
The original purpose of ItemSetManager appears to be managing rules for picking up items with left/right hands across multiple item sets. However, with ItemSlotCollection, all slots are strictly limited (essentially just two slots: left and right hands). In this case, the entire ItemSetManager and its dependent classes feel unnecessarily bloated.
I’ve been reviewing the related code recently and found that all equip/unequip functionality revolves around ItemSetManager queries — even ItemSetAbilityBase.EquipUnequip performs queries on every equip/unequip action.
My current pain point is that I want to implement a UIS-centric weapon equip/unequip system. The default UIS-UCC bridge works, but it forces all data flow through ItemSetManager to control UCC’s weapon handling. To me, ItemSetManager is overly complex, and I haven’t fully grasped its internal logic.
My ultimate goal is to directly control UCC weapon spawning, equipping, and unequipping from UIS, bypassing ItemSetManager entirely.
In my view, ItemSlotCollection can already fulfill most of ItemSetManager’s responsibilities — all that’s needed is a dedicated controller to manage spawned weapon objects.
I’d like to discuss: is this approach feasible, and what implementation paths are available?
Theoretically, I only need to handle weapon spawning, weapon control, as well as equipping, unequipping and switching weapons. I can let **UIS** manage which weapon is equipped, instead of delegating this logic to `ItemSetManager`. The upper-level data flow can be fully controlled by myself, making the intermediate `ItemSetManager` completely redundant. The downstream layer only needs to focus on actual weapon instantiation, animation management and concrete implementation logic. Is this design approach feasible?
