-
Notifications
You must be signed in to change notification settings - Fork 4
Overview
The purpose of FMGInvSys plugin is to provide a reasonably robust inventory system. The uniquely flexible item combinations and item widget setup are where it shines, but it also tries to provide other useful implementations such as an inventory menu, a character, and so on.
The plugin's C++ code is located under <YourProjectName>/Plugins/FMGInvSys-master/Source/FMGInvSys/. The header files are in Public/, and the .cpp files are in Private/. The plugin's C++ classes are mostly organized in files of the same names. E.g. The C++ class UFMGInvSysInventory can be found in FMGInvSysInventory.h and FMGInvSysInventory.cpp.
The plugin's blueprint classes can be accessed in the editor's Content Browser, under FMGInvSys Content.
The plugin can be divided into 2 parts.
The integral part has things like the item classes, the inventory class, the classes that make up the inventory menu, and the item combiner. These are "integral" because item, inventory, and inventory menu are what people expect from an inventory system.
The prototypes is FMGInvSys's attempt to bring further convenience to the user, beyond the scope of an inventory system. It has things like a character class, a game mode, and a player controller. Here is a brief description of them. The prototypes represent one way of how FMGInvSys can be used. But the reality is, they probably won't fit your project completely, or meet all its needs.
It's temping to just use and modify FMGInvSys's prototypes directly. But the tricky part comes when you update the plugin, if you ever need to. Updating a plugin in Unreal is done by removing the entirety of the old plugin directory under Plugins/, and swapping in the new one. If you've made any modifications to the plugin directly, they will be lost. The same challenge exists if you upgrade your Unreal Engine version, which likely requires a plugin build for the newer engine version. Read on for various strategies to resolve this.
So if you plan to never update the plugin or the engine for your project1, you can use and modify the plugin however you want. But if you do anticipate updates, there are different strategies to use this plugin effectively.
A blueprint can be considered as a final concrete implementation. If you find a blueprint from the plugin to be exactly what you want, you can just use it as is. An example is FMGInvSys's "item clicker" blueprint WBP_FMGInvSysItemClicker, which is a pretty standard way of how an item should look and behave in the inventory menu.
When you're starting out, maybe you should always try this option when you can, because it can quickly give you an idea of how things work, whether to modify something, and what to modify.
More commonly, you may like the plugin's C++ implementation of some mechanics, but don't want the final blueprint. An example is the inventory menu. You may not like the visual setup of FMGInvSys's in WBP_FMGInvSysInventoryMenu. So you can simply make a blueprint that inherits from the C++ class UFMGInvSysInventoryMenu, add in the essential widgets, and lay them out the way you like it.
More conveniently, you can make a copy of WBP_FMGInvSysInventoryMenu outside of the plugin. This is effectively creating a blueprint subclass of UFMGInvSysInventoryMenu, while having FMGInvSys's layout as a starting point.
This is typical for the prototypes. For example, you may already have a character class. In this case you are expected to programme your character class to FMGInvSys's interfaces, rather than to use FMGInvSys's character. This is even more so the case for FMGInvSys's player controller and game mode.
This option is good only under one of these conditions:
- You don't plan to update the plugin or the engine.
- You are willing to re-apply your modification to the newer plugin.
- You are prototyping and want to see immediate results.
1 This is not uncommon in game dev.