GIS FAQ

How is it different from Lyra’s Inventory and Equipment System?

1. First, Lyra’s inventory and equipment system is more of a prototype rather than a complete solution. However, it introduces a flexible data structure using DataAssets combined with Fragments. This concept is fully adopted and extended in GIS, while most other parts have been almost completely redesigned.
2. Lyra’s EquipmentDefinition is quite redundant. In GIS, any item with an Equippable Fragment can be treated as Equipment. Additionally, Lyra’s Equipment instances are limited, whereas GIS supports both UObjects and Actors (for example, equipping a pet that spawns an AI companion to fight alongside the player).
3. Lyra’s inventory system is essentially a simple list of item. In contrast, GIS supports multiple containers (collections), which can store items in different forms such as lists, item slots, and stack-based structures. They share a unified api, while allowing flexible switching of underlying implementations.
4. Lyra has several known issues, the most typical being network timing problems—for example, the client may receive the ItemEntry before the corresponding ItemInstance is available.

Was it build with GAS in mind and if not would it be easy to integrate it into the system?

1. GIS is not tightly coupled with GAS, but GAS integration was considered from the beginning. You can use custom Item Fragments to associate Gameplay Abilities (GA) and Gameplay Effects (GE) with items. When an item is used or equipped, the corresponding GA/GE can be applied to the owner. These items can be weapons, armor, or accessories—fully customizable without modifying the core code.
2. You should try the All-in-One playable demo, which showcases how the combat system(GAS based), movement system(GAS friendly), and inventory system work together:
   https://drive.google.com/drive/folders/1rHTLX4LO9Zy9TP-8XbTECExX5sAH3XoV

Was network security considered in the design?

Yes. All critical logic runs on the server, following a standard Client/Server architecture. The client only retrieves data for display and sends RPC requests to the server for any changes.

Does the sample project built with Common UI include ready-made UI layouts?

1. Yes, the sample project includes a complete UI implementation, built using one of my free plugins:
   https://www.fab.com/listings/98b2c4a0-9520-4d6b-8bc2-86d5c82612ca

This plugin not only handles UI but also supports multiplayer interactions (e.g., multiple players trading with the same merchant simultaneously).

2. This also highlights that GIS itself is fully decoupled from UI. You can either use the provided presentation layer or design your own from scratch.

Does it support permission-based trading and shared inventories between players?

1. Shared inventories are supported. For example, a camp can have a shared chest accessible by all players belonging to that camp. However, determining whether a player belongs to a specific group is the developer’s responsibility, not the plugin’s. The system provides ItemRestriction scripts that allow you to define custom logic for adding/removing items.
2. You can use Buy/Sell Conditions to control whether a player can trade specific items, and Price Modifiers to dynamically adjust item prices. For example (not built-in but easily extendable): a merchant reputation system where a 50–100 affinity translates to a 10%–30% discount, or regional pricing differences.

The crafting system documentation is empty. If it’s implemented, could you briefly explain how it works?

1. The crafting system is mostly implemented in code but has not yet been fully tested. It will be completed in a future update.
2. The general idea is:
   For example:
   You can create an item called Item_Recipe_GreatSword, which takes two Item_Weapon_Sword as input and produces one Item_Weapon_GreatSword as output.
   The CraftingSystemComponent handles the actual logic—consuming the recipe, deducting inputs, generating outputs, and adding the crafted item to the player’s inventory.
3. • Items with a CraftingRecipe Fragment act as recipes.
   • A recipe can define other item definitions and currencies as inputs, and produce other items as outputs.