它与Lyra的库存和装备系统有何不同？
1.首先，Lyra的库存和装备系统只是个半成品，但它提出了DataAsset配合Fragment实现灵活数据结构。这一点在GIS得到充分应用，其它部分在GIS种几乎重新设计。
2.Lyra的EquipmentDefinition显得非常多余，在GIS种，只要具备EquippableFragment的道具都可以视作Equipment。Lyra的Equipment实例只能是UObject，GIS的Equipment实例可以是UObject，也可以是Actor（比如装备了一个宠物，生成了一个宠物AI为我战斗）。
3.Lyra的库存系统逻辑本身只是个单一列表，GIS的库存系统是包含多个容器（集合），不同的容器以基于列表，物品槽，和物品堆栈的形式存储。统一接口，但不同的底层实现随意切换。
4.Lyra有很多Bug，最典型的是网络时序问题，客户端ItemEntry同步下来了，但是ItemInstance还没有。
它在设计时是否考虑到了 GAS？如果不是，将其集成到系统中是否容易？
1.GIS的核心系统不与GAS捆绑，但确实一开始就考虑好了与GAS的集成。使用自定义道具Fragment为道具关联GA/GE，当道具使用，或者装备时，你为装备的所有者添加GA/GE。这些道具可以是武器，或者盔甲，或者是护符，你可以自由设计，无需修改我的核心代码。
2.你应该体验我的All-In-One可玩Demo（它演示了我的战斗和运动系统以及库存系统组合起来的效果）：https://drive.google.com/drive/folders/1rHTLX4LO9Zy9TP-8XbTECExX5sAH3XoV
它在设计时是否考虑了网络安全？对于专用服务器上的多人游戏，任何与物品栏相关的功能都应该只由服务器处理，客户端也只能通过其用户界面从服务器读取信息。
是的，关键行为都发生在服务端，标准的Client/Server架构。客户端只是从服务端获取数据，展示，并以rpc方式请求服务端进行变更。
使用 Common UI 构建的示例项目中是否已提供现成的 UI 布局？
1.是的，配套项目有UI的完整实现，但是它利用了我其中一个免费插件：https://www.fab.com/listings/98b2c4a0-9520-4d6b-8bc2-86d5c82612ca
其实该插件不仅实现了UI，也实现了联机交互（比如两个玩家同时和一个商人进行买/卖）。
2.第一点足以表明：GIS插件本身对UI完全解耦，你可以用配套项目里的表现层，你也可以完全自己设计表现层。
它是否考虑了玩家之间权限不同的交易和共享库存？
1.支持共享库存，比如一个营地可以有一个箱子，只要是属于该营地的所有玩家，都可以进行存取。然而，如何判断玩家是否属于某个营地，是用户的职责，不是插件的职责。插件也提供ItemRestriction脚本允许你设计自定义逻辑，来决定能否往某个库存添加/移除道具。
2.你可以通过Buy/SellCondition去自定义玩家能否购买销售某些道具，你也可以使用PriceModier将物品价格动态化。举例（非内内置，但可以拓展实现）：比如你与商人好感度50~100映射为10%~30% off的折扣，你甚至可以通过地区不同去影响价格。
制作系统的文档是空白的，如果该系统已经实现，能否简要解释一下它的工作原理？
1.制作系统代码基本完成，但还未测试。会在后续版本更新。
2.大致思路是：带有CraftingRecipe Fragment的道具，就是配方。配方支持你选择其它道具定义，以及货币作为输入，并将另外的其它道具作为输出。
你可以制作一个道具叫做：Item_Recipe_GreatSword，然后将2个Item_Weapon_Sword作为输入，产出一个Item_Weapon_GreatSword。
CraftingSystemComponent这个组件负责实际的逻辑，消耗配方，扣除Input，创建Output并将新道具加入玩家的库存。