# Table of Contents - [Welcome to IFP | Inventory Framework | Varian's Documentation](#welcome-to-ifp-inventory-framework-varian-s-documentation) - [Tags Metadata | Varian's Documentation](#tags-metadata-varian-s-documentation) - [Tag Facts | Varian's Documentation](#tag-facts-varian-s-documentation) - [Integrations | Tag Facts | Varian's Documentation](#integrations-tag-facts-varian-s-documentation) - [ImGui (Cog) setup | Varian's Documentation](#imgui-cog-setup-varian-s-documentation) - [Cog's presence detection | ImGui (Cog) setup | Varian's Documentation](#cog-s-presence-detection-imgui-cog-setup-varian-s-documentation) - [Enabling the ImGui debuggers | ImGui (Cog) setup | Varian's Documentation](#enabling-the-imgui-debuggers-imgui-cog-setup-varian-s-documentation) - [Cog | Object Tags | Varian's Documentation](#cog-object-tags-varian-s-documentation) - [Object Tags | Varian's Documentation](#object-tags-varian-s-documentation) - [Changelog | Object Tags | Varian's Documentation](#changelog-object-tags-varian-s-documentation) - [Task Graphs | Blueprint Tasks Extension | Varian's Documentation](#task-graphs-blueprint-tasks-extension-varian-s-documentation) - [Blueprint Tasks Extension | Varian's Documentation](#blueprint-tasks-extension-varian-s-documentation) - [Decorator | Blueprint Tasks Extension | Varian's Documentation](#decorator-blueprint-tasks-extension-varian-s-documentation) - [Decorator | Blueprint Tasks Extension | Varian's Documentation](#decorator-blueprint-tasks-extension-varian-s-documentation) - [Dialogue | Blueprint Tasks Extension | Varian's Documentation](#dialogue-blueprint-tasks-extension-varian-s-documentation) - [Who am I? | Varian's Documentation](#who-am-i-varian-s-documentation) - [Quests | Blueprint Tasks Extension | Varian's Documentation](#quests-blueprint-tasks-extension-varian-s-documentation) - [Other nodes | Blueprint Tasks Extension | Varian's Documentation](#other-nodes-blueprint-tasks-extension-varian-s-documentation) - [Warmup Pool | Object Recycler | Varian's Documentation](#warmup-pool-object-recycler-varian-s-documentation) - [My design style | Varian's Documentation](#my-design-style-varian-s-documentation) - [Suggested Plugins | Varian's Documentation](#suggested-plugins-varian-s-documentation) - [Cog | Object Recycler | Varian's Documentation](#cog-object-recycler-varian-s-documentation) - [Object Recycler | Varian's Documentation](#object-recycler-varian-s-documentation) - [Welcome to Input Nexus | Input Nexus | Varian's Documentation](#welcome-to-input-nexus-input-nexus-varian-s-documentation) - [Cog | Input Nexus | Varian's Documentation](#cog-input-nexus-varian-s-documentation) - [Changelog | Input Nexus | Varian's Documentation](#changelog-input-nexus-varian-s-documentation) - [Nexus Component | Input Nexus | Varian's Documentation](#nexus-component-input-nexus-varian-s-documentation) - [Link Bundle | Input Nexus | Varian's Documentation](#link-bundle-input-nexus-varian-s-documentation) - [Input Buffer | Input Nexus | Varian's Documentation](#input-buffer-input-nexus-varian-s-documentation) - [To-do | Input Nexus | Varian's Documentation](#to-do-input-nexus-varian-s-documentation) - [Welcome | Varian's Documentation](#welcome-varian-s-documentation) - [Input Link | Input Nexus | Varian's Documentation](#input-link-input-nexus-varian-s-documentation) - [OmniToolbox | Varian's Documentation](#omnitoolbox-varian-s-documentation) - [Todo | OmniToolbox | Varian's Documentation](#todo-omnitoolbox-varian-s-documentation) - [Macros | OmniToolbox | Varian's Documentation](#macros-omnitoolbox-varian-s-documentation) - [Macros | OmniToolbox | Varian's Documentation](#macros-omnitoolbox-varian-s-documentation) - [Documentation button | OmniToolbox | Varian's Documentation](#documentation-button-omnitoolbox-varian-s-documentation) - [Content Browser | OmniToolbox | Varian's Documentation](#content-browser-omnitoolbox-varian-s-documentation) - [Installing the plugin | Inventory Framework | Varian's Documentation](#installing-the-plugin-inventory-framework-varian-s-documentation) - [Thumbnail Renderer | OmniToolbox | Varian's Documentation](#thumbnail-renderer-omnitoolbox-varian-s-documentation) - [Asset Manager | Inventory Framework | Varian's Documentation](#asset-manager-inventory-framework-varian-s-documentation) - [Adding the component and containers | Inventory Framework | Varian's Documentation](#adding-the-component-and-containers-inventory-framework-varian-s-documentation) - [Debug Draw system | OmniToolbox | Varian's Documentation](#debug-draw-system-omnitoolbox-varian-s-documentation) - [Place Actor Palette control | OmniToolbox | Varian's Documentation](#place-actor-palette-control-omnitoolbox-varian-s-documentation) - [Libraries | OmniToolbox | Varian's Documentation](#libraries-omnitoolbox-varian-s-documentation) - [Hiding properties | OmniToolbox | Varian's Documentation](#hiding-properties-omnitoolbox-varian-s-documentation) - [Activating the component | Inventory Framework | Varian's Documentation](#activating-the-component-inventory-framework-varian-s-documentation) - [Unknown](#unknown) - [Float Providers | OmniToolbox | Varian's Documentation](#float-providers-omnitoolbox-varian-s-documentation) - [Introduction | Inventory Framework | Varian's Documentation](#introduction-inventory-framework-varian-s-documentation) - [Asset Validation | OmniToolbox | Varian's Documentation](#asset-validation-omnitoolbox-varian-s-documentation) - [Custom Interaction system | Inventory Framework | Varian's Documentation](#custom-interaction-system-inventory-framework-varian-s-documentation) - [First Steps | Inventory Framework | Varian's Documentation](#first-steps-inventory-framework-varian-s-documentation) - [Suggested Plugins | Inventory Framework | Varian's Documentation](#suggested-plugins-inventory-framework-varian-s-documentation) - [Example Project | Inventory Framework | Varian's Documentation](#example-project-inventory-framework-varian-s-documentation) - [Unknown](#unknown) - [Structure and contribution | OmniToolbox | Varian's Documentation](#structure-and-contribution-omnitoolbox-varian-s-documentation) - [World Settings and actions | OmniToolbox | Varian's Documentation](#world-settings-and-actions-omnitoolbox-varian-s-documentation) - [Spreadsheet Object | OmniToolbox | Varian's Documentation](#spreadsheet-object-omnitoolbox-varian-s-documentation) - [0.1 | OmniToolbox | Varian's Documentation](#0-1-omnitoolbox-varian-s-documentation) - [0.3 | OmniToolbox | Varian's Documentation](#0-3-omnitoolbox-varian-s-documentation) - [Test Environment | Inventory Framework | Varian's Documentation](#test-environment-inventory-framework-varian-s-documentation) - [0.2 | OmniToolbox | Varian's Documentation](#0-2-omnitoolbox-varian-s-documentation) - [Style Guide | Inventory Framework | Varian's Documentation](#style-guide-inventory-framework-varian-s-documentation) - [Functional Tests | OmniToolbox | Varian's Documentation](#functional-tests-omnitoolbox-varian-s-documentation) - [Versions | OmniToolbox | Varian's Documentation](#versions-omnitoolbox-varian-s-documentation) - [How does the system work? | Inventory Framework | Varian's Documentation](#how-does-the-system-work-inventory-framework-varian-s-documentation) - [Test Environment Guide | OmniToolbox | Varian's Documentation](#test-environment-guide-omnitoolbox-varian-s-documentation) - [Introduction | OmniToolbox | Varian's Documentation](#introduction-omnitoolbox-varian-s-documentation) - [Tools | Inventory Framework | Varian's Documentation](#tools-inventory-framework-varian-s-documentation) - [Inventory Helper | Inventory Framework | Varian's Documentation](#inventory-helper-inventory-framework-varian-s-documentation) - [Item Editor | Inventory Framework | Varian's Documentation](#item-editor-inventory-framework-varian-s-documentation) - [Bugs | Inventory Framework | Varian's Documentation](#bugs-inventory-framework-varian-s-documentation) - [A_ItemActor | Inventory Framework | Varian's Documentation](#a-itemactor-inventory-framework-varian-s-documentation) - [F.A.Q | Inventory Framework | Varian's Documentation](#f-a-q-inventory-framework-varian-s-documentation) - [Classes and Settings | Inventory Framework | Varian's Documentation](#classes-and-settings-inventory-framework-varian-s-documentation) - [How does the networking work? | Inventory Framework | Varian's Documentation](#how-does-the-networking-work-inventory-framework-varian-s-documentation) - [W_Attachment Parent | Inventory Framework | Varian's Documentation](#w-attachment-parent-inventory-framework-varian-s-documentation) - [W_Highlight | Inventory Framework | Varian's Documentation](#w-highlight-inventory-framework-varian-s-documentation) - [AC_Inventory | Inventory Framework | Varian's Documentation](#ac-inventory-inventory-framework-varian-s-documentation) - [WBP_ContextMenu | Inventory Framework | Varian's Documentation](#wbp-contextmenu-inventory-framework-varian-s-documentation) - [W_Container | Inventory Framework | Varian's Documentation](#w-container-inventory-framework-varian-s-documentation) - [Traits and Components | Inventory Framework | Varian's Documentation](#traits-and-components-inventory-framework-varian-s-documentation) - [W_InventoryItem | Inventory Framework | Varian's Documentation](#w-inventoryitem-inventory-framework-varian-s-documentation) - [External Objects | Inventory Framework | Varian's Documentation](#external-objects-inventory-framework-varian-s-documentation) - [W_Tile | Inventory Framework | Varian's Documentation](#w-tile-inventory-framework-varian-s-documentation) - [W_Drag | Inventory Framework | Varian's Documentation](#w-drag-inventory-framework-varian-s-documentation) - [Systems | Inventory Framework | Varian's Documentation](#systems-inventory-framework-varian-s-documentation) - [BP_PreviewActor | Inventory Framework | Varian's Documentation](#bp-previewactor-inventory-framework-varian-s-documentation) - [Item Sockets | Inventory Framework | Varian's Documentation](#item-sockets-inventory-framework-varian-s-documentation) - [Adding new items during runtime | Inventory Framework | Varian's Documentation](#adding-new-items-during-runtime-inventory-framework-varian-s-documentation) - [Crafting | Inventory Framework | Varian's Documentation](#crafting-inventory-framework-varian-s-documentation) - [Saving and loading | Inventory Framework | Varian's Documentation](#saving-and-loading-inventory-framework-varian-s-documentation) - [Creating new items | Inventory Framework | Varian's Documentation](#creating-new-items-inventory-framework-varian-s-documentation) - [Tags and Tag Values | Inventory Framework | Varian's Documentation](#tags-and-tag-values-inventory-framework-varian-s-documentation) - [Sorting Items | Inventory Framework | Varian's Documentation](#sorting-items-inventory-framework-varian-s-documentation) - [Drag and drop | Inventory Framework | Varian's Documentation](#drag-and-drop-inventory-framework-varian-s-documentation) - [Modifying Critical Files | Inventory Framework | Varian's Documentation](#modifying-critical-files-inventory-framework-varian-s-documentation) - [Setting up vendors | Inventory Framework | Varian's Documentation](#setting-up-vendors-inventory-framework-varian-s-documentation) - [Compatibility Settings | Inventory Framework | Varian's Documentation](#compatibility-settings-inventory-framework-varian-s-documentation) - [Tile Tags | Inventory Framework | Varian's Documentation](#tile-tags-inventory-framework-varian-s-documentation) - [Fragments | Inventory Framework | Varian's Documentation](#fragments-inventory-framework-varian-s-documentation) - [WBP_Tooltip | Inventory Framework | Varian's Documentation](#wbp-tooltip-inventory-framework-varian-s-documentation) - [Working in the system | Inventory Framework | Varian's Documentation](#working-in-the-system-inventory-framework-varian-s-documentation) - [Templates for inventory and containers | Inventory Framework | Varian's Documentation](#templates-for-inventory-and-containers-inventory-framework-varian-s-documentation) - [Item Query | Inventory Framework | Varian's Documentation](#item-query-inventory-framework-varian-s-documentation) - [Creating custom functions | Inventory Framework | Varian's Documentation](#creating-custom-functions-inventory-framework-varian-s-documentation) - [Creating custom widgets | Inventory Framework | Varian's Documentation](#creating-custom-widgets-inventory-framework-varian-s-documentation) - [Loot Tables | Inventory Framework | Varian's Documentation](#loot-tables-inventory-framework-varian-s-documentation) - [Ability System Integration | Inventory Framework | Varian's Documentation](#ability-system-integration-inventory-framework-varian-s-documentation) - [UI Navigation | Inventory Framework | Varian's Documentation](#ui-navigation-inventory-framework-varian-s-documentation) - [Optimizations | Inventory Framework | Varian's Documentation](#optimizations-inventory-framework-varian-s-documentation) - [Equipping and unequipping items | Inventory Framework | Varian's Documentation](#equipping-and-unequipping-items-inventory-framework-varian-s-documentation) - [DA_CoreItem | Inventory Framework | Varian's Documentation](#da-coreitem-inventory-framework-varian-s-documentation) - [3.0 | Inventory Framework | Varian's Documentation](#3-0-inventory-framework-varian-s-documentation) - [1.1.1 | Inventory Framework | Varian's Documentation](#1-1-1-inventory-framework-varian-s-documentation) - [2.7.1 | Inventory Framework | Varian's Documentation](#2-7-1-inventory-framework-varian-s-documentation) - [1.2.0 | Inventory Framework | Varian's Documentation](#1-2-0-inventory-framework-varian-s-documentation) - [2.1.0 | Inventory Framework | Varian's Documentation](#2-1-0-inventory-framework-varian-s-documentation) - [2.8.1 | Inventory Framework | Varian's Documentation](#2-8-1-inventory-framework-varian-s-documentation) - [2.0.1 | Inventory Framework | Varian's Documentation](#2-0-1-inventory-framework-varian-s-documentation) - [Versions | Inventory Framework | Varian's Documentation](#versions-inventory-framework-varian-s-documentation) - [1.0.0 | Inventory Framework | Varian's Documentation](#1-0-0-inventory-framework-varian-s-documentation) - [3.4 | Inventory Framework | Varian's Documentation](#3-4-inventory-framework-varian-s-documentation) - [2.4.0 | Inventory Framework | Varian's Documentation](#2-4-0-inventory-framework-varian-s-documentation) - [2.10.1 | Inventory Framework | Varian's Documentation](#2-10-1-inventory-framework-varian-s-documentation) - [2.5.1 | Inventory Framework | Varian's Documentation](#2-5-1-inventory-framework-varian-s-documentation) - [3.3.1 | Inventory Framework | Varian's Documentation](#3-3-1-inventory-framework-varian-s-documentation) - [3.2.2 | Inventory Framework | Varian's Documentation](#3-2-2-inventory-framework-varian-s-documentation) - [2.3.0 | Inventory Framework | Varian's Documentation](#2-3-0-inventory-framework-varian-s-documentation) - [2.6.0 | Inventory Framework | Varian's Documentation](#2-6-0-inventory-framework-varian-s-documentation) - [3.1 | Inventory Framework | Varian's Documentation](#3-1-inventory-framework-varian-s-documentation) - [2.2.0 | Inventory Framework | Varian's Documentation](#2-2-0-inventory-framework-varian-s-documentation) - [2.9.0 | Inventory Framework | Varian's Documentation](#2-9-0-inventory-framework-varian-s-documentation) - [2.11 | Inventory Framework | Varian's Documentation](#2-11-inventory-framework-varian-s-documentation) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) - [Unknown](#unknown) --- # Welcome to IFP | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/welcome-to-ifp.md) . * * * [Marketplace](https://www.fab.com/listings/a936148d-d2c2-4795-9de7-e7cf8ebb9bdd) | [Youtube](https://www.youtube.com/@VarianDaemon_) | [Discord](https://discord.com/invite/bBfa9pwtEn) | [Trello](https://trello.com/b/pE2DJRlb/inventory-framework-plugin) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework#what-is-the-inventory-framework-plugin) What is the Inventory Framework Plugin? ------------------------------------------------------------------------------------------------------------------------------------------------ Nearly every inventory system shares the same foundation, a container with tiles and items slot into those tiles. This Inventory Framework Plugin (IFP) attempts to be that foundation for your project, while allowing for a high level of inventory design, item customization, rapid prototyping and system integration. From my research, inventory systems were taking 2-6 months or more (depending on how advanced it was) to be designed, bug tested, network tested and to be documented. With this framework, I try to provide you the framework needed to create your perfect inventory system and bring that initial creation time down. What this provides is the C++ foundation for your programmers and a good Blueprint foundation for your designers, which includes: 1. Actor components and item parents that handle all the logic for you and are abstract enough so you can implement your mechanics and systems into it. 2. Perhaps the most network optimized inventory system on the marketplace. 3. Only inventory system on the marketplace with custom shaped items. 4. Widgets that are designer friendly (Easy to implement new logic, add animations to events, create children, etc). They also handle all the drag, drop, highlighting, splitting, combining logic and more. Unlike many other assets, widgets in IFP are highly customizable and have very few limits, allowing you to easily customize your inventories visuals. 5. A system that has no reliance on widgets to create or handle its data, meaning everything you need to know about an item is always accessible in a highly performant manner. 6. Recursive items, meaning items inside of items for as long as you want. 7. Actor appearance duplication system that copies the appearance of your items allowing you to both inspect items and auto-generate icons. It works with all actors, not just item actors. No longer do you need to follow a strict actor hierarchy setup like many other inventory systems need. You can create your items and actors however you want and the system will automatically duplicate the appearance for either generating item icons or letting you examine an item. 8. Powerful in-game and in-editor tools to improve quality control and speed up workflow. It is NOT an inventory to fully replicate the mechanics of any specific game. If you want your system to behave like a specific game. This framework provides you with the functions, data and systems to replicate most inventory systems. If you have any issues or questions neither the videos or documentation answer then feel free to message me on Discord (Variandaemon) or join the discord channel. You can look at the FAQ for more info. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework#color-sheet) Color Sheet: ------------------------------------------------------------------------------------------ **functions** - **variable** \- **category** \- **class** [NextIntroduction](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction) Last updated 1 month ago --- # Tags Metadata | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/tagsmetadata/tags-metadata.md) . A simple config system which stores metadata for tags inside `collections`. `O_TagMetadataCollection`: This is the class that hosts a collection of metadata Example: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F85507437-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fk78LHfXaaau9UrBYk0Pe%252Fuploads%252FwelrdvPmYV6V2O1YJ9Kj%252Fimage.png%3Falt%3Dmedia%26token%3Da66d4f2e-0312-4342-9645-a743ef6e9dba&width=768&dpr=3&quality=100&sign=fcd8951&sv=2) To have the system pick up your collection, go into `Project Settings` -> `Plugins` -> `TagMetadata Settings` and add your collection to the array. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F85507437-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fk78LHfXaaau9UrBYk0Pe%252Fuploads%252Fxzf1OeY0j6nvxUM4kYhm%252Fimage.png%3Falt%3Dmedia%26token%3Dba3a60d8-963c-4e3b-89a8-df29bf1b1b19&width=768&dpr=3&quality=100&sign=8491e848&sv=2) `O_TagMetadata`: The object that is added to the tags Metadata array to grant the tag whatever data you want to add. Example: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F85507437-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fk78LHfXaaau9UrBYk0Pe%252Fuploads%252FuwIGwLUIxJWymuMIDxyV%252Fimage.png%3Falt%3Dmedia%26token%3Dc2b2a23f-4245-4ec0-b30a-db30c2fbd462&width=768&dpr=3&quality=100&sign=9c35772c&sv=2) The system comes with three functions to retrieve the metadata: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F85507437-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fk78LHfXaaau9UrBYk0Pe%252Fuploads%252FeMLImEEZCeT8awWRr4tP%252Fimage.png%3Falt%3Dmedia%26token%3Dddc0aafb-e3ae-4007-8093-95c4b71398c9&width=768&dpr=3&quality=100&sign=5840cf88&sv=2) Example to retrieve the metadata: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F85507437-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fk78LHfXaaau9UrBYk0Pe%252Fuploads%252FWEvaOMhHQQKnWoGskF10%252Fimage.png%3Falt%3Dmedia%26token%3D98ecd822-369c-4e3c-b7a9-b36fb207d299&width=768&dpr=3&quality=100&sign=4e0905c0&sv=2) [](https://varian.gitbook.io/varian-docs/tagsmetadata#notes) Notes ----------------------------------------------------------------------- * All of the collections are hard referenced by the config, meaning they are loaded at all times. Be very mindful of what assets you are referencing and always use a soft reference. * This system is meant for fixed variables, modifying any variables on the metadata objects during runtime is not recommended. [](https://varian.gitbook.io/varian-docs/tagsmetadata#base-classes) Base Classes ------------------------------------------------------------------------------------- * `O_TagMetadata` - The metadata object that will host your custom data. * `O_TagMetadataCollection` - The collection that hosts the metadata objects and associates them with a tag. [](https://varian.gitbook.io/varian-docs/tagsmetadata#change-log) Change log: ---------------------------------------------------------------------------------- ### [](https://varian.gitbook.io/varian-docs/tagsmetadata#id-1.2) 1.2 * Collections are now soft referenced. Note, the functions will instantly load a collection if it isn't loaded. So use async load first. for optimal streaming. ### [](https://varian.gitbook.io/varian-docs/tagsmetadata#id-1.1) 1.1 * Collections now prevent identical tags. * Added editor utility widget. * Added `EditorAssistant` support Last updated 1 year ago --- # Tag Facts | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/tag-facts/tag-facts.md) . `TagFacts` is a simple subsystem storing a fact database. This database is a simple TSet of a gameplay tag and an integer. `TagFacts` is a free plugin available on my [**ModularityPractice github repo**](https://github.com/Variann/ModularityPractice) Fact systems is extremely common in game studios as it provides an extremely simple interface for handling facts and achievements. This can be used to track what quests have been completed, how many times a player has talked to an NPC or any other "fact" you'd like to keep track of. There are only a handful of functions you'll end up using majority of the time. The highlights are: * IncrementFact * DoesFactExist * GetFactValue The other functions are very situational. But when it comes to fact databases, the above functions are the most commonly used. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F1189842449-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FGjNOeFzjjRbJR8VE6VXy%252Fuploads%252FiDAiLddmeI4tvsn3vNQi%252Fimage.png%3Falt%3Dmedia%26token%3D9b9ed472-e895-4f02-8986-d1c12b0d4b7f&width=768&dpr=3&quality=100&sign=19024941&sv=2) It also comes with console commands. `SetFact` will allow you to set the value of a tag during runtime, but it's recommended to use the [Integrations](https://varian.gitbook.io/varian-docs/tag-facts/integrations) debugger instead. [NextIntegrations](https://varian.gitbook.io/varian-docs/tag-facts/integrations) Last updated 1 year ago --- # Integrations | Tag Facts | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/tag-facts/integrations.md) . [](https://varian.gitbook.io/varian-docs/tag-facts/integrations#cog) Cog ----------------------------------------------------------------------------- `TagFacts` comes with a `Cog` debugger out of the box. This debugger allows you to increment and decrement facts at runtime. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F1189842449-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FGjNOeFzjjRbJR8VE6VXy%252Fuploads%252FaWCbhzsXKeGoZ66uckIG%252Fimage.png%3Falt%3Dmedia%26token%3D801e61e0-26a6-43be-b937-b11b8214501b&width=768&dpr=3&quality=100&sign=432df9b1&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F1189842449-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FGjNOeFzjjRbJR8VE6VXy%252Fuploads%252FustOBW2gDXdBFiTVpBo4%252Fimage.png%3Falt%3Dmedia%26token%3De4b8ed49-089f-44e5-aed9-0b311fb8fe9d&width=768&dpr=3&quality=100&sign=10df613c&sv=2) * * * [](https://varian.gitbook.io/varian-docs/tag-facts/integrations#hermes) Hermes ----------------------------------------------------------------------------------- The fact subsystem will automatically broadcast a `FFactMessage` message on the same channel as the fact when it's added, increment, decrement or removed. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F1189842449-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FGjNOeFzjjRbJR8VE6VXy%252Fuploads%252FWGLObg9MQASvl4ohHgfq%252Fimage.png%3Falt%3Dmedia%26token%3Dba6a8f3b-89e5-4109-b837-6867b59c8ac6&width=768&dpr=3&quality=100&sign=b081e42b&sv=2) [PreviousTag Facts](https://varian.gitbook.io/varian-docs/tag-facts) Last updated 1 year ago --- # ImGui (Cog) setup | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/imgui-cog-setup/imgui-cog-setup.md) . Most of my plugins come with debugging tools built with ImGui. The most popular ImGui solution seems to be [Cog](https://github.com/arnaud-jamin/Cog) , which I believe is the most mature solution (as of writing). That's why I have standardized all my ImGui debugging tools with this plugin. Cog is NOT required to be installed to install any of my plugins. My plugins use [preprocessor macro's to detect if Cog is installed](https://varian.gitbook.io/varian-docs/imgui-cog-setup/cogs-presence-detection) . If it is, then enable Cog related code. If it isn't, disable it and your IDE and compiler will ignore it. This documentation will cover how to use it and how my code is automatically enabled or disabled depending on this plugins presence. [NextCog's presence detection](https://varian.gitbook.io/varian-docs/imgui-cog-setup/cogs-presence-detection) Last updated 1 year ago --- # Cog's presence detection | ImGui (Cog) setup | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/imgui-cog-setup/cogs-presence-detection.md) . We will use my [ObjectTags](https://varian.gitbook.io/varian-docs/object-tags) plugin as an example. Inside of the `build.cs` file, you'll find this code: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F4281265215-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHMyo485jJ75PBKbKwjZt%252Fuploads%252FjMOCHyLDNK6CPcfjutbH%252Fimage.png%3Falt%3Dmedia%26token%3Dd4dff862-5d03-4841-912e-83659d64a9a3&width=768&dpr=3&quality=100&sign=2236ba28&sv=2) This code will enable or disable the `COG_INSTALLED` preprocessor macro depending of the `Cog` plugin can be found inside the `Plugins` folder and add it as a dependency if it's found. This setup enables us to write Cog dependend code, which is disabled and ignored by the IDE and compiler if the Cog plugin is disabled. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F4281265215-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHMyo485jJ75PBKbKwjZt%252Fuploads%252FkohLJ9LUCZxIUbsvCBkS%252Fimage.png%3Falt%3Dmedia%26token%3D9820396d-67c3-4c14-9874-f4d3ab2a7315&width=768&dpr=3&quality=100&sign=b80e8e7f&sv=2) In the code example above, if Cog is missing, the code will automatically be disabled and not recognized by the IDE. Thus, not causing any errors and allowing you to continue using the plugin. It's important you do `COG_INSTALLED` first. The compiler is smart enough that if it sees `COG_INSTALLED` as false, it won't bother to check `ENABLE_COG`, which in the case of Cog not being installed, would result in an error. But since `COG_INSTALLED` returns false before `ENABLE_COG`, the compiler immediately strips it out and doesn't bother checking it. If the checks are reversed, you'll get an error saying `ENABLE_COG` is undefined if Cog is ever uninstalled. In some cases, you might have to wrap `#include`'s with the `#if COG_INSTALLED` preprocessor macro, then use `#if ENABLE_COG`. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F4281265215-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHMyo485jJ75PBKbKwjZt%252Fuploads%252FeOZGFCILGeNucQJ8I1cO%252Fimage.png%3Falt%3Dmedia%26token%3D1edf04b6-6ddf-4109-8f80-b78b987e3138&width=768&dpr=3&quality=100&sign=2f324ffa&sv=2) [PreviousImGui (Cog) setup](https://varian.gitbook.io/varian-docs/imgui-cog-setup) [NextEnabling the ImGui debuggers](https://varian.gitbook.io/varian-docs/imgui-cog-setup/enabling-the-imgui-debuggers) Last updated 1 year ago --- # Enabling the ImGui debuggers | ImGui (Cog) setup | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/imgui-cog-setup/enabling-the-imgui-debuggers.md) . Depending on how you manager your windows or if you're using a global window manager, you'll need to call `AddWindow` for the plugins Cog window class. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F4281265215-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHMyo485jJ75PBKbKwjZt%252Fuploads%252FrEiWSa4U7C0gyvAaQosE%252Fimage.png%3Falt%3Dmedia%26token%3D9db7a4b4-3891-473b-bd23-d0cf20a9ae8b&width=768&dpr=3&quality=100&sign=39c8e96f&sv=2) All debuggers can be found in a `Cog` folder inside every plugin/module. [PreviousCog's presence detection](https://varian.gitbook.io/varian-docs/imgui-cog-setup/cogs-presence-detection) Last updated 1 year ago --- # Cog | Object Tags | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/object-tags/cog.md) . `ObjectTags` provides a `Cog` debugger out of the box that supports its `Selection` system. It allows you to make modifications to an objects tags value and its duration during runtime. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F2777676461-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjP5XAKMs1xUM2psZ0ZK9%252Fuploads%252F4wEpP19a6whDydXvPEkR%252Fimage.png%3Falt%3Dmedia%26token%3Dced45dc8-c457-44cf-9bfe-fb9d81c37fb7&width=768&dpr=3&quality=100&sign=ada2bda7&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F2777676461-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjP5XAKMs1xUM2psZ0ZK9%252Fuploads%252FgzVPoTBcl1Pu9CWpObme%252Fimage.png%3Falt%3Dmedia%26token%3Dfa935077-1dc9-4411-9084-612c20bc4ae8&width=768&dpr=3&quality=100&sign=8caece8a&sv=2) [PreviousObject Tags](https://varian.gitbook.io/varian-docs/object-tags) [NextChangelog](https://varian.gitbook.io/varian-docs/object-tags/changelog) Last updated 1 year ago --- # Object Tags | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/object-tags/object-tags.md) . A simple subsystem that allows you to add a tag to any object. This includes actors, widgets, everything that derives from `UObject` can have a tag! You can add/remove tags through the regular `AddTagsToObject` or `RemoveTagsFromObject`function. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F2777676461-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjP5XAKMs1xUM2psZ0ZK9%252Fuploads%252FEumro3XqTzlU40LlBmCi%252Fimage.png%3Falt%3Dmedia%26token%3Dd4397740-9e2d-4e50-87d4-e15f2c213008&width=768&dpr=3&quality=100&sign=4dd21627&sv=2) You can also use `TagRelationship`'s to create tags that are incompatible with each other. Such as a `Alive` tag automatically being removed if a `Dead` tag is applied. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2Fgithub.com%2FVariann%2FModularityPractice%2Fassets%2F6917153%2F17a1f573-b64e-4623-86bb-db82cfd8578d&width=768&dpr=3&quality=100&sign=f9f93568&sv=2) image * The system also comes with a `Listener` system, which allows other objects to trigger gameplay logic when another objects tags are updated. * There is a `TagHistory` system meant for development and aid debugging to help identify who added/removed tags for itself or another object. [](https://varian.gitbook.io/varian-docs/object-tags#base-classes) Base Classes ------------------------------------------------------------------------------------ * O\_TagRelationship - Relationship class to associate a relationship between a tag and other tags. [](https://varian.gitbook.io/varian-docs/object-tags#gas-integration) GAS integration ------------------------------------------------------------------------------------------ The plugin already automatically adds any tags you add as a LooseGameplayTag to the target if it is an actor and has a Ability component, but not the other way around. This way, whenever you try to activate an ability and it has a `BlockingTag` or `RequiredTags`, then it'll automatically have the tag you added to the actor through the subsystem. To have the subsystem pick up any tags that GAS applies, you will want to make your own `ASC` component and override the `OnTagUpdated` function and implement this logic: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2Fgithub.com%2FVariann%2FModularityPractice%2Fassets%2F6917153%2Febded181-7560-4e99-9941-57fb73c57d51&width=768&dpr=3&quality=100&sign=cd65831f&sv=2) image ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2Fgithub.com%2FVariann%2FModularityPractice%2Fassets%2F6917153%2Fb4251317-c7df-4b67-b2f1-2f2e87442dc7&width=768&dpr=3&quality=100&sign=fb6201&sv=2) image This setup will ensure that abilities, effects and any other components of `GAS` will update the `ObjectTags` subsystem. Though this won't handle `TagRelationship`'s, you'll have to integrate that yourself or manage the tags in a way to not include tags that might be in a complicated relationship. [](https://varian.gitbook.io/varian-docs/object-tags#performance) Performance ---------------------------------------------------------------------------------- Virtually free. Inclusive call average costs: * `GetObjectTags` - 12k calls, average time: 1.6 microseconds * `AddTagToObject` - 9k calls, average time: 1.7 microseconds * `RemoveTagsFromObject` - 9k calls, average time: 0.5 microseconds [](https://varian.gitbook.io/varian-docs/object-tags#debugging) Debugging ------------------------------------------------------------------------------ ### [](https://varian.gitbook.io/varian-docs/object-tags#console-commands) Console commands * `AddTag` and `AddTagToPlayer` : Adds a tag to the actor in front of the camera or the player. This accepts 2 optional floats. A value to assign to the tag, and a duration. * `RemoveTag` and `RemoveTagFromPlayer` : Remove a tag from the actor in front of the camera or the player. * `ToggleViewActorTags` : Toggle drawing text over all actors in the level with their tags. ### [](https://varian.gitbook.io/varian-docs/object-tags#cog) Cog This section implies that you have a basic `Cog` plugin setup. * The `ObjectTags` window debugger class is called `FCogObjectTagsWindow`. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F2777676461-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjP5XAKMs1xUM2psZ0ZK9%252Fuploads%252Fjfi9csZeac35UYxgiWsn%252Fimage.png%3Falt%3Dmedia%26token%3D6330ad6f-bebc-4076-a0df-eada24b83ec0&width=768&dpr=3&quality=100&sign=95242cf6&sv=2) [NextCog](https://varian.gitbook.io/varian-docs/object-tags/cog) Last updated 1 year ago * [Base Classes](https://varian.gitbook.io/varian-docs/object-tags#base-classes) * [GAS integration](https://varian.gitbook.io/varian-docs/object-tags#gas-integration) * [Performance](https://varian.gitbook.io/varian-docs/object-tags#performance) * [Debugging](https://varian.gitbook.io/varian-docs/object-tags#debugging) * [Console commands](https://varian.gitbook.io/varian-docs/object-tags#console-commands) * [Cog](https://varian.gitbook.io/varian-docs/object-tags#cog) --- # Changelog | Object Tags | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/object-tags/changelog.md) . ### [](https://varian.gitbook.io/varian-docs/object-tags/changelog#id-1.4) 1.4 * Added Cog debugger * Added categories to all properties * Added popup modal when starting the engine to guide users to the documentation ### [](https://varian.gitbook.io/varian-docs/object-tags/changelog#id-1.3) 1.3 * Added console commands to add/remove tags * On-Screen debugger overlay to display the tags of an actor over them * State tree tasks and conditions * Vislogger support * Actor component to add default tags to placed actors in a level ### [](https://varian.gitbook.io/varian-docs/object-tags/changelog#id-1.2) 1.2 * Tags can now be applied temporarily with a set timer. * Tags can now have values associated with them. * Subsystem is no longer level bound, meaning it can keep track of tags for objects that aren't destroyed when a new level is loaded, such as the game instance. * Added helper functions for evaluating tag relationships * Added ImGui debugger ### [](https://varian.gitbook.io/varian-docs/object-tags/changelog#id-1.1) 1.1 * `ObjectTags` is now a TMap instead of a TArray. Significantly improving performance in some scenarios. * Improved `ExternalTags` support. * Better `GAS` implementation. [PreviousCog](https://varian.gitbook.io/varian-docs/object-tags/cog) Last updated 1 year ago * [1.4](https://varian.gitbook.io/varian-docs/object-tags/changelog#id-1.4) * [1.3](https://varian.gitbook.io/varian-docs/object-tags/changelog#id-1.3) * [1.2](https://varian.gitbook.io/varian-docs/object-tags/changelog#id-1.2) * [1.1](https://varian.gitbook.io/varian-docs/object-tags/changelog#id-1.1) --- # Task Graphs | Blueprint Tasks Extension | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs.md) . `TaskGraph`'s is a simple concept where a portion of the game is wrapped up into one or several blueprints. For example; the tutorial could be wrapped into a blueprint, where numerous events are tracked through tasks and gameplay events. Some task graphs can become large as they start referencing numerous tasks and potentially assets. This is why it's heavily encouraged to only soft reference task graphs and use the `AsyncActivateTaskGraph`node. By default, you can only create task graphs through this async function to prevent hard reference mistakes. [](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs#examples) Examples ------------------------------------------------------------------------------------------------------ * When an NPC is interacted with, who has branching dialogue, that dialogue can now be hosted and managed inside of a task graph. * The tutorial section might have several areas to teach the player numerous aspects of the game. One task graph could manage the doors, listen for gameplay events. * Task graph's support recursion. So a tutorial task graph could be divided into further task graphs, for example a boss fight at the end of the tutorials Task graph can be placed into a sub Task graph. * Quest chains can be managed nearly entirely within a task graph, creating a space to manage lengthy quest chains. * When a specific NPC is killed, you could start a task graph that now tracks when a player does another specific event, such as walking past an NPC that is related to the one you killed [](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs#modular-game-features) Modular Game Features -------------------------------------------------------------------------------------------------------------------------------- `TaskGraph`'s can be activated through modular game features. Allowing DLC's to create their own `TaskGraph`'s. [PreviousBlueprint Tasks Extension](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension) [NextDialogue](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue) Last updated 1 year ago * [Examples](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs#examples) * [Modular Game Features](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs#modular-game-features) --- # Blueprint Tasks Extension | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/blueprint-tasks-extension.md) . `BTE`(Blueprint Tasks Extension) is a plugin designed to add more nodes and some basic systems to be used alongside `Blueprint Tasks`. This plugin is an extension of [Blueprint Task Forge](https://github.com/CommitAndChill/BlueprintTaskForge) , which is required for this plugin to work. This plugin is free and available for anyone to use on [Github](https://github.com/Variann/BlueprintTasksExtension) [NextTask Graphs](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs) Last updated 11 months ago --- # Decorator | Blueprint Tasks Extension | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue/decorator.md) . The dialogue task decorator provides an example of how to handle images inside a node. [PreviousDialogue](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue) [NextQuests](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests) Last updated 1 year ago --- # Decorator | Blueprint Tasks Extension | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests/decorator.md) . The decorator for the quest node contains an example of retrieving the value of a pin on the node to drive its visuals. Where as usually you'd enable `AllowInstance`and then have the decorator be driven by the instance. But since the quest node is simple enough that it doesn't require an instance, it's far simpler to just retrieve the value of the `QuestAsset`pin. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F209662838-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FKDIkkSbhB2r5Jmh7vwHn%252Fuploads%252FgfgsskFNKcu5olY4m9RE%252Fimage.png%3Falt%3Dmedia%26token%3Df018776b-faf4-4a00-a736-b93d048a35d1&width=768&dpr=3&quality=100&sign=673eedf3&sv=2) [PreviousQuests](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests) [NextOther nodes](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/other-nodes) Last updated 1 year ago --- # Dialogue | Blueprint Tasks Extension | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue.md) . This plugins approach to dialogue is nothing special, since dynamic custom output pins are native to `BlueprintTasks`, everybody can make their own dialogue system with ease. This more or less serves as an example of how to make your own, alongside bringing an example of how to decorate a dialogue node. [PreviousTask Graphs](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs) [NextDecorator](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue/decorator) Last updated 1 year ago --- # Who am I? | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/who-am-i.md) . Hello, I'm Varian! I've been an indie developer for the last few years. Starting to learn programming completely from scratch to now being a successful seller on the marketplace. For reasons I won't go into here, I'm essentially retired and just work on my own games and code for fun. (That doesn't mean I am not available for work, just the chances of me saying yes to a job are low). This website acts as both my portfolio and as a source of documentation for all of my plugins. Either paid, free, in development, or private. I've been crafting a "golden path of development" for quite some time that suits my workflow. What does that mean? I'm creating a workflow that suits me and allows me to make my games faster. This path started out through my most successful plugin, the [Inventory Framework Plugin](https://varian.gitbook.io/varian-docs/inventoryframework/) , which lead to my public repo, [ModularityPractice](https://github.com/Variann/ModularityPractice) . This path was then reinforced by [Riot's development ecosystem](https://youtu.be/9xxwQVdwcTQ?si=EUl2iFRfBSgeypto) talk. I am still figuring out how much time I want to invest into the UE marketplace and how much I want to focus on indie game development. But what you can always trust in is that I'll always be working on either one! [PreviousWelcome](https://varian.gitbook.io/varian-docs) [NextMy design style](https://varian.gitbook.io/varian-docs/my-design-style) Last updated 1 year ago --- # Quests | Blueprint Tasks Extension | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests.md) . [](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests#quest-structure) Quest structure --------------------------------------------------------------------------------------------------------------- The structure of a quest can be viewed as a tree and are comprised of three parts. * Quest Chain: A chain is only completed when all quests associated with the chain are completed * Quest: A quest is only completed when all objectives stages it contains are complete. A quest can contain as many stages as it needs. * Objective Stage: A objective stage is only completed when all objectives it contains are completed. The name of this example quest chain will be "A Helping Hand" * First quest `Cleaning The Farm` * Objective Stage 1 * Collect 5 Apples * Collect 3 Carrots * Objective Stage 2 * Return the apples and carrots to Farmer John * Next quest is called `Tractor Maintenance` * Objective Stage 1 * Refuel the tractor * Objective Stage 2 * Get in the tractor * Objective Stage 3 * Drive to the farmland * Next quest is called `Plow the Farms` * Objective Stage 1 * Plow the carrot farm * Plow the apple farm * Objective Stage 2 * Talk to Farmer John for your payment. (Completes the "A Helping Hand" quest chain) This structure allows you to create similar architecture to quests you can find in many popular RPG's. A quest can have as many stages as you want, allowing you to create lengthy quests that might involve several scenes. [](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests#branching-quests) Branching quests ----------------------------------------------------------------------------------------------------------------- There are no in-built mechanisms for brancing quests, but rather it's put into the hands of designers to dictate how quests branch out. I personally handle this through [Task Graph's](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs) , and I am responsible for deciding where and how quests are accepted, completed and ultimately locked out from the player. For example, two dialogue choices are given to the player and each will accept a different quest. You might want to lock out the other quest that wasn't chosen, but there might be other parts of the game where that quest could be accepted, so you wouldn't want to lock it from the player. [PreviousDecorator](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue/decorator) [NextDecorator](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests/decorator) Last updated 1 year ago * [Quest structure](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests#quest-structure) * [Branching quests](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests#branching-quests) --- # Other nodes | Blueprint Tasks Extension | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/other-nodes.md) . This page just covers the other nodes that aren't a part of a specific system and can be mostly viewed as quality-of-life improvements. [](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/other-nodes#repeater) Repeater ------------------------------------------------------------------------------------------------------ * Repeatedly triggers for an optional set amount of times with a specific delay in between. Useful for gun firing logic. [PreviousDecorator](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests/decorator) Last updated 1 year ago --- # Warmup Pool | Object Recycler | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/object-recycler/warmup-pool.md) . The warmup pool system allows you to slowly spawn objects until a quota is met. This limit can be set inside the config settings. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3083520733-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FtAr71XXXtm6BySwwYkT3%252Fuploads%252FQ4hUZZz1zaHlhaD5uXLR%252Fimage.png%3Falt%3Dmedia%26token%3Dfa9a8f22-4c0f-4e8c-b13a-12f620ed28c1&width=768&dpr=3&quality=100&sign=668ceb4d&sv=2) When an object is added to the pool and it exceeds this limit, objects will slowly start being removed from the pool depending on the frequency. The oldest object (index 0) in the pool will be removed, as its assumed that one hasn't been used the longest. Depending on how much memory the object consumes and your memory budget, you might want to keep the soft cap low. [PreviousObject Recycler](https://varian.gitbook.io/varian-docs/object-recycler) [NextCog](https://varian.gitbook.io/varian-docs/object-recycler/cog) Last updated 1 year ago --- # My design style | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/my-design-style.md) . [](https://varian.gitbook.io/varian-docs/my-design-style#how-are-my-plugins-systems-designed) How are my plugins/systems designed? --------------------------------------------------------------------------------------------------------------------------------------- ### [](https://varian.gitbook.io/varian-docs/my-design-style#over-arching-goals) Over-arching goals * Create a suit of tools, systems, plugins, workflows and more, that tries to be as design agnostic as possible. Slowly creating a large collection of code that can be re-used between projects, no matter their genre or requirements. This can be thought of as "creating an ecosystem/SDK" * Minimize duplicate work as much as possible. * Create a "golden path" of development. The clearer this path becomes, the faster development of each project becomes. ### [](https://varian.gitbook.io/varian-docs/my-design-style#system-design) System design Systems can be defined as a plugin, module, a small set of classes, or as an extension in another system like an equipment system in an inventory system. But most of the time, it's just considered as a plugin. * I will NOT be supporting replication/multiplayer in any of my plugins other than Inventory Framework. I am finished with multiplayer projects. * Rarely create parent actors or override important classes, such as the game instance. Utilize subsystems, actor components and such as much as possible. * Plugins should try to be self-contained. If they require another plugin to work, that other plugin should be design-agnostic. * Do not recreate a system from another plugin just to get around this. It's better to break this rule rather than create duplicate systems. For example, a broadcast system like `GameplayMessageRouter` should never have duplicates in other plugins. * Unfortunately, this rule might be broken in plugins that are planned to be released to the marketplace because of the marketplace dependency rules. * Try to enable as much Blueprint support as possible. * Exceptions are made when Blueprint support might cripple or highly complicate a systems workflow. * Enable cross-plugin integration through preprocessor macros. * For example; `TagFacts` will broadcast a message through [Hermes if the plugin is installed](https://varian.gitbook.io/varian-docs/tag-facts/integrations#hermes) . [](https://varian.gitbook.io/varian-docs/my-design-style#debugging-standards) Debugging standards ------------------------------------------------------------------------------------------------------ The debugging standards are slowly being enforced throughout my plugins. So these standards might not be found in my plugins \*yet\* * Try to provide a `ImGui` debugger through `Cog`. ([**Documentation**](https://varian.gitbook.io/varian-docs/imgui-cog-setup/) ) * This is mostly just done for systems that are difficult to debug through the `Blueprint Debugger` tool or if the engine has no other suitable alternative debugger. * For functions with fail states where a simpe boolean doesn't cover all fail states, try to include a FString parameter that explains why it failed. * Add log messages in a custom category or print to the screen if necessary. * Most custom categories are just called `Log` with the name of the module appended to the end. In some rare circumstances, a custom log might be made for a specific system inside of a module. [PreviousWho am I?](https://varian.gitbook.io/varian-docs/who-am-i) [NextSuggested Plugins](https://varian.gitbook.io/varian-docs/suggested-plugins) Last updated 1 year ago * [How are my plugins/systems designed?](https://varian.gitbook.io/varian-docs/my-design-style#how-are-my-plugins-systems-designed) * [Over-arching goals](https://varian.gitbook.io/varian-docs/my-design-style#over-arching-goals) * [System design](https://varian.gitbook.io/varian-docs/my-design-style#system-design) * [Debugging standards](https://varian.gitbook.io/varian-docs/my-design-style#debugging-standards) --- # Suggested Plugins | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/suggested-plugins.md) . No matter what plugin of mine you are using, this is a list of plugins I recommend for everyone due to their excellent quality. [](https://varian.gitbook.io/varian-docs/suggested-plugins#gas-companion) [GAS Companion](https://www.unrealengine.com/marketplace/en-US/product/gas-companion) --------------------------------------------------------------------------------------------------------------------------------------------------------------------- Unreal Engine's built-in Gameplay Ability System (GAS) is extremely powerful and is becoming an industry standard. There is a problem with it though; it's not very beginner-friendly. It's annoying to make attributes and can take a long time to set it up. The plugin GASCompanion does all the heavy lifting for you, has good documentation and good Discord support. [](https://varian.gitbook.io/varian-docs/suggested-plugins#flow-graph) [Flow Graph](https://github.com/MothCocoon/FlowGraph) ---------------------------------------------------------------------------------------------------------------------------------- Made by one of the developers of Witcher 2 and 3 and is being backed by Riot Games, this plugin has revolutionized how I make things like quests, dialogues and much more through its amazing graph editor. A tool that I truly think should be introduced to Unreal's base toolset. [](https://varian.gitbook.io/varian-docs/suggested-plugins#editor-scripting-tools) [Editor Scripting Tools](https://github.com/HoussineMehnik/UE4-EditorScriptingToolsPlugin) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This plugin lets you customize the editor without touching C++. It allows you to add UMG widget tools into detail panels all inside blueprints and without touching the plugin that class resides in. [](https://varian.gitbook.io/varian-docs/suggested-plugins#gameplay-message-router) Gameplay Message Router ---------------------------------------------------------------------------------------------------------------- This is a plugin that can be found in Lyra and it provides a simple yet powerful global messaging system. [PreviousMy design style](https://varian.gitbook.io/varian-docs/my-design-style) Last updated 1 year ago * [GAS Companion](https://varian.gitbook.io/varian-docs/suggested-plugins#gas-companion) * [Flow Graph](https://varian.gitbook.io/varian-docs/suggested-plugins#flow-graph) * [Editor Scripting Tools](https://varian.gitbook.io/varian-docs/suggested-plugins#editor-scripting-tools) * [Gameplay Message Router](https://varian.gitbook.io/varian-docs/suggested-plugins#gameplay-message-router) --- # Cog | Object Recycler | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/object-recycler/cog.md) . `ObjectRecycler` comes with a `Cog` debugger out of the box. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3083520733-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FtAr71XXXtm6BySwwYkT3%252Fuploads%252FNgA452ciate0UHoLhLKo%252Fimage.png%3Falt%3Dmedia%26token%3Ddf04a389-e7f9-4555-8c55-5659dadb932f&width=768&dpr=3&quality=100&sign=b927ba0a&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3083520733-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FtAr71XXXtm6BySwwYkT3%252Fuploads%252FUoTdhzaxXm73DoKmsUen%252Fimage.png%3Falt%3Dmedia%26token%3Db207c435-fe45-445f-a4b8-7da523ef42b6&width=768&dpr=3&quality=100&sign=c24aa16a&sv=2) [PreviousWarmup Pool](https://varian.gitbook.io/varian-docs/object-recycler/warmup-pool) Last updated 1 year ago --- # Object Recycler | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/object-recycler/object-recycler.md) . A system for recycling spawned objects to improve performance. This type of system is very popular among open world games, games with lots of objects, or games with very tight performance requirements. What does it do? * Spawning objects is expensive. So why are we destroying objects when we can recycle them? Take for example a projectile: If the player shoots a projectile, it lands on a target, deals damage, spawns VFX, etc. But instead of destroying the projectile, we make it invisible, add it to a pool, then when the player shoots another projectile, we check if any projectiles in the pool are available for re-use. If so, then set a new world location, make it visible, reset any parameters and treat it as if you just spawned in a whole new actor, without paying the cost of spawning and constructing an actor. How fast is it at recycling an object? * The system has been designed to scale extremely well. So 1 object in the pool or a thousand. In a test of over 3000+ calls where the pool slowly scaled up from 0-200 objects being recycled, the average recycling time was 3 microseconds. For context, in this test the actor that was being spawned only had 1 widget component for displaying damage numbers. On average, this actor was taking 136 microseconds to spawn from scratch. Recycling it was about 45 times more efficient. * The above was just exclusive time. If we take inclusive time into account, recycling took about 10 microseconds and spawning from scratch took 266 microseconds. Not as efficient as exclusive time, but still 26.6 times faster, but since we are now talking about inclusive time, this scaling will drastically improve when the actor has more components and is more expensive to spawn. Recycling an actor is usually just resetting its location and some parameters. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2Fgithub.com%2FVariann%2FModularityPractice%2Fassets%2F6917153%2F49c294bf-3ee5-416f-9b4d-ec7d6a477147&width=768&dpr=3&quality=100&sign=795f8db5&sv=2) A hidden benefit this system adds is that it reduces hitches caused by the garbage collector. The garbage collector is one of the main causes of large hitches and low performance spikes in most games, especially UE games as the game starts removing hundreds of objects from memory (This should be improved in 5.4 with the asynchronous garbage collector). Since this system is re-using objects and not allowing them to be garbage collected, this hitch can be greatly reduced. [](https://varian.gitbook.io/varian-docs/object-recycler#how-to-use) How to use ------------------------------------------------------------------------------------ This is a subsystem, so no reparenting of any kind is needed. Just simply call these functions: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3083520733-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FtAr71XXXtm6BySwwYkT3%252Fuploads%252FvRiHfjblfu8Qb4YvzCC0%252Fimage.png%3Falt%3Dmedia%26token%3D327958ac-7233-4d26-b890-f9a625840905&width=768&dpr=3&quality=100&sign=db6374d4&sv=2) For classes to participate, they must implement the `I_ObjectRecycling` interface, which includes these functions: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3083520733-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FtAr71XXXtm6BySwwYkT3%252Fuploads%252FwJhXmz4y0tyOdXoa5giI%252Fimage.png%3Falt%3Dmedia%26token%3D523654e0-2869-49fb-b40f-123125ee6c36&width=768&dpr=3&quality=100&sign=ce78d56c&sv=2) [](https://varian.gitbook.io/varian-docs/object-recycler#advice) Advice ---------------------------------------------------------------------------- * When you send an actor into the pool and decide to set its location to somewhere you might send other actors, it's highly suggested to disable collision on that actor. This is because all the actors you will send there will start colliding with each other. This will consume your FPS and Unreal Insights will only report back `ExecuteForegroundTask`, with no hints that it's actually collision events. [NextWarmup Pool](https://varian.gitbook.io/varian-docs/object-recycler/warmup-pool) Last updated 7 months ago * [How to use](https://varian.gitbook.io/varian-docs/object-recycler#how-to-use) * [Advice](https://varian.gitbook.io/varian-docs/object-recycler#advice) --- # Welcome to Input Nexus | Input Nexus | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/input-nexus/welcome-to-input-nexus.md) . `InputNexus` is a plugin that streamlines how Enhanced Input System is handled and where gameplay logic is stored, creating a more designer-friendly approach and reducing clutter in the player controller and pawns. * **Input Nexus Component:** Hosts an array of Input Link's and is the home of input management. * **Input Link:** Objects linked to an input action's event to run your gameplay code. * **Link Bundle:** Quickly grant multiple Input Nexus component's the exact same Mapping Context, Input Action and Input Link setup. * **Input Buffering:** Open buffer channels to delay Input Link's code tied to those channels until the channel is closed. The vast majority of gameplay logic around Enhanced Input System can be found in the player controller and pawn, which slowly leads to those classes becoming massively bloated. Because of this, the core of `InputNexus` can be found in the `AC_InputNexus` actor component. This component hosts an array of input actions, and grants each input action an array of `InputLink`'s, then when that input action is activated, the nexus component sends appropriate events to each link associated with that input action. This can include movement, opening an inventory screen, activating GAS abilities, etc. This approach allows you to create reusable, easily manageable input gameplay logic that can be used across projects. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FcBoGE2SXww5V0uWK1cus%252Fimage.png%3Falt%3Dmedia%26token%3D00698416-b01f-411e-9ea5-f32bb8c4fff8&width=768&dpr=3&quality=100&sign=3c56d819&sv=2) [](https://varian.gitbook.io/varian-docs/input-nexus#faq) FAQ ------------------------------------------------------------------ * Should the regular `InputAction` nodes continue to be used? * You can, but it is advised to use `InputLinks` whenever possible because we can control the order and input consumption. This system does not block the regular input action nodes from being used in any way. * The helper library comes with a `RegisterObjectWithInputComponent` and `UnregisterObjectWithInputComponent` function, which enable and disable the traditional input action nodes in most classes. * Is it possible to have multiple Nexus components at the same time? * Yes! You can also enable/disable input events per Nexus component. Meaning you can disable one, then enable another Nexus component to completely swap out `InputActions` and `InputLinks`. * For things like GAS, why wouldn't I use the in-built `EIS` support? * Every single system in Unreal that tries to tie some event to input actions are separated. So it becomes extremely difficult to debug, organize, customize and control. Lyra has its own implementation, GAS has its own implementation. `InputNexus` is a centralized system that tries to allow itself to be connected to anything you want to enable `EIS` support for, such as a custom ability system. * Does this support replication? * No. But it doesn't mean it can't be implemented. As stated [here](https://varian.gitbook.io/varian-docs/my-design-style#how-are-my-plugins-systems-designed) , I am done with creating systems with replication support. It is fairly simple to add replication support, but I won't be adding it because it would mean that I would have to provide technical support for multiplayer issues. [NextNexus Component](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component) Last updated 1 year ago --- # Cog | Input Nexus | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/input-nexus/cog.md) . `InputNexus` provides a `Cog` debugger out of the box. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252Fe8nd6kMPhY2JUbbOItiO%252Fimage.png%3Falt%3Dmedia%26token%3D7b3ae225-d559-4403-bd64-fe205dcdc65d&width=768&dpr=3&quality=100&sign=89d6cacd&sv=2) This debugger allows you to make certain modifications to all registered `InputNexus` components and their `InputLinks` in the level. Adding it to your window manager is very simple. I prefer to put the window into the `Input` category. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FJT7A8q5OTg9RGEapK9Vb%252Fimage.png%3Falt%3Dmedia%26token%3D88154ac4-a89e-4d39-8d87-887232b5aa95&width=768&dpr=3&quality=100&sign=210ee263&sv=2) [PreviousInput Buffer](https://varian.gitbook.io/varian-docs/input-nexus/input-link/input-buffer) [NextTo-do](https://varian.gitbook.io/varian-docs/input-nexus/to-do) Last updated 1 year ago --- # Changelog | Input Nexus | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/input-nexus/changelog.md) . [](https://varian.gitbook.io/varian-docs/input-nexus/changelog#version-1.0.0) Version 1.0.0 ------------------------------------------------------------------------------------------------ * Release [PreviousTo-do](https://varian.gitbook.io/varian-docs/input-nexus/to-do) Last updated 1 year ago --- # Nexus Component | Input Nexus | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component.md) . This component is the host of all `InputLink`'s and manages them. It's also responsible for link bundles, mapping contexts and buffering inputs. [](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component#buffering-inputs) Buffering inputs ------------------------------------------------------------------------------------------------------------ To open and close an input buffer channel, simply call `OpenInputBufferChannel` and `CloseInputBufferChannel`. Go [here](https://varian.gitbook.io/varian-docs/input-nexus/input-link/input-buffer) to read more about how input buffers work. * You can check if a channel is open through the `IsBufferChannelOpen` function. [](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component#managing-inputs) Managing inputs ---------------------------------------------------------------------------------------------------------- * To completely disable or enable a `NexusComponent`, call `ToggleInputEvents`. You can also call the native `Activate` or `Deactivate` functions, which will toggle the input events appropriately. * To disable or enable an input action, call `ToggleInputEventsForInputAction`. * Multiple `NexusComponent`'s are supported on an actor, but it's up to you to retrieve the one you want. You might want to create a list of what type of input logic the pawn will use and what kind of input logic the controller will use. For example: * Controller: Handles UI logic, such as the escape button summoning the escape screen. * Pawn: Handles movement and interaction. In the case that the player possesses a vehicle pawn, this will automatically disable the other pawns movement and interaction events. [PreviousWelcome to Input Nexus](https://varian.gitbook.io/varian-docs/input-nexus) [NextInput Link](https://varian.gitbook.io/varian-docs/input-nexus/input-link) Last updated 1 year ago * [Buffering inputs](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component#buffering-inputs) * [Managing inputs](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component#managing-inputs) --- # Link Bundle | Input Nexus | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/input-nexus/input-link/link-bundle.md) . `LinkBundle`'s is a simple data-only object meant to store an array of `InputLink`'s to quickly grant a set of `InputMappingContext`'s, `InputAction`'s and `InputLink`'s. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252Fbl0DL7cLuYAQFxaM8QS3%252Fimage.png%3Falt%3Dmedia%26token%3Dd639c2ed-75ff-4baa-ad5b-b8189ff0d3ed&width=768&dpr=3&quality=100&sign=67975e81&sv=2) * This is a data-only class with no functions. Hence why this is not a data asset and just a object class. * Only 1 copy of each `LinkBundle` can be active at a time per `InputNexus` component. * Default `LinkBundle`'s will have their links added to the start of the `InputLink`'s array and everything defined in the component and `LinkBundle`'s added during runtime will have their `InputLink`'s added to the end of the array. It's designed this way because default `LinkBundle`'s are expected to be used as the base data, then everything added through the `InputLinks` array should be treated as the links added on top of them. * Remember, the `InputLink`'s at the [end of the array are activated first](https://varian.gitbook.io/varian-docs/input-nexus/input-link) . We use a reverse for-loop rather than a standard for-loop. [PreviousInput Link](https://varian.gitbook.io/varian-docs/input-nexus/input-link) [NextInput Buffer](https://varian.gitbook.io/varian-docs/input-nexus/input-link/input-buffer) Last updated 1 year ago --- # Input Buffer | Input Nexus | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/input-nexus/input-link/input-buffer.md) . Each `InputNexus` can temporarily suspend events to `InputLinks` that enable input buffering. Buffers are separated by `InputBufferChannels`, which is a TMap of gameplay tags and `InputLinks`. When the channel is opened, this buffer is populated by any links that attempted to be activated but were stopped, while also storing the last action value. When the channel is closed, the `InputLinks` will act as if the player just pressed the button, but using the last stored action value that was used. * Keep in mind, this is not a queue system. Only the last input event will be repeated. To open a buffer channel, call `OpenInputBufferChannel`, then to close it, you call `CloseInputBufferChannnel`. Inputs are buffered inside `UInputLink` ➝ `BufferInput`. If you wish to override or customize how a link handles buffering, override this function. Once the channel is closed, all the inputs are released like so: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FYeDcyrJGBPFCn24KxE32%252Fimage.png%3Falt%3Dmedia%26token%3D210a167a-155a-43e4-ae70-5db181a299b4&width=768&dpr=3&quality=100&sign=a65100ed&sv=2) Do note, this follows the same code execution as when an input is pressed, as in, checking if it's enabled, can handle the input and consumption If you have the `InputLink` trigger on the `Completed` event, the released buffered input might not trigger the way you'd expect. Since the `Completed` event can reset the input value, that means the data inside of `FInputActionValue` will be null. To cancel an `InputLink`'s buffered input, call `FlushBufferedInput` [](https://varian.gitbook.io/varian-docs/input-nexus/input-link/input-buffer#animation-based-buffering) Animation based buffering -------------------------------------------------------------------------------------------------------------------------------------- `InputNexus` provides an animation notify state that allows you to open and close a input buffer channel ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FZ6L2qik3Whv4Z3rT2PLS%252Fimage.png%3Falt%3Dmedia%26token%3D614bf3c5-8575-4f2c-8374-ec5bc30365f4&width=768&dpr=3&quality=100&sign=e4dea908&sv=2) When it starts, the buffer channel is opened. When it ends, the buffer channel is closed. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FRu0vI2hpdTS9ubCxwoq2%252Fimage.png%3Falt%3Dmedia%26token%3Deff182a1-2c43-4dd3-a73a-086313185ee9&width=768&dpr=3&quality=100&sign=44d5abc2&sv=2) [PreviousLink Bundle](https://varian.gitbook.io/varian-docs/input-nexus/input-link/link-bundle) [NextCog](https://varian.gitbook.io/varian-docs/input-nexus/cog) Last updated 1 year ago --- # To-do | Input Nexus | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/input-nexus/to-do.md) . This to-do list contains features that might get released in the next update, worked on in the future or is in progress. * UI or game input `InputLink`'s * `Cog` debugger should show what buffer channels are open/closed * Add and remove `InputLink`'s through Modular Game Features [PreviousCog](https://varian.gitbook.io/varian-docs/input-nexus/cog) [NextChangelog](https://varian.gitbook.io/varian-docs/input-nexus/changelog) Last updated 1 year ago --- # Welcome | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/welcome.md) . Welcome to the main source of documentation for all of my plugins! Below are shortcuts to my plugins. You can also hover over the top left dropdown. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F1557693872-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FxzUOY86WRCHSxkZ9RK7V%252Fuploads%252FTgbJwgkAU7p15ua5fudd%252Fimage.png%3Falt%3Dmedia%26token%3D697ca388-e088-45f7-9414-49135893ec3f&width=768&dpr=3&quality=100&sign=24abb329&sv=2) Paid-only plugins: [](https://varian.gitbook.io/varian-docs/inventoryframework) Inventory Framework * Design your perfect inventory system [](https://varian.gitbook.io/varian-docs/input-nexus/) Input Nexus * Streamline and componetise your input actions Free, much smaller plugins: [](https://varian.gitbook.io/varian-docs/omnitoolbox/) OmniToolbox * A utility plugin, which some of my plugins depend on [](https://varian.gitbook.io/varian-docs/tagsmetadata/) Tags Metadata * Add simple metadata to gameplay tags [](https://varian.gitbook.io/varian-docs/object-tags/) Object Tags * Global tag system supporting all UObjects [](https://varian.gitbook.io/varian-docs/tag-facts/) Tag Facts * Simple fact database for keeping track of events. Private or in-development plugins. Some of these plugins are either for my personal projects and stored here so either I or team members can view it. If any of these interest you, you can message me on Discord and the plugin could potentially be shared with you. [](https://varian.gitbook.io/varian-docs/object-recycler/) Object Recycler * Object pooling system to help with performance Hermes * Global and local messaging system. [NextWho am I?](https://varian.gitbook.io/varian-docs/who-am-i) Last updated 7 months ago --- # Input Link | Input Nexus | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/input-nexus/input-link.md) . When it comes to running meaningful gameplay code, `InputLinks` is where that code is stored. Links are tied to an `InputAction` and `TriggerEvents` to control when their code is ran. When that action is activated with that trigger event, the `InputLink` will call `OnInputActivated` Input events are handled like so: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252Fe0in6iU9AK8vDlRmqy7N%252Fimage.png%3Falt%3Dmedia%26token%3D80e37e22-6a17-48b8-93a2-85235a1745a9&width=768&dpr=3&quality=100&sign=6f70190e&sv=2) * Links can be dynamically enabled and disabled, for example an ability input being disabled while the ability is on cooldown. * Links will only receive the input event if: * They are registered to the specific trigger event that is currently occurring. * `CanHandleInput`returns true * The link is enabled. * If the link decides to consume the input, it will prevent the input event from continuing on down the chain of links for that input action. * To add a input link during runtime, in Blueprints use the `ConstructObjectFromClass` node, this will allow you to edit `ExposeOnSpawn` parameters as you wish. In C++, use `NewObject<>()`. Then call `AddInputLink`. * * * [](https://varian.gitbook.io/varian-docs/input-nexus/input-link#runtime-input-links) Runtime Input Links ------------------------------------------------------------------------------------------------------------- `InputLink`'s can be constructed during runtime. Sometimes, all you need is to listen to an input event as if the object is an input link. For example; a GAS ability ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FEHjrXcTN2gCvBPZD3TIw%252Fimage.png%3Falt%3Dmedia%26token%3D4b4a6f40-7ac3-47f9-92b2-d6b0fc6c620e&width=768&dpr=3&quality=100&sign=fa2f7b92&sv=2) This GAS ability is now receiving input events as if itself was an `InputLink`. The events are just being filtered and forwarded through a `InputLink`, making it act as a proxy between `GAS` and `InputNexus`. This method now allows you to utilize all the strenghts of `InputNexus` with minimal work and complexity. This ability can now benefit from input buffering, input consumption and more. * * * [](https://varian.gitbook.io/varian-docs/input-nexus/input-link#practical-examples) Practical examples ----------------------------------------------------------------------------------------------------------- * During the tutorial, you might want to listen to specific input events, such as the movement keys. Normally, you'd now have to hard code this into the player character and have redundant code throughout your entire game. With a `InputLink`, you can listen to an input event, execute custom code, then remove it. Separating that logic from the character and not have redundant code being executed throughout the game. I use the FlowGraph plugin to add a input link to the jump and movement input actions during the tutorial and broadcast an event when it happens. The input link has then been designed to remove itself when it hits a broadcast limit. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FzZCa3P1mmOq5YHAKOu1U%252Fimage.png%3Falt%3Dmedia%26token%3Defa28ea9-9643-4855-bed6-d3b572367a22&width=768&dpr=3&quality=100&sign=2d0b9fce&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FOicKnjqFlKp7LKsg40Ek%252Fimage.png%3Falt%3Dmedia%26token%3D135f3180-bb90-46cd-9f90-c745583e604d&width=768&dpr=3&quality=100&sign=f0e3c857&sv=2) * For my project, I've integrated support with [**ObjectTags**](https://varian.gitbook.io/varian-docs/object-tags/) so I can natively block `InputLink`'s depending on a tag query. Now all I need to do to block movement is fill in what tags would block the movement `InputLink`, such as a stunned tag. I never have to repeat this code anywhere, I just need to make my `InputLink`'s a child of this tag support class. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FDNGz1McfNMXGRtWkRdKx%252Fimage.png%3Falt%3Dmedia%26token%3D2003455a-b95b-41f0-b9d2-04cf7e0de42c&width=768&dpr=3&quality=100&sign=ad02f542&sv=2) * * * [](https://varian.gitbook.io/varian-docs/input-nexus/input-link#creating-custom-input-links) Creating custom input links ----------------------------------------------------------------------------------------------------------------------------- `InputLink`'s have several functions for you to override and call. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F613315177-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoMPMkfK8Z7Abx42Ut6mi%252Fuploads%252FMCxVl39DDjK6ZnmOhVA4%252Fimage.png%3Falt%3Dmedia%26token%3Dd0594e57-4afc-4b89-aea7-83b45afcfc56&width=768&dpr=3&quality=100&sign=f8164910&sv=2) `InputNexus` comes with 2 simple examples, which can be found in the `Links` folder. The majority of the time, you'll be overriding either `OnInputActivated` or `CanHandleInput` [PreviousNexus Component](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component) [NextLink Bundle](https://varian.gitbook.io/varian-docs/input-nexus/input-link/link-bundle) Last updated 1 year ago * [Runtime Input Links](https://varian.gitbook.io/varian-docs/input-nexus/input-link#runtime-input-links) * [Practical examples](https://varian.gitbook.io/varian-docs/input-nexus/input-link#practical-examples) * [Creating custom input links](https://varian.gitbook.io/varian-docs/input-nexus/input-link#creating-custom-input-links) --- # OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/omnitoolbox.md) . [Github link](https://github.com/Varian-s-Unreal-Plugins/OmniToolbox) | [Trello Board](https://trello.com/b/M1LkF49R/omnitoolbox) | [Discord](https://discord.gg/bBfa9pwtEn) `OmniToolbox` is a free and open-source plugin designed to provide numerous function libraries, quality-of-life editor changes and provide a foundation to improve all of my plugins. There are many features that are very impactful, but are too small to warrant their own plugin. This toolbox is essentially my collection of those features. Highlights include: * Quickly and easily add any asset into the content browser's context menu by simply adding a interface. * Assets can easily control their own thumbnails through a universal thumbnail renderer. * Many C++ functions exposed to Blueprint, such as async traces, gameplay tag utility functions. * Useful tools and features too small to warrant their own plugin, such as [Float Providers](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/float-providers) . * Useful macro's and utilities to simplify C++ code. [NextStructure and contribution](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution) Last updated 5 months ago --- # Todo | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/todo.md) . [](https://varian.gitbook.io/varian-docs/omnitoolbox/todo#validators) Validators ------------------------------------------------------------------------------------- * Common validators to help projects get going. For example: * Enforcing naming schemes, such as materials must have a `M_` prefix and material instances must have a `MI_` prefix. * This would be its own separate module and a config setting to enable, just in case developers already have their own validators or have a style guide that does not match these validators. * [Flassari - CommonValidators](https://github.com/Flassari/CommonValidators) is a good source to start with [](https://varian.gitbook.io/varian-docs/omnitoolbox/todo#linked-assets-toolbar) Linked assets toolbar ----------------------------------------------------------------------------------------------------------- An example would be behavior tree's and blackboards. In IFP, linked assets would be very useful for the item asset. Having a button to quickly go between the item asset, item actor, item instance and such would be very useful. Last updated 7 months ago * [Validators](https://varian.gitbook.io/varian-docs/omnitoolbox/todo#validators) * [Linked assets toolbar](https://varian.gitbook.io/varian-docs/omnitoolbox/todo#linked-assets-toolbar) --- # Macros | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/macros.md) . --- # Macros | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/macros.md) . Some of these macros are only functional while in the editor, and some work on both. Some of these macros are meant for .cpp files and placed in the global scope. The rest can be placed inside of regular code. Copy Omni_InsightsTrace_Str("My insights trace") * Wrapper for `TRACE_CPUPROFILER_EVENT_SCOPE_STR` Copy Omni_InsightsTrace() * Wrapper for `TRACE_CPUPROFILER_EVENT_SCOPE(__FUNCTION__)`. If the function this macro is inside of is called `Bar` and the class is named `Foo`, this will display as `Foo::Bar` inside Unreal Insights Copy Omni_OnModuleStarted("AIF_Mass") { UE_LOG(LogTemp, Warning, TEXT("AIF_Mass module has started")); } * This macro will trigger the code beneath it whenever the specified module is started. You can find module names inside of a plugins `.uplugin` file. * Place in .cpp file and in global scope. * You can use the engine's `UE_MODULE_NAME` macro if you aren't waiting for a separate module to start. Copy Omni_SetClassIcon( AgentIntelligenceFramework, /*Plugin name*/ AgentGameplayEffectConfig, /*Class name (No U prefix)*/ EffectIconSlate) /*Name of SVG inside of plugins resource folder*/ * Automatically assigns an SVG (must be inside the plugins `Resource` folder) for a class as the class icon and class thumbnail. * Place in .cpp file and in global scope. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252Fw8orwRVs0y6SVmuSxhik%252Fimage.png%3Falt%3Dmedia%26token%3Da9c01cae-93cf-49a1-9766-8d87fd876b1c&width=768&dpr=3&quality=100&sign=28185536&sv=2) [PreviousStructure and contribution](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution) [NextContent Browser](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/content-browser) Last updated 5 months ago --- # Documentation button | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/documentation-button.md) . Any asset implementing the `I_AssetDetails` interface and overrides the `GetDocumentationLinks` will have a button appear next to the compile button that when pressed, will open that URL in the browser. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FCJF6fGjEPVjLO6sg4bLd%252Fimage.png%3Falt%3Dmedia%26token%3De4a5364e-e6c0-476c-ab6d-3934dcfb6b90&width=768&dpr=3&quality=100&sign=802f5371&sv=2) Copy virtual TArray GetDocumentationLinks_Implementation() const override { return TArray { FOmniDocumentationLinkAndText("https://varian.gitbook.io/varian-docs/tagsmetadata") }; } Providing more than 1 index will convert the button into a dropdown menu ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252F4yCK9otYVpkh992mH41t%252Fimage.png%3Falt%3Dmedia%26token%3Deadc86bb-4415-4fb5-aabe-e32bd3dcc9f3&width=768&dpr=3&quality=100&sign=741b4539&sv=2) `FOmniDocumentationLinkAndText` has 2 parameters, a URL and a text. Remember to fill in the text when providing multiple links, as this text will be displayed to the user. [PreviousThumbnail Renderer](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/thumbnail-renderer) [NextPlace Actor Palette control](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/place-actor-palette-control) Last updated 7 months ago Copy virtual TArray GetDocumentationLinks_Implementation() const override { return TArray { FOmniDocumentationLinkAndText( "https://varian.gitbook.io/varian-docs/tagsmetadata", "Option1") FOmniDocumentationLinkAndText( "https://varian.gitbook.io/varian-docs/", "Option2") }; } --- # Content Browser | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/content-browser.md) . > [](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/content-browser#credits) > > Credits: > > > -------------------------------------------------------------------------------------------------- > > * Thanks to mklabs for his [GAS Companion](https://www.fab.com/listings/72e2bc50-658e-43cd-bd40-535f46d2f113) > plugin, his content browser extension code is the original reason I pursued this system. Although no GAS Companion code is used in this plugin. > > * Some of the code is borrowed from the open-source [VoxelCore](https://github.com/VoxelPlugin/VoxelCore) > plugin. > `OmniToolbox` allows any C++ class to be easily added to the content browser's context menu by simply adding the `I_AssetDetails` interface and returning true for `AppearsInContextMenu`. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FjvRVYer2oNevkLNu5RYm%252Fimage.png%3Falt%3Dmedia%26token%3D46e23a2f-5dc0-4567-92e9-f052808f733a&width=768&dpr=3&quality=100&sign=62b37672&sv=2) Your asset will now automatically get a `UOmniAssetDefinition` and `UOmniFactory` to handle displaying it in the context menu and to create the asset. This only supports basic assets (data assets and normal blueprint types) The interface provides some utilities, such as enabling a class picker ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FzwlCXbqt97chKDhP4m3J%252Fimage.png%3Falt%3Dmedia%26token%3D4992c7d9-98f2-462b-9b44-e5f33cad6825&width=768&dpr=3&quality=100&sign=ecc255d1&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FXGHShrX6kz3DyC64avGm%252Fimage.png%3Falt%3Dmedia%26token%3D8963ccca-4311-48ee-b868-2d67184f0e4d&width=768&dpr=3&quality=100&sign=2737f54d&sv=2) When overriding `AppearsInContextMenu`, I recommend doing it like this: Handling it like this will prevent child classes from also attempting to appear in the context menu. [](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/content-browser#blueprint-support) Blueprint support --------------------------------------------------------------------------------------------------------------------- I do NOT recommend using this system for blueprints. It's not good practice to have your base abstract classes be blueprints and there are many potential issues that can occur when loading blueprints like this. To allow blueprints to appear in the content browsers context menu, a little bit more work is required: 1. Go to your editor settings and find `OmniToolbox` and add your blueprint to `Context Menu Entries` 1. The blueprint must implement `I_AssetDetails` to appear 2. Restart the editor. 1. The code that handles this system is only executed once and that is when the plugin is started. [PreviousMacros](https://varian.gitbook.io/varian-docs/omnitoolbox/macros) [NextThumbnail Renderer](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/thumbnail-renderer) Last updated 7 months ago Copy virtual bool AppearsInContextMenu_Implementation() const override { return GetClass() == UEntityAbility::StaticClass(); } --- # Installing the plugin | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin.md) . [Video walkthrough of the first steps](https://youtu.be/oR8iAmbiDtQ?si=EyXcBJFVL7yjfxTq) * * * Because of how integral an inventory system is to a game, I highly recommend you DO NOT install the plugin to the engine and then use it that way, but instead install the plugin locally to your project. That way you can use the plugin in multiple projects without having a change that works in one project mess up the other project. This means you can also have much better control how the parents behave and work and not have to worry about changes made for another project. But it does mean updating the system is a bit more work, but it is very straight forward if you have source-control set up, as it'll tell you all the changes and you can reimplement any custom changes you made to suit your project. This is not mandatory, but can greatly help in the future when you want to update safely. Once you are done installing the plugin (either locally or through the engine), I **HIGHLY** advise you make children of any class in this system once you want to modify the class. After installing the plugin, I highly recommend you immediately make your own child of the inventory component and add that to your actors as replacing it in the future will mean a lot more work. This should make updating in the future a lot easier and gives you a lot more customizability. This does NOT cover how to install an IDE such as Rider or Visual Studio. You should already have an IDE installed - [**Unreal's docs for setting up Visual Studio**](https://docs.unrealengine.com/4.27/en-US/ProductionPipelines/DevelopmentSetup/VisualStudioSetup/) 1. Download the plugin through the Epic games client just like how you would download any other plugin. 2. If your project doesn’t have any C++ code, you will want to go into the engine and at the top go to **Tools -> New C++ Class**. It doesn’t matter what you create here or where you save it. This is just to get the engine to generate all the files you need to compile the plugin. 3. Go to your **Unreal Engine installation -> Engine -> Plugins -> Marketplace** and copy the InventoryFrameworkPlugin folder. 4. Go into your project's root folder (Where your .uproject is), create a folder called “Plugins” if you don’t have one. 5. Paste the InventoryFrameworkPlugin folder into the plugin folder. 6. Go back to your .uproject, right click and press "Generate Visual Studio Project Files”. 7. Open the solution file with whatever IDE you use (For example Visual Studio or Rider) and build the project. 8. (Optional) You can now uninstall the plugin from the engine through the Epic Games Launcher, though you won't get notifications from the Epic Games client whenever an update is available (The discord announces every update as well). * The engine automatically enables the plugin the majority of the time. In rare cases, it might not enable it. If it didn't, open your project, go to Edit -> Plugins and search for "Inventory Framework Plugin" and make sure it's enabled. Everything in the demo folder is designed to be replaced by your assets/Blueprints. It is only there so you don’t get any errors on startup and can get started quickly. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin#finding-the-plugin-content-in-your-content-browser) Finding the plugin content in your content browser ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ To find the blueprints, go into your content browser and make sure that in your settings (1) that "Show Plugin Content" (2) is checked. Once that is checked, you will find a "Plugins" folder and in there you will find "InventoryFrameworkPlugin content" (3) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FTLjwB6JikvRj3AgW58Wo%252FShowPluginContent.png%3Falt%3Dmedia%26token%3Dcf45f06c-27a4-487e-9981-8fbd34e67701&width=768&dpr=3&quality=100&sign=7489e661&sv=2) If you decide to NOT install the plugin locally, you will also have to check "Show Engine Content" and then go into Engine -> Plugins -> InventoryFrameworkPlugin Content * * * It is highly recommended to head over to the [How does the system work?](https://inventoryframework.github.io/introduction/howdoesthesystemwork/) page and giving a read before proceeding. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin#github-repository-access) Github repository access -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Github access is not required to get the example project. The example project can be downloaded from the product page. To access the example projects repository and the associated example plugins plugins, you will need to verify your purchase by forwarding your Epic Games receipt to my email (Varianprofessional@gmail.com) with your Github username or send me a message with the order ID. [PreviousFirst Steps](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps) [NextAsset Manager](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager) Last updated 1 year ago * [Finding the plugin content in your content browser](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin#finding-the-plugin-content-in-your-content-browser) * [Github repository access](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin#github-repository-access) --- # Thumbnail Renderer | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/thumbnail-renderer.md) . > [](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/thumbnail-renderer#credits) > > Credits > > > ---------------------------------------------------------------------------------------------------- > > Thanks to Erlite from the Unreal Engine discord for helping me with some of the thumbnail property code. There are three ways to override the thumbnail: 1. Use the `ThumbnailOverrides` map in the config settings. 2. Implement the `I_AssetDetails` interface and override `GetThumbnail` 3. For blueprints, the system will look for any `Texture2D` variable with the name “`ThumbnailOverride`” (Advised to use soft reference). This is primarily used for Blueprint programmers. 4. Use the `ThumbnailOverride` meta property specifier on a `UTexture2D` property to use for the thumbnail. (Advised to use soft reference). ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FcPxrj6KwLq4JsY0cBwQG%252Fimage.png%3Falt%3Dmedia%26token%3Dc7a74573-394e-4911-8788-33ef8bb4131f&width=768&dpr=3&quality=100&sign=ef0b098c&sv=2) The priority for what is chosen is also in the same order as above. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FQ6ezSk8WNtuFpOQiZTyU%252Fimage.png%3Falt%3Dmedia%26token%3D2ae0ea0b-f854-4921-a8c9-84fdb94d2011&width=768&dpr=3&quality=100&sign=dd914be&sv=2) Example of a variable in a data asset using the metadata. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FgjSkO9oojf315LIfj6Kv%252Fimage.png%3Falt%3Dmedia%26token%3Dd58e7285-c196-4c00-b430-e31d7a9215e6&width=768&dpr=3&quality=100&sign=4ae61316&sv=2) Blueprint asset assigning its own thumbnail You can even reference .uasset files from C++ without having the variable be visible in the editor. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FzIkIAEl0fd2IuVLNKjxc%252Fimage.png%3Falt%3Dmedia%26token%3D04dce1f7-2b12-4f12-b300-1c5a39f5b3ec&width=768&dpr=3&quality=100&sign=2f8cced0&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FMWDLFxvBJJMdCcxOdGbE%252Fimage.png%3Falt%3Dmedia%26token%3Dad71117a-d664-417d-b73b-f729e57b94c2&width=768&dpr=3&quality=100&sign=3e0fc092&sv=2) Bugs: * After installing the plugin, the thumbnail might not load until the asset is opened or reloaded. You will want to make any changes to it so you get the little asterisk label and save the asset. * Technically not a bug, but textures can be a very low LOD when first loaded. You will want to open the texture and set the `TextureGroup` to `UI`. * In some scenarios after setting the texture to null, the thumbnail won't update. You will want to right click the asset -> `Asset Actions` -> Press `Clear Thumbnail` [PreviousContent Browser](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/content-browser) [NextDocumentation button](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/documentation-button) Last updated 7 months ago --- # Asset Manager | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager.md) . * * * For the asset manager to pick up your item data base and for several tools to function correctly, you must set up the asset manager per project. 1. Go into Projects Settings. 2. Under the "Game" category, select "Asset Manager". 3. Add a new index and set "Primary Asset Type" to "Items", set the asset base class to **DA\_CoreItem**, then go into Directories and add all locations where you might store your items (This also searches sub folders). 4. (Optional) If you are using the crafting system, you will also want to add another index and set "Primary Asset Type" to "CraftingRecipes", set the asset base class to **DA\_CoreCraftingRecipe**, then go into Directories and add all locations where you might store your recipe's. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager#adding-custom-asset-types) Adding custom asset types -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Inside your item data assets, you can see in the **Developer Settings** there's a "**Asset Registry Category**" variable. The default is "Items", just like the asset type we just set up in the asset manager. You are able to either change the default for children of **DA\_CoreItem** to be something unique, or change it per-item. If you have massive item data bases (500+ items), it is recommended to organize your data base using custom asset types. Whatever you fill in inside of **Asset Registry Category**, you will need to follow the above steps, but replacing the Primary Asset Type with whatever you put into **Asset Registry Category**. You also must save the data asset manually after the change. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager#validating) Validating -------------------------------------------------------------------------------------------------------------------------------------------------- To validate your items are being discovered correctly, I suggest going into the [ItemEditor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor) and hitting Refresh near the bottom left. You can also search for your item and if it appears, then the above steps have been done successfully. If an item is not appearing there, either the above steps were not followed correctly or the asset manager is ignoring it for some reason. If you go into "Windows" and open the output log and find any "Ignoring PrimaryAssetType Items - Conflicts with SOMECLASSNAME - Asset: ITEMNAMEHERE" in your message log, it means no data has been changed inside of your data asset or it is identical to another data asset. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager#limitations) Limitations ---------------------------------------------------------------------------------------------------------------------------------------------------- As of 5.1, there is still no way of mixing normal and blueprint data assets, for now you can only have normal data assets, and you can't do a lot of hierarchy setups. All of your parent files must live at a C++ level. Because the item data asset variable inside **FS\_InventoryItem** lives in C++, there is no way to reference blueprint data assets. If you check "Has Blueprint Classes" the system will not work. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager#bulk-editing) Bulk Editing ------------------------------------------------------------------------------------------------------------------------------------------------------ You'll sometimes find yourself with tons of items and need to modify a large amount of items. This is where a good folder hierarchy setup is essential. In the example project, every item is in its own folder, but all of those folders are inside **Items** folder. If you go into the Items folder, find the filter on the left of the search bar and go into **Inventory Framework -> Item Asset** you will see every item inside the example project. If you select multiple, then right click and go into **Asset Actions -> Bulk Edit Via Property Matrix**, you'll find the property matrix editor. [**Unreal's docs for the Property Matrix**](https://docs.unrealengine.com/4.27/en-US/Basics/UI/PropertyMatrix/) [PreviousInstalling the plugin](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin) [NextExample Project](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project) Last updated 1 year ago * [Adding custom asset types](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager#adding-custom-asset-types) * [Validating](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager#validating) * [Limitations](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager#limitations) * [Bulk Editing](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager#bulk-editing) --- # Adding the component and containers | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/adding-the-component-and-containers.md) . * * * 1. There are two components, one is the C++ parent and the other is the blueprint child of the C++ component. There is nothing stopping you from making your own BP component with the C++ component as its parent but I still recommend using the Blueprint component. You can also make a blueprint child of the blueprint component, which is the recommended path if you are going to override any functions. You want to add your component to your actor, if you're making an item, I suggest using **BP\_ItemActor** as its parent and the component will automatically get added. Do note though that the item Data Asset only accepts children of **BP\_ItemActor**. [**Go here**](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#changing-the-item-actor-class) if you want to change this behavior 2. Inside the component you'll find an array called **ContainerSettings**. These are your settings and where you'll add any items to the container. It is most common to give them a unique name, which you'll later use in the next step to assign them to a container widget. You will also need to set what kind of type this container is inside **InventoryType** and give the component a widget inside **WidgetClass** which it'll use to display its containers. Typically for player characters, this is the inventory screen. The order of these containers are important. There are many functions that try and find the first available container, which scans the containers from index 0 to the last index. 3. Now you'll need to bind your containers to a widget to represent the container. This is optional, there are cases where you might not want a container to have a widget representation. Though the player will not have a widget to interact with the container through. Go into your widget and add a child of **WBP\_Container** to your layout. The plugin comes with a widget called **WBP\_DemoContainer** which has all the visuals set up for you. Then go into your graph and implement the **I\_InventoryWidgets** interface. Find the **GetContainers** interface function and make an array and add your containers. Somewhere throughout your logic you will need to call **BindContainerWithWidget**, you can see an example on how I call this function inside **BP\_Interactable** or **BP\_ThirdPersonCharacter**. 4. The actor must implement the **I\_Inventory** interface and override the **GetInventoryComponent** function and pass in a reference to the inventory component. [PreviousExample Project](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project) [NextActivating the component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component) Last updated 1 year ago --- # Debug Draw system | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/debug-draw-system.md) . Unreal has had three issue that has annoyed me for a long time; Vislog and the DrawDebug functions aren't cross-integrating, they behave slightly differently, and there's no way to update a previously create debug draw. For example, drawing a capsule around the player, then moving that capsule with the player. 1. If you want to debug something both live and in the vislog recorder, you have to call 2 different functions. 2. `DrawDebugCapsule` will center the capsule at the origin point. But `Vislog Capsule Shape` will create a capsule with the bottom of the capsule touching the origin point. 3. Functions like `PrintString` have a "key", so you can monitor a specific message in the corner of the screen and modify that one. The draw debug functions do not have this. 4. Bonus issue: With the introduction of Mass, it's far easier to do multithreading code that often has to debug draw something. But the debug draw functions can sometimes cause odd crashes when used outside the game thread `OmniToolbox` provides numerous functions called `Draw and Log...` and then a shape. These functions look to solve all problems in one go. To disable runtime visualization, use the `OmniToolbox.Debug.DrawDebugShapes` console command. It will continue to record vislog shapes. [PreviousPlace Actor Palette control](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/place-actor-palette-control) [NextAsset Validation](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/asset-validation) Last updated 6 months ago --- # Place Actor Palette control | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/place-actor-palette-control.md) . `OmniToolbox` provides 2 ways of adding any actor to Unreal's `Place Actors` panel. 1. Through the `Omni_AddActorToPlacementPaletteCategory` macro in C++ 2. Through the `OmniToolbox` project settings, which is primarily used for blueprints. You can then define your own categories in C++ like so: Copy Omni_PlacementPaletteCategory( "Agent Intelligence Framework", /*Category name*/ "AIF", /*Display name*/ "EditorViewport.VisualizeVirtualShadowMapMode", /*In-engine SVG icon*/ 0); /*Order priority - higher number means = closer to the bottom*/ ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FMWdTsGhZVJOvUqhzfL45%252Fimage.png%3Falt%3Dmedia%26token%3D1e57786e-7cf0-4f81-ba08-358633a00638&width=768&dpr=3&quality=100&sign=f2929898&sv=2) [PreviousDocumentation button](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/documentation-button) [NextDebug Draw system](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/debug-draw-system) Last updated 6 months ago --- # Libraries | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/libraries.md) . `OmniToolbox` comes with several function libraries that are constantly expanding. Each one can be found in the runtime module inside the `FunctionLibraries` folder to simplify the API. It's highly recommended to look over the templates and functions provided. This can easily be done before installing the plugin by reviewing the [Github page](https://github.com/Varian-s-Unreal-Plugins/OmniToolbox/tree/main/Source/OmniToolbox/Public/FunctionLibraries) Many of these libraries contain various functions from either my projects, or been posted onto the Epic forums to solve a specific problem. They also contain functions that - for some unknown reason - Epic have not provided a way to call from blueprint (such as `GetParentTag`) [PreviousFloat Providers](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/float-providers) [NextWorld Settings and actions](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/world-settings-and-actions) Last updated 7 months ago --- # Hiding properties | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/hiding-properties.md) . In some scenarios, you might want to hide a property from the details panel for various reasons. I wanted this feature because I have a custom GAS ability component with custom ability sets and GAS abilities. I am using `GAS Companion`, which has its own ability set and default abilities. To reduce UI clutter and reduce chances of someone mixing up which one to use, I added a UCLASS meta property to hide properties by their names ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FiocWfqiIm0fO7mIJc6C4%252Fimage.png%3Falt%3Dmedia%26token%3D67e50139-5ea8-4901-9e7f-07f6e727cb18&width=768&dpr=3&quality=100&sign=59a31240&sv=2) This does not work for classes that have a custom `IDetailCustomization`class. Last updated 1 year ago --- # Activating the component | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component.md) . * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component#starting-the-component) Starting the component ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Starting the component is very simple, just call **AC\_Inventory** \-> **StartComponent**. The bigger challenge will be deciding when you want to call this function. Typically this can be called at **BeginPlay** or when the player gets close to the actor. This will depend on some factors, the biggest being if any item inside the component will be visually present AND if they have a spawn chance. For example; a gun with a sight on it and the sight has a spawn chance. The sight's spawn chance might fail, and you might want the sight to get removed off the gun. Another example would be an NPC that is wearing some armor that has a spawn chance. If the armor fails its spawn chance, you'll probably want to modify some attributes and remove the armor. This type of logic is very project dependant and depends on if the inventory component is eating up any impactful performance. I suggest leaving the **StartComponent** function on **BeginPlay**, and when it's time to optimize your games performance, then you start evaluating if calling **StartComponent** is more worthwhile being called at different times. The order of the items inside every container is very important. If you hover over an items **TileIndex** you'll see your options. If an item is set to finding the first tile available or a random tile, then another item attempts to spawn on top of that item, it'll fail. There is a delegate which will fire whenever an item fails to spawn. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component#stopping-the-component) Stopping the component ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This function will remove all widgets and object references. Under no circumstances should this function be called while the player is actively interacting with the component. Here's a list of scenarios where you want to refrain from calling **StopComponent**. 1. The player will be interacting with the component within a short period of time, perhaps within 10 minutes. 2. If the player will be interacting with the component again, if the component has a lot of items or a lot of containers and it causes a noticable hitch when starting the component, it might be more efficient to keep the component active. 3. The component has items that have a spawn chance. Every time the component starts, it'll roll these spawn chances. 4. In a multiplayer scenario, you'll be eating a potentially large RPC call every time you start the component. If you stop the component and the player interacts with this component again, the **StartComponent** function will call a RPC that might be quite large. The component can not be stopped while its **Listeners** array is not empty, which is used for multiplayer. If your games memory usage is tight, it might be worthwhile trying to call **StopComponent**, but the above points must be kept in mind. What might be worthwhile for you to optimize would be to try and clean up any widgets and object references the component is holding onto. That is most often the root of any performance issues after activating a component with a lot of items. [PreviousAdding the component and containers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/adding-the-component-and-containers) [NextCustom Interaction system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system) Last updated 1 year ago * [Starting the component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component#starting-the-component) * [Stopping the component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component#stopping-the-component) --- # Unknown \# Varian's Documentation ## Landing Page - \[Welcome\](https://varian.gitbook.io/varian-docs/welcome.md) - \[Who am I?\](https://varian.gitbook.io/varian-docs/who-am-i.md) - \[My design style\](https://varian.gitbook.io/varian-docs/my-design-style.md) - \[Suggested Plugins\](https://varian.gitbook.io/varian-docs/suggested-plugins.md) ## Inventory Framework - \[Welcome to IFP\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/welcome-to-ifp.md) - \[Introduction\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction.md) - \[First Steps\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps.md) - \[Installing the plugin\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin.md) - \[Asset Manager\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager.md) - \[Example Project\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project.md) - \[Adding the component and containers\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/adding-the-component-and-containers.md) - \[Activating the component\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component.md) - \[Custom Interaction system\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system.md) - \[Suggested Plugins\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins.md) - \[How does the system work?\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work.md) - \[How does the networking work?\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work.md) - \[Style Guide\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide.md) - \[Test Environment\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/test-environment.md) - \[Classes and Settings\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings.md) - \[A\\\_ItemActor\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a\_itemactor.md) - \[AC\\\_Inventory\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac\_inventory.md) - \[BP\\\_PreviewActor\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp\_previewactor.md) - \[DA\\\_CoreItem\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da\_coreitem.md) - \[Traits and Components\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components.md) - \[W\\\_Attachment Parent\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_attachment-parent.md) - \[W\\\_Container\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_container.md) - \[W\\\_Drag\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_drag.md) - \[W\\\_Highlight\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_highlight.md) - \[W\\\_InventoryItem\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_inventoryitem.md) - \[W\\\_Tile\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_tile.md) - \[WBP\\\_ContextMenu\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp\_contextmenu.md) - \[WBP\\\_Tooltip\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp\_tooltip.md) - \[Systems\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems.md) - \[Ability System Integration\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration.md) - \[Crafting\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting.md) - \[External Objects\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects.md) - \[Fragments\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments.md) - \[Item Query\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query.md) - \[Item Sockets\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-sockets.md) - \[Loot Tables\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables.md) - \[Saving and loading\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading.md) - \[Tags and Tag Values\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values.md) - \[Templates for inventory and containers\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers.md) - \[Tile Tags\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags.md) - \[UI Navigation\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation.md) - \[Working in the system\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system.md) - \[Adding new items during runtime\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime.md) - \[Creating custom functions\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions.md) - \[Creating custom widgets\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets.md) - \[Creating new items\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items.md) - \[Compatibility Settings\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings.md) - \[Drag and drop\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/drag-and-drop.md) - \[Equipping and unequipping items\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items.md) - \[Modifying Critical Files\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files.md) - \[Optimizations\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations.md) - \[Setting up vendors\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors.md) - \[Sorting Items\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items.md) - \[Tools\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools.md) - \[Inventory Helper\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper.md) - \[Item Editor\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor.md) - \[Versions\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions.md) - \[3.4\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4.md) - \[3.3.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1.md) - \[3.2.2\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2.md) - \[3.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1.md) - \[3.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0.md) - \[2.11\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11.md) - \[2.10.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1.md) - \[2.9.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0.md) - \[2.8.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1.md) - \[2.7.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1.md) - \[2.6.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0.md) - \[2.5.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1.md) - \[2.4.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0.md) - \[2.3.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0.md) - \[2.2.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0.md) - \[2.1.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0.md) - \[2.0.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1.md) - \[1.2.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0.md) - \[1.1.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1.md) - \[1.0.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.0.0.md) - \[F.A.Q\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q.md) - \[Bugs\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs.md) ## Tags Metadata - \[Tags Metadata\](https://varian.gitbook.io/varian-docs/tagsmetadata/tags-metadata.md) ## Input Nexus - \[Welcome to Input Nexus\](https://varian.gitbook.io/varian-docs/input-nexus/welcome-to-input-nexus.md) - \[Nexus Component\](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component.md) - \[Input Link\](https://varian.gitbook.io/varian-docs/input-nexus/input-link.md) - \[Link Bundle\](https://varian.gitbook.io/varian-docs/input-nexus/input-link/link-bundle.md) - \[Input Buffer\](https://varian.gitbook.io/varian-docs/input-nexus/input-link/input-buffer.md) - \[Cog\](https://varian.gitbook.io/varian-docs/input-nexus/cog.md) - \[To-do\](https://varian.gitbook.io/varian-docs/input-nexus/to-do.md) - \[Changelog\](https://varian.gitbook.io/varian-docs/input-nexus/changelog.md) ## Object Tags - \[Object Tags\](https://varian.gitbook.io/varian-docs/object-tags/object-tags.md) - \[Cog\](https://varian.gitbook.io/varian-docs/object-tags/cog.md) - \[Changelog\](https://varian.gitbook.io/varian-docs/object-tags/changelog.md) ## Object Recycler - \[Object Recycler\](https://varian.gitbook.io/varian-docs/object-recycler/object-recycler.md) - \[Warmup Pool\](https://varian.gitbook.io/varian-docs/object-recycler/warmup-pool.md) - \[Cog\](https://varian.gitbook.io/varian-docs/object-recycler/cog.md) ## Tag Facts - \[Tag Facts\](https://varian.gitbook.io/varian-docs/tag-facts/tag-facts.md) - \[Integrations\](https://varian.gitbook.io/varian-docs/tag-facts/integrations.md) ## ImGui (Cog) setup - \[ImGui (Cog) setup\](https://varian.gitbook.io/varian-docs/imgui-cog-setup/imgui-cog-setup.md) - \[Cog's presence detection\](https://varian.gitbook.io/varian-docs/imgui-cog-setup/cogs-presence-detection.md) - \[Enabling the ImGui debuggers\](https://varian.gitbook.io/varian-docs/imgui-cog-setup/enabling-the-imgui-debuggers.md) ## Blueprint Tasks Extension - \[Blueprint Tasks Extension\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/blueprint-tasks-extension.md) - \[Task Graphs\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs.md) - \[Dialogue\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue.md) - \[Decorator\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue/decorator.md) - \[Quests\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests.md) - \[Decorator\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests/decorator.md) - \[Other nodes\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/other-nodes.md) ## OmniToolbox - \[OmniToolbox\](https://varian.gitbook.io/varian-docs/omnitoolbox/omnitoolbox.md) - \[Structure and contribution\](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution.md) - \[Macros\](https://varian.gitbook.io/varian-docs/omnitoolbox/macros.md) - \[Todo\](https://varian.gitbook.io/varian-docs/omnitoolbox/todo.md) - \[Content Browser\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/content-browser.md) - \[Thumbnail Renderer\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/thumbnail-renderer.md) - \[Hiding properties\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/hiding-properties.md) - \[Macros\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/macros.md) - \[Documentation button\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/documentation-button.md) - \[Place Actor Palette control\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/place-actor-palette-control.md) - \[Debug Draw system\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/debug-draw-system.md) - \[Asset Validation\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/asset-validation.md) - \[Float Providers\](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/float-providers.md) - \[Libraries\](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/libraries.md) - \[World Settings and actions\](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/world-settings-and-actions.md) - \[Spreadsheet Object\](https://varian.gitbook.io/varian-docs/omnitoolbox/tools/spreadsheet-object.md) - \[Versions\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions.md) - \[0.3\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3.md) - \[0.2\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2.md) - \[0.1\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.1.md) - \[Introduction\](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/introduction.md) - \[Functional Tests\](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests.md) - \[Test Environment Guide\](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on a page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/welcome.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Float Providers | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/float-providers.md) . A borrowed concept from [Hogwarts Legacy](https://www.youtube.com/live/CeX9uFRfyxE?si=D1rVcFOYZfwgCrfl&t=20981) . This is a simple instanced struct that will return a float. You can make children of this struct to create new available dropdowns. I use this for my GA base cooldowns. In some cases, I want a scalable float or a runtime float curve. The plugin comes with three examples: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FSOjETTdoixgMmbf4ALo6%252Fimage.png%3Falt%3Dmedia%26token%3D1e69e5b1-013a-4b6f-b438-c9018360917b&width=768&dpr=3&quality=100&sign=5012c37d&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252Fy53LsW5FVXIfm96JBwEB%252Fimage.png%3Falt%3Dmedia%26token%3D8ecbe8a5-630d-46a5-bfb8-151e523e184c&width=768&dpr=3&quality=100&sign=b3103836&sv=2) To use a float provider, make a variable with `FOmniFloatProvider` as the type. You can optionally give it a default value and a default float provider child. Depending on the type you're using, you might have to initialize the data float provider like so: [PreviousAsset Validation](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/asset-validation) [NextLibraries](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/libraries) Last updated 6 months ago Copy UPROPERTY() FOmniFloatProvider Duration = FBasicFloatProvider(5); Copy Duration.FloatProvider.GetMutable<>().WorldContext = GetWorld(); Duration.FloatProvider.GetMutable<>().BaseValue = SomeFloat; --- # Introduction | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction.md) . * This plugin was created for an open-world game that had very strict performance requirements. Because of this, most logic is handled in C++ and only minor , designer-based things are handled in Blueprint. The design architecture is also designed to give programmers more control of when widgets and data is initialized to not just optimize memory, but also reduce lag spikes. The architecture has also been made in mind for large-scale projects by providing useful editor tools. * The architecture was made with designers in mind, so certain C++ functions can be overridden in Blueprints and some functions are only needed on the Blueprint level. This system is not meant to be purely C++ or Blueprints, rather a healthy mix of the two. If you can't write in C++ or don't have access to anyone who can write C++ code for you, the current functions should allow for you to create nearly any Blueprint logic you should need. * The plugin was designed to be [**installed locally**](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin) to your project, not the engine. * Many things have been designed to be as abstract as possible and assume as little as possible about YOUR project and creation process. I do not want to dictate any creative vision and I do not want to step on any toes. I’ve tried to keep the system as painless as possible for you to integrate YOUR systems and assets with this inventory system, such as an attribute, ability or crafting system. Even though some of those things are provided out of the box, every project is unique and has specific requirements that you may have already solved. [PreviousWelcome to IFP](https://varian.gitbook.io/varian-docs/inventoryframework) [NextFirst Steps](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps) Last updated 1 year ago --- # Asset Validation | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/asset-validation.md) . `OmniToolbox` provides a module called `OmniToolboxValidation` that provide several asset validators that suit all projects and providing a project settings category to control them. The default asset validation system has one critical flaw; Any marketplace assets you import or utilize in your project might fail the validator (such as a naming convention). But modifying these external assets can make updating them very difficult. `OmniToolbox` looks to optionally solve this through its project settings. You can make all validators that are children of `UOmniAssetValidator` ignore certain paths by adding those paths to the `Directories To Ignore` array. The `FDirectoryPath` struct seems to be bugged as of 5.7, which is the struct that provides a dropdown view of the projects directories. You might have to restart your project for your modifications to be registered. [PreviousDebug Draw system](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/debug-draw-system) [NextFloat Providers](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/float-providers) Last updated 6 months ago --- # Custom Interaction system | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system.md) . The plugin does come with an extremely basic interaction system, which is designed to be replaced. This page covers how to replace it. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system#id-2.7-and-above) 2.7 and above: ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Simply replace the **PreInteract**, **StartInteract** and **EndInteract** with your own interaction functions inside **BP\_ItemActor** and **BP\_Interactable**. All three functions are inside **BPI\_Interact**, which can be found in the plugins demo folder and removed once these three functions are replaced. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system#id-2.6-and-below) 2.6 and below: ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ * There are two functions, **StartInteract** and **FinishInteract**. The first will send an RPC to the server, then the server will send the client any data around the component the client needs, then trigger **AC\_Inventory** \-> **OnDataReceivedFromOtherComponent**, which will call **FinishInteract**. This is handled in this way because allowing players to interact with the actors component before replication is finished can lead to a lot of bugs. Not because there are issues in the plugin, but because of the nature of clients modifying an actor that isn't in sync. Virtually every multiplayer game handles it in this way unless they have client prediction and network rollback. This is the only "gotcha" that needs to be kept in mind. In general, you should already not be allowing players to interact with actors that are waiting on an RPC. With the above point in mind, you can start replacing all the functions with your own. The only ones that other systems rely on are **GetAnimationData** and **UpdatePreview**. [PreviousActivating the component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component) [NextSuggested Plugins](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins) Last updated 1 year ago * [2.7 and above:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system#id-2.7-and-above) * [2.6 and below:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system#id-2.6-and-below) --- # First Steps | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps.md) . [Installing the plugin](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin) [Asset Manager](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager) [Example Project](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project) [Adding the component and containers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/adding-the-component-and-containers) [Activating the component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component) [Custom Interaction system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system) [Suggested Plugins](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins) [PreviousIntroduction](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction) [NextInstalling the plugin](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin) --- # Suggested Plugins | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins.md) . This is a list of plugins that I personally suggest you use alongside this plugin. None of these are mandatory and completely optional. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#gas-companion) [**GAS Companion**](https://www.unrealengine.com/marketplace/en-US/product/gas-companion) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Unreal Engine's built-in Gameplay Ability System (GAS) is extremely powerful and is becoming an industry standard. There is a problem with it though; it's very beginner-unfriendly. It's annoying to make attributes and can take a long time to set it up. The plugin GASCompanion does all the heavy lifting for you, has good documentation and good Discord support. I am not implementing a attribute or ability system with this system because I believe you should be using GAS (Either a plugin or your own implementation). * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#flow-graph) [**Flow Graph**](https://github.com/MothCocoon/FlowGraph) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Made by one of the developers of Witcher 2 and 3 and is being backed by Riot Games, this plugin has revolutionized how I make things like quests, dialogues and much more. A tool that I truly think should be introduced to Unreal's base toolset. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#unrealimgui) [**UnrealImGui**](https://github.com/IDI-Systems/UnrealImGui) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- DearImGui is a great tool used in tons of game engines and is amazing for debugging your game. You can get blueprint support through [**ImGuiBlueprint**](https://github.com/TheEnbyWitch/ImGuiBlueprint) (I have a [**personal repo**](https://github.com/Variann/ImGuiBlueprint) where I've added more widget support) I sometimes use this plugin to quickly visualize data from a bunch of items while in-game. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#editorscriptingtools) [**EditorScriptingTools**](https://github.com/HoussineMehnik/UE4-EditorScriptingToolsPlugin) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This plugin lets you customize the editor without touching C++. This way you can add UMG widget tools into the item data asset all inside blueprints and without touching the plugin. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#my-other-free-plugins) [**My other (free) plugins**](https://github.com/Variann/ModularityPractice) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ I make other plugins to solve problems when I'm making games. These are MUCH smaller and simpler plugins compared to IFP. Some of them are unfinished, some of them might have bugs, but due to their simplicity and small size, the chances of bugs are low and fixing them is pretty fast. [PreviousCustom Interaction system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system) [NextHow does the system work?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work) * [GAS Companion](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#gas-companion) * [Flow Graph](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#flow-graph) * [UnrealImGui](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#unrealimgui) * [EditorScriptingTools](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#editorscriptingtools) * [My other (free) plugins](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins#my-other-free-plugins) --- # Example Project | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project.md) . Important This documentation only covers the new example project. The old example project does not have any documentation The example project can be downloaded from the marketplace linked at the top of the site. This document will cover how the example project works and how best to utilize it. * First, I never recommend people build ON TOP of any example projects from any asset, including `IFP`. You should always create a fresh project and use the example project as either inspiration, or get access to the Github repo and start forking the example projects. * The example project does not contain anything by itself. It is rather a host for 1 plugin (`IFP_CommonAssets`) which hosts common assets and classes, and then all example projects are their own plugins utilizing this plugin. This way, it is extremely simple for people to get going with a basic example with simple integration into YOUR project, while having Github submodule support. If you install any of the example plugins, remember to: 1. Update your asset manager to include their `Items` folder inside the `Directories` array. If you are using `IFP`'s crafting system, you will also want to include the `Crafting -> Recipes` folder. 2. Go into your project settings -> GameplayTags and add the plugins tag table into the `Gameplay Tag Table List`. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#scope) Scope ------------------------------------------------------------------------------------------------------------------------------------------ The scope of example projects are very small, for a few reasons: 1. I do not have infinite time on my hands. I'd rather improve the base plugin rather than spend too much time on the examples. 2. To keep them as simple as possible with as few classes as possible. You are already diving into a pretty large framework, I do not want to create example projects that may be too complicated for some. 3. With point 2 in mind, replication is NOT kept in mind for the example projects in some cases, for example playing a montage and ensuring its playing on all clients. `IFP` is already replicated and it already automatically handles the majority of replication for you and many projects built with `IFP` are being built with replication in mind, but not everyone is making a multiplayer game. So I would just be making more complicated code and taking up more of my time to test things that should be replaced with your systems or customized to fit your project anyways. This trade-off is necessary for allowing me to continue creating example projects, developing `IFP` and still work on my personal projects and game. 4. Extremely few assets, such as models, textures and so forth. These projects are meant to be as small as possible in not just assets, but also disk size. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#project-structures) Project structures -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Each example project is built with a dependency on `IFP_CommonAssets`, so no matter what project you pick, that plugin also has to be installed. This section covers how each project is structured and handled. * Hierarchy between classes is kept to a minimum and the character blueprint only handles the bare minimum, such as adding the HUD and handling common inputs. Rather, much of the code is handled through actor components, which allows you to quickly get started and you do not have to worry about hierarchy-hell. Most components have a comment box at the top of the event graph explaining their purpose. If you wish to use any of these components in your project, I suggest making a child of each so any updates won't override your changes. * **AC\_QuickStartHelper\_IFP** \- Handles common delegates and inputs based around inventories, such as adding the inventory to the screen and starting the inventory component. This is simply to quickly get you started to make sure `IFP` is working correctly in your project or act as a wrapper to contain all code based around `IFP` without modifying your character blueprint. * **AC\_BasicInteraction\_IFP** \- Enables the basic interaction system that comes with IFP (This system is designed to be replaced, which this [**documentation**](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system) covers) * **AC\_QuickLootHelper\_IFP** \- Handles the quick loot example system. * **BP\_AC\_EquipmentHelper** \- Handles `IFP`'s default equipment system, which can be modified or completely replaced. * **BP\_AC\_Interactable** \- Enables the actor to be treated as an interactable. Such as a chest or a vendor. * Each plugin gets its own gameplay tags table. You do not need to install any of the example projects to get these helper components. You can simply install the `IFP_CommonAssets`plugin into your project and you'll then have all the assets from the showcase. The only thing you'd need to update is your mapping context or the input action events the helper components use. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#examples) Examples ------------------------------------------------------------------------------------------------------------------------------------------------ * **Showcase**: This example is simply trying to fit in all features of `IFP` into one showcase. * **RPG**: Example of a traditional inventory, with a quick slot system and a upgrade station. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#github-repository-access) Github repository access -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Github access is not required to get the example project. The example project can be downloaded from the product page. To access the plugins repository and the associated example plugins plugins, you will need to verify your purchase by forwarding your Epic Games receipt to my email (Varianprofessional@gmail.com) with your Github username or send me a message with the order ID. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#old-example-project-differences) Old example project differences ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The primary way that the old example project and the new one are different is how the player character is setup. Both in my personal project and in `IFP`, I am trying to de-bloat the player character as much as possible. All the components listed above contain the vast majority of the logic that used to be in the player character. [PreviousAsset Manager](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager) [NextAdding the component and containers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/adding-the-component-and-containers) Last updated 1 year ago * [Scope](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#scope) * [Project structures](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#project-structures) * [Examples](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#examples) * [Github repository access](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#github-repository-access) * [Old example project differences](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#old-example-project-differences) --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/welcome-to-ifp.md). # Welcome to IFP \*\*\* \[Marketplace \](https://www.fab.com/listings/a936148d-d2c2-4795-9de7-e7cf8ebb9bdd)| \[Youtube \](https://www.youtube.com/@VarianDaemon\_)| \[Discord\](https://discord.com/invite/bBfa9pwtEn) | \[Trello\](https://trello.com/b/pE2DJRlb/inventory-framework-plugin) \*\*\* ## What is the Inventory Framework Plugin? Nearly every inventory system shares the same foundation, a container with tiles and items slot into those tiles. This Inventory Framework Plugin (IFP) attempts to be that foundation for your project, while allowing for a high level of inventory design, item customization, rapid prototyping and system integration. From my research, inventory systems were taking 2-6 months or more (depending on how advanced it was) to be designed, bug tested, network tested and to be documented. With this framework, I try to provide you the framework needed to create your perfect inventory system and bring that initial creation time down. What this provides is the C++ foundation for your programmers and a good Blueprint foundation for your designers, which includes: 1. Actor components and item parents that handle all the logic for you and are abstract enough so you can implement your mechanics and systems into it. 2. Perhaps the most network optimized inventory system on the marketplace. 3. Only inventory system on the marketplace with custom shaped items. 4. Widgets that are designer friendly (Easy to implement new logic, add animations to events, create children, etc). They also handle all the drag, drop, highlighting, splitting, combining logic and more. Unlike many other assets, widgets in IFP are highly customizable and have very few limits, allowing you to easily customize your inventories visuals. 5. A system that has no reliance on widgets to create or handle its data, meaning everything you need to know about an item is always accessible in a highly performant manner. 6. Recursive items, meaning items inside of items for as long as you want. 7. Actor appearance duplication system that copies the appearance of your items allowing you to both inspect items and auto-generate icons. It works with all actors, not just item actors. No longer do you need to follow a strict actor hierarchy setup like many other inventory systems need. You can create your items and actors however you want and the system will automatically duplicate the appearance for either generating item icons or letting you examine an item. 8. Powerful in-game and in-editor tools to improve quality control and speed up workflow. It is NOT an inventory to fully replicate the mechanics of any specific game. If you want your system to behave like a specific game. This framework provides you with the functions, data and systems to replicate most inventory systems. If you have any issues or questions neither the videos or documentation answer then feel free to message me on Discord (Variandaemon) or join the discord channel. You can look at the FAQ for more info. \*\*\* ## Color Sheet: \*\*functions\*\* - \*\*variable\*\* - \*\*category\*\* - \*\*class\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/welcome-to-ifp.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Structure and contribution | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution.md) . `OmniToolbox` comprises of 2 modules: * OmniToolbox * Contains various helper function libraries and other things that are only relevant to runtime based logic. * Runtime module * OmniToolboxEditor * Contains developer settings, thumbnail renderer, content browser modification and many other editor-only based changes. * Editor module [](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#creating-plugins-with-omnitoolbox) Creating plugins with OmniToolbox --------------------------------------------------------------------------------------------------------------------------------------------------------- ### [](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#copyright) Copyright `OmniToolbox` is published under the MIT license and everyone has permission to fork it, copy the code, or publish their own version. ### [](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#minimal-implementation) Minimal implementation By minimal, I mean no gameplay features and having the possibility of using your plugin without having OmniToolbox installed. This can be done like so: 1. Add this code to your modules build.cs file: 1. Wrap your code with `#if OMNITOOLBOX_INSTALLED` * Blueprints do NOT have the ability to filter code like this. If you add any blueprint code to your project that originates from `OmniToolbox`, you now have a hard dependency on `OmniToolbox`. * Instead of checking if `OmniToolbox` is installed, I recommend checking by version #### [](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#asset-details-interface) Asset details interface From my testing, there seems to be an issue with Unreal recognizing interfaces while in the editor when it comes to interfaces wrapped with preprocessor macros The code above will compile and during runtime will continue to work normally, I've even validated this with my other plugins and using other interfaces. But while in the editor, it will not work. Unfortunately, this interface must work while in the editor. If you want to make assets utilize the interface, but still be able to compile the plugin without `OmniToolbox` installed, you will have to do this evil hack: This is essentially just creating a new class with the same name if the plugin isn't installed. It's not ideal, but it's the best we can do for now. [](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#making-contributions) Making contributions ------------------------------------------------------------------------------------------------------------------------------- `OmniToolbox` follows 3 philosophies: 1. Simplify the lives of developers (for example; utility functions, systems or [macro's](https://varian.gitbook.io/varian-docs/omnitoolbox/macros) to reduce repetitive work, such as giving assets custom icons) 2. Adding abstract features (for example; [float providers](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/float-providers) ) 3. Exposing C++ logic to blueprints (for example; gameplay tags have many functions that for some reason Epic have not exposed to blueprint) Any contribution that wants to be accepted should try and follow these goals. Examples of contributions that would get declined: * Combat system using GAS * A combat system is not abstract enough (not all games have combat) and not everyone wants a dependency on GAS * Prototyping assets, such as materials, widgets, etc * This can quickly clutter up people's projects and asset validators in some projects might not be happy with these assets. * While useful, I feel like a separate plugin, specifically designed for prototyping material, should be developed. I might create one to speed up development of my example projects, but there's no guarantee on that. In some cases, it might be better for some people to simply make a pull/feature request for the engine itself. [PreviousOmniToolbox](https://varian.gitbook.io/varian-docs/omnitoolbox) [NextMacros](https://varian.gitbook.io/varian-docs/omnitoolbox/macros) Last updated 7 months ago * [Creating plugins with OmniToolbox](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#creating-plugins-with-omnitoolbox) * [Copyright](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#copyright) * [Minimal implementation](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#minimal-implementation) * [Making contributions](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution#making-contributions) Copy if(Plugins.GetPlugin("OmniToolbox") != null) { PublicDefinitions.Add("OMNITOOLBOX_INSTALLED=1"); PublicDependencyModuleNames.Add("OmniToolbox"); PublicDependencyModuleNames.Add("OmniToolboxRuntime"); } else { PublicDefinitions.Add("OMNITOOLBOX_INSTALLED=0"); } Copy #if OMNITOOLBOX_INSTALLED Omni_SetClassIcon(AgentIntelligenceFramework, EntityController, EntityControllerSlate) #endif Copy UTexture2D* GetThumbnail_Implementation() { #if OMNITOOLBOX_INSTALLED if(FEffectDataUIIcon* EffectIcon = GetStructPtrFromInstancedStructArray(EffectDefinition.Effect.Data)) { return EffectIcon->Icon.LoadSynchronous(); } #endif return nullptr; } Copy UCLASS(Abstract, Blueprintable) class AIF_MASS_API AEntityController : public AController #if OMNITOOLBOX_INSTALLED , public II_AssetDetails #endif Copy #if !OMNITOOLBOX_INSTALLED class II_AssetDetails {}; #endif UCLASS(Abstract, Blueprintable) class AIF_MASS_API AEntityController : public AController, public II_AssetDetails --- # World Settings and actions | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/world-settings-and-actions.md) . `OmniToolbox` provides a system similar to Lyra's user experience system. By changing your World Setting's class in the project settings to `OmniWorldSettings`, you will get a new array of `WorldActions` inside the `World Settings` panel. When the world's BeginPlay is activated, these world actions are activated. [](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/world-settings-and-actions#uomniworldaction) UOmniWorldAction ------------------------------------------------------------------------------------------------------------------------------- Utilized by the `UOmniWorldSettings` class during `BeginPlay`to enable specified game features and activate specific game feature actions, or enable specific game features. [PreviousLibraries](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/libraries) [NextSpreadsheet Object](https://varian.gitbook.io/varian-docs/omnitoolbox/tools/spreadsheet-object) Last updated 7 months ago --- # Spreadsheet Object | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/tools/spreadsheet-object.md) . `OmniToolbox` provides a `SpreadsheetObject` which can be constructed and passed around as a pointer to manage a singular HTML spreadsheet, which can then later be imported into google sheets. To use the spreadsheet object, you call `Initialize` and declare your headers. Headers are the columns at the very top and dictate how far a row can get. You then call `AddRowByName` and store the index. You then call `GetColumnIndexByHeader` and store the index To then modify a cell, you call `EditCell` and pass in the stored row and column index to modify the cell. The file is then saved inside `ProjectFolder/Saved/Spreadsheets` whenever `Save` is called. [](https://varian.gitbook.io/varian-docs/omnitoolbox/tools/spreadsheet-object#why-html) Why HTML? ------------------------------------------------------------------------------------------------------ Every solution I could find to generate a CSV or XLSX file that supported coloring cells required external libraries. These libraries are so popular that I could not find any reliable source of information to create my own without plainly copying the existing libraries. This would be a ton of work for very little gain. Generating a table in HTML with colored cells is very simple and most excel programs can import HTML files, such as Google Sheets and Microsoft Excel. [PreviousWorld Settings and actions](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/world-settings-and-actions) [NextVersions](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions) Last updated 6 months ago --- # 0.1 | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.1.md) . Marketplace and beta release [Previous0.2](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2) [NextIntroduction](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/introduction) Last updated 6 months ago --- # 0.3 | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3.md) . [](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3#macros) Macros ---------------------------------------------------------------------------------------------- * Added `Omni_PlacementPaletteCategory`, which allows you to easily create a new category inside the `Place Actors` tool and the `Place Actor` dropdown near the level viewport's `Selection Mode` * Added `Omni_AddActorToPlacementPaletteCategory`, which adds an actor to a placement palette category * Blueprint users can add a blueprint to the placement palette through the `OmniToolbox` project settings through `Placement Palette Actors` array. For now, the editor has to be restarted when adding to this array. [](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3#vanguard) Vanguard -------------------------------------------------------------------------------------------------- * `Vanguard` is a new module extending Unreal's automation tooling and will be powering all testing environments for my future plugins. * Documentation can be found [here](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/introduction) [PreviousVersions](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions) [Next0.2](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2) Last updated 5 months ago * [Macros](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3#macros) * [Vanguard](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3#vanguard) --- # Test Environment | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/test-environment.md) . The Test environment for `IFP` utilizes `OmniToolbox`'s automation framework to power a plugin called "IFP\_TestingEnvironment". This plugin can be accessed through `IFP`'s github organization. * [How to request access to the Github organization](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project#github-repository-access) * `OmniToolbox` [Fab page](https://www.fab.com/listings/db6ebd6c-e95d-40c3-9a9d-1c9d815e6295) and [Github repo](https://github.com/Varian-s-Unreal-Plugins/OmniToolbox) This environment hosts a number of testers to validate `IFP` is functioning as expected and provide numerous small code-snippets for how to utilize IFP The test environment is NOT for testing replication. Results of these tests only apply to single player and server. [PreviousStyle Guide](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide) [NextClasses and Settings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings) Last updated 6 months ago --- # 0.2 | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2.md) . [](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2#float-provider) Float Provider -------------------------------------------------------------------------------------------------------------- * Structs have been renamed, added a new `FOmniFloatProvider` which exposes instanced structs to blueprint users and enables struct customization. * Float providers have been customized. It now enforces at least a basic float provider, ensuring a null instanced struct is never assigned and puts a input value into the title. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FHHhxF8hOciJCXL8DeE1Q%252Fimage.png%3Falt%3Dmedia%26token%3Dd82edd87-3f6f-4679-b3a5-e17fdb34e3e2&width=768&dpr=3&quality=100&sign=2eefa20b&sv=2) [](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2#new-functions) New functions ------------------------------------------------------------------------------------------------------------ * Exposed `AddInstanceComponent` to blueprints, which helps add actor components through scriptable tools and ensure they get serialized. [](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2#bug-fixes) Bug fixes ---------------------------------------------------------------------------------------------------- * `Omni_InsightsTrace` was not using \_\_FUNCTION\_\_ correctly [Previous0.3](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3) [Next0.1](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.1) Last updated 6 months ago * [Float Provider](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2#float-provider) * [New functions](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2#new-functions) * [Bug fixes](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2#bug-fixes) --- # Style Guide | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide.md) . I have tried to follow the popular [**UE5 Style Guide**](https://github.com/Allar/ue5-style-guide) . Though I may sometimes accidentally or purposefully sway from it. I am very open to criticism, if something is confusing or inconsistent, don't hesitate to let me know. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide#functions) Functions ---------------------------------------------------------------------------------------------------------------------------------- Networking functions are prefixed with **C\_** for client, **S\_** for server and **MC**\_ for multicast. For functions that attempt to automate replication, the bulk of the function's code is stored in a function with a **Internal\_** prefix. These are typically called both by the server and client. If you want access to the internal functions, you will need to add **BlueprintCallable** to the UFUNCTION above them. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide#tools) Tools -------------------------------------------------------------------------------------------------------------------------- All editor utility widgets are stored inside Plugin folder -> Content -> Core -> Widgets -> EditorUtilityWidgets -> Tools. Any widgets or special components for each editor utility widget is stored in its own folder named after the editor utility widget inside the EditorUtilityWidgets folder. This is done so you can bookmark/favourite the Tools folder and have access to all the tools quickly. You can also find all your editor utility widgets at the top of the editor -> Tools -> Tools, though there is no way to separate the inventory tools from your own editor utility widgets. [PreviousHow does the networking work?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work) [NextTest Environment](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/test-environment) * [Functions](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide#functions) * [Tools](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide#tools) --- # Functional Tests | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests.md) . Due to dependency issues with the `FunctionalTesting` module, `OmniToolbox` can't make a C++ child of `AFunctionalTest`. Hence why we use an actor component instead. `Vanguard` offers an actor component designed specifically to be placed on `AFunctionalTest` actors called `TestAssistantComponent`. It provides several utilities, such as: * Generate a spreadsheet that displays what sub-tests were successful and what sub-tests failed. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FiMoriGBdRdF2gAvE0oVQ%252Fimage.png%3Falt%3Dmedia%26token%3Daa3c7a34-8187-45ec-a872-8025b8a438d8&width=768&dpr=3&quality=100&sign=cab3de35&sv=2) This code will generate this spreadsheet (if the `OmniToolbox.Vanguard.GenerateSpreadsheet` console variable is set to true) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FlxDKqc5XB8ZND3FQHBJE%252Fimage.png%3Falt%3Dmedia%26token%3D132d1959-2234-42db-a003-b667688239d9&width=768&dpr=3&quality=100&sign=2054823e&sv=2) * When running a test, a folder with the current timestamp is created that can contain several files. One being a performance log (Do NOT use these numbers to drive your performance metrics if the session was in PIE. Only use these numbers for packaged builds). ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FJ3ArIYnhGaSzejEHoRMo%252Fimage.png%3Falt%3Dmedia%26token%3Daf61440f-2e5f-4355-b64a-54d265c6ef3c&width=768&dpr=3&quality=100&sign=1401253a&sv=2) The other files can be visual log files or spreadsheets generated from tests. If no file was generated, then that test did not want to generate a spreadsheet and did not use the visual logger. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FHhaOR8AOoxtlwLiSJjNY%252Fimage.png%3Falt%3Dmedia%26token%3D8e2bae85-846a-4b9e-be1c-8141a5849e1b&width=768&dpr=3&quality=100&sign=43ec744e&sv=2) When doing tests through the project launcher, these files can be found in `Saved -> StagedBuilds -> Platform (for example; Windows) -> ProjectName -> Saved -> Automation -> Vanguard` [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests#unreal-insights-integration) Unreal Insights Integration -------------------------------------------------------------------------------------------------------------------------------------------- The assistant allows you to automatically begin and end a trace for the duration of a test. (Enable `Automatically Start Insights Trace` in the components settings) When this is used, the assistant also automatically: * Takes a screenshot when the `WriteResults` function encounters an error ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FMgH1d19fGuY6UdaEnFfT%252Fimage.png%3Falt%3Dmedia%26token%3D21403204-d7f0-437d-92dc-46c665350058&width=768&dpr=3&quality=100&sign=4de9273d&sv=2) * When a new spreadsheet row is added, we start a new region * The trace file is moved from the profiling directory and into the `Vanguard` folder and renamed to the testers name. You can drag and drop a `.utrace` file into Unreal Insights to open it Stopping a trace can cause a spike in FPS. ### [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests#notes) Notes * By default, all trace channels are disabled when making a new profile. You will want to f[amiliarize yourself](https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-insights-reference-in-unreal-engine-5#tracechannels) with them and enable the ones you want. * The more you enable, the larger the trace file and potentially more performance overhead. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FMImAXtpOPedwjxfJuIK2%252Fimage.png%3Falt%3Dmedia%26token%3Dbd0ffdf5-117b-406b-bdf3-e13049651c5c&width=768&dpr=3&quality=100&sign=9033425e&sv=2) [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests#visual-logger-integration) Visual Logger Integration ---------------------------------------------------------------------------------------------------------------------------------------- The assistant allows you to automatically begin and end a Vislog file for the duration of a test. (Enable `Automatically Record Vislog` in the components settings) This gives you a file you can open through the Visual Logger tool inside of the Unreal editor (`Tools` -> `Debug` -> `Visual Logger` ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252Ff3lMPmWtoITpwmG0LFIW%252Fimage.png%3Falt%3Dmedia%26token%3Df5b71d55-b5c4-4e2b-b213-3adbc42badbf&width=768&dpr=3&quality=100&sign=3efd243b&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FAMw6C2dRxhlTUXs7oX66%252Fimage.png%3Falt%3Dmedia%26token%3D7101e043-709a-4fb0-a90e-78a740f0005e&width=768&dpr=3&quality=100&sign=dfa112ae&sv=2) You can now see any `Visual Logger` shapes your test performed on the timeline. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252Ft0OgonGA8O8Ok7xPfC5M%252Fimage.png%3Falt%3Dmedia%26token%3D552e53a5-1aa0-4657-a57a-687e86a5090b&width=768&dpr=3&quality=100&sign=c0e2d6e3&sv=2) * I recommend using `OmniToolbox`'s `DrawAndLog(Shape)` functions to see the shapes both during the test and in the Visual Logger recording. [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests#performance-requirements) Performance requirements -------------------------------------------------------------------------------------------------------------------------------------- `Vanguard` allows you to mark a test as failed depending on if a large enough hitch/lag spike was detected or if a target game thread time was not achieved. There's a few notes to take around this system as there are big plans in the future to expand this: * You can find the settings to control this inside `Editor Preferences -> Plugins -> Vanguard Testing Settings`. * It's placed inside the editor preferences and not the project preferences because we want each computer to have its own settings. * As of `0.3`, the `Scalability Perf Test Settings` is not yet implemented. Use the settings above it. * This combined with the point above is aiming to achieve a test environment where you can have a computer with a bad CPU/GPU have appropriate settings for specific scalability settings. For example, a 5 year old cheap CPU might target 60 FPS on low scalability (index 0). Where as a modern expensive CPU might target 180 FPS on low scalability. There's no timeline for when this feature will be implemented or how much the API will change. The API might change in such a way where you list a CPU by its product name and give that specific CPU a target. Do note that Epic \*might\* be [working on something similar](https://youtu.be/aqNL8tdfIHI?si=4kkMIQKk5pcJLAxq) to this, but focusing specifically on performance. Depending on how this advances, this feature might get scrapped or focus only on CPU performance. [PreviousIntroduction](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/introduction) [NextTest Environment Guide](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide) Last updated 5 months ago * [Unreal Insights Integration](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests#unreal-insights-integration) * [Notes](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests#notes) * [Visual Logger Integration](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests#visual-logger-integration) * [Performance requirements](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests#performance-requirements) --- # Versions | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions.md) . [0.3](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3) [0.2](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2) [0.1](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.1) [PreviousSpreadsheet Object](https://varian.gitbook.io/varian-docs/omnitoolbox/tools/spreadsheet-object) [Next0.3](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3) --- # How does the system work? | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work.md) . * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work#design-structure) Design structure ------------------------------------------------------------------------------------------------------------------------------------------------------------- With how strict the performance requirements were for this plugin, I’ve had to design this inventory system slightly differently from other systems you might find either on the marketplace or Youtube tutorials. The biggest thing to keep in mind is that this system does NOT rely on widgets being valid or created to keep track of its data or run gameplay logic. This is to achieve five things: 1. This greatly speeds up widget construction since all the data they need (for example where an item is inside the container and so forth) is already prepped. 2. Allows you to remove widgets from memory and still have the necessary data to find out important things like looting an item and finding a free space for that item. 3. Since widgets have way fewer references, there is less work to be done to manage widgets getting garbage collected properly. 4. Designers are able to create new widgets and prototype much faster since all the data they need about containers and items is always available from the component. 5. You have complete control over when you want to construct these widgets, meaning you can reduce lag spikes when starting your game or even speed up the time it takes for your players to load a level or area. **ContainerSettings** is an array inside of **AC\_Inventory.h** and this is your inventory. Each container hosts a set of items and dictates its dimensions, compatibility settings and so forth. Some settings are hidden as they are not relevant to designers. When creating a widget for a container, the widget uses a **UniqueID** to find out what container it is representing. This is typically referred to as "Binding" a container with a widget. Items differentiate themselves from each other by using a **UniqueID** as items can have the same name, same data asset and so forth, they can even share the same position inside a container while in-editor. A component can not give items or containers the same **UniqueID** twice. This is essential for functions to work properly. The component is designed to live on individual actors, not the player controller. Though there is no reason why it can't live on the controller, but I won't be actively testing it that way. It is highly recommended to head over to the [AC\_Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory) page and giving a read. Understanding the main component that makes this system work is crucial to understanding the in's and out's of the system. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work#how-are-the-infinite-items-inside-of-items-achieved) How are the infinite items inside of items achieved? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Since UE does not support recursive structs and recursive structs are difficult to manage, containers use a coordinates system explaining what item they belong to. The array is simply containers and those containers have an array of items. The only thing the compoonent needs to know whether a container is owned by the component or owned by an item is by checking **FS\_ContainerSettings****.****BelongsToItem**. I recommend reading the code comment for the **FS\_ContainerSettings****.****BelongsToItem** property and then looking at **AC\_Inventory.h** -> **GetItemsContainers** for an example. [PreviousSuggested Plugins](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins) [NextHow does the networking work?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work) Last updated 1 year ago * [Design structure](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work#design-structure) * [How are the infinite items inside of items achieved?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work#how-are-the-infinite-items-inside-of-items-achieved) --- # Test Environment Guide | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide.md) . Some of my plugins get their own test environments - including `OmniToolbox`. This page is covering the standardization measures taken for all of these environments to make sure they are all consistent. This page can also be used to help inspire your own test environments and their rules. [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide#style-guide) Style guide ------------------------------------------------------------------------------------------------------------------ * Each test environment must be a game feature plugin and be named with either the full name of the plugin or project its testing or its shorthand term (Inventory Framework Plugin -> IFP), followed with `_TestingEnvironment` * Game feature plugins feature everything we need to limit asset referencing and helps ensure all test content is disabled or not cooked in final builds. * Some tests might want to make temporary changes to the asset manager, or add components to actors for debugging the games normal gameplay maps in the middle of a session. Game Feature Plugins natively support this. * With the `_TestingEnvironment` suffix, it's possible to check in your shipping builds if any game features with that suffix exist. If so, then something went wrong with packaging. * The environment can only have 1 map and it must be named with a `M_` prefix, then named after the test environment plugin. For example, `OmniToolbox`'s map is named `M_OmniToolbox_TestingEnvironment` * Making sure external maps are cooked for automation testing is painful and adding more test maps only forces automation tools to be updated. This rule makes sure that once the cook command has been setup, it doesn't have to be updated. * Every map must have a camera actor with a tag `DefaultCamera` * `UTestAssistantComponent` can automatically assign all tests with no observation point to use this actor as its observation point. * Every test must be located in loaction 0,0,0 (unless the test is testing something regarding elevation). The test map must have a flat plane that does not prevent actors at this location to fail to spawn, but still allow actors to walk without falling. This plane must also have a grid material with standard measurements. * With location set to 0 and the grid material makes it possible to identify if something in the scene is in the correct location through a screenshot or without opening a debugger. * I highly recommend the grid material from the Game Animation Sample. * Every test must have atleast one tag. * This is to make the `Automation RunTests` console command easier to use. * Every test goes into the `Testers` folder and then has its own folder. Even if the test is only 1 class. * All assets inside these test environments must only reference assets inside of themselves or engine assets. Plugins found in the engine are not allowed to be referenced. * Most engine assets used are the simple primitive shapes, such as the default engine cube. [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide#setting-up-the-project-launcher) Setting up the Project Launcher ---------------------------------------------------------------------------------------------------------------------------------------------------------- There's 2 ways to open the project launcher; 1. In the editor, go into `Tools` -> `Project Launcher` 2. Open file explorer and go to `YourEngineInstallation\Engine\Binaries\Win64` and open `UnrealFrontend.exe` I recommend the latter so the process is not tied to your editor, in case it crashes. It's also better to learn to not rely on the editor being open in case you ever build a home server or start using cloud services to automate your builds and tests. Unfortunately, Unreal's support for blueprint-based automation tests are very limiting. Tests can only be discovered by maps that have been opened throughout the session and it seems to struggle with swapping maps. Because of this, we have to create a launch profile for every test environment. ### [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide#creating-a-launch-profile) Creating a launch profile 1. Press the `Create Launch Profile` button 1. I tend to name my launch profiles for test environments like so: `Name of plugin being tested - Test tags (Full suite if all tests are being ran) - Configuration (DebugGame/Development`. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252FpfOaDy11BJScJnLEqJJc%252Fimage.png%3Falt%3Dmedia%26token%3D55f500a3-c06b-4ab2-89b6-1fcb220cc882&width=768&dpr=3&quality=100&sign=9354af86&sv=2) 2. Add this to the additional cook commands: * This will make sure the test environment map is packaged. 1. This step is optional, depending on how you want to use this profile. You can add commands to be executed, such as console commands to enable or disable certain features. * Open the test environment map * Enable spreadsheet generation * When using Unreal Automation in the editor, there's a flag (`GIsAutomationTesting`) that is set to true. But when you start tests through a console command, this flag is not set to true. `Vanguard` relies on this flag, but due to an engine bug, we have to use our own flag when running through the project launcher. * Execute all automation tests with the `OmniToolbox` tag, then once they are finished, close the session. * `Automation RunTests` can also take specific names if you only want to run specific tests. It also accepts multiple tags * You can remove `Quit` if you don't want the client to automatically shut down. * Remember, this is a console command. So if you want to rerun a test during runtime, you can either use the `Automation RunTests` console command or open the `Sessions Frontend` -> `Automation` and run the tests through there. My profiles usually end up looking something like this: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3180859593-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FHaVAFyKjs3d16ljfQ2o0%252Fuploads%252F76NEAvEExN7fOatV78bm%252Fimage.png%3Falt%3Dmedia%26token%3Df81eafaa-7a56-488b-945a-820786a7fe82&width=768&dpr=3&quality=100&sign=4ab6eb83&sv=2) * I added `stat fps` and `stat unitgraph` for this profile, since I usually monitor it. But ideally, you should not have to monitor these tests. When changing engine versions or reinstalling the engine, your profiles might get wiped. To backup your profiles, go to `EngineInstallation/Programs/UnrealFrontend/Profiles` and backup the files found in there. [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide#common-issues) Common issues ---------------------------------------------------------------------------------------------------------------------- * `Could not find file ProjectDirectory\Binaries\Win64\ProjectNameEditor.target` * To fix this, launch your project with your IDE and rebuild your project with the `Development` configuration assigned. * `DoesPackageExist called on PackageName that will always return false. Reason: Input '/SomeFile' is not a child of an existing mount point.` * There seem to be many solutions to this posted online. For me, this was solved by disabling and enabling the game feature plugin * `Error_FailedToDeleteStagingDirectory` * This usually occurs when another application is using a file inside the staging directory. This can happen when you have any of the spreadsheets or trace files open in a separate program. * If you use a cloud service, like OneDrive, pCloud or something else, those can sometimes lock files inside the staging folder. [PreviousFunctional Tests](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests) Last updated 5 months ago * [Style guide](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide#style-guide) * [Setting up the Project Launcher](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide#setting-up-the-project-launcher) * [Creating a launch profile](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide#creating-a-launch-profile) * [Common issues](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide#common-issues) Copy -Map=M_OmniToolbox_TestingEnvironment -package Copy -ExecCmds=\"open M_OmniToolbox_TestingEnvironment\" Copy -ExecCmds=\"OmniToolbox.Vanguard.GenerateSpreadsheets 1;\" Copy -ExecCmds=\"OmniToolbox.Vanguard.OverrideIsAutomationTesting 1;\" Copy -ExecCmds=\"Automation RunTests OmniToolbox;Quit\" --- # Introduction | OmniToolbox | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/introduction.md) . `Vanguard` is a module inside of `OmniToolbox` that is designed to extend Unreal's automation tooling. It is still slightly under development, but it is driving the test environment for my next big plugin. So it is seeing nearly daily use. [](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/introduction#why-the-separate-name) Why the separate name? ----------------------------------------------------------------------------------------------------------------------------- Since `Vanguard` is focused on testing and automation, it's NOT designed for runtime code, but we still need to expose everything to blueprints and keep it inside `OmniToolbox`, not a separate plugin. In an effort to help developers understand when they are working with Omni's systems and when they are working with Vanguard (something that isn't supposed to be packaged), it makes sense to give this system it's own unique name - `Vanguard`. [Previous0.1](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.1) [NextFunctional Tests](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests) Last updated 6 months ago --- # Tools | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools.md) . [Inventory Helper](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper) [Item Editor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor) [PreviousSorting Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items) [NextInventory Helper](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper) --- # Inventory Helper | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper.md) . [**Video documentation**](https://youtu.be/5CsMMlH9w2Y) * * * As of 5.4, there is an engine bug that is causing the widget that gives us a details panel to cause hundreds to thousands of invalidations of the widget. This is causing an annoying amount of lag. The tool still functions, but as this is an engine bug, there is little I can do to alleviate this. You will very likely be spending a good amount of time using this utility widget, so I suggest bookmarking it or having some way of quickly accessing it while you work. Working with the raw container struct and the array of items is extremely cumbersome and not very efficient use of time. It also does not provide any sort of feedback of items that might be overlapping or have gone outside the bounds of the container. This is why I've developed the Inventory Helper. This is a editor utility widget which attempts to mimick the final result you'd see in game and providing a place for you to create your own in-editor tools without going into C++. It is **HIGHLY** advised to rarely, if ever, work with the raw container settings array. The only exception is class defaults. Use the inventory helper whenever you can. Because of how many features this helper has, it becomes a lot to write down, so I've made a video (Not yet released) going over how to use the inventory helper and cover many of its features. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper#the-void-system) The void system What might confuse most is the "Void" widget and actor. Dragging and dropping an item onto the background will "pin" the item exactly where you dropped it. But the item data and its containers must be stored on an actor _somewhere_ in the currently loaded level. The void actor is where that data is stored. This also has the benefit of acting as a proxy for moving an item from one actor to another. You can select one actor, move an item into the void area, then select another actor and move the item into one of its containers. Limitations[](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper#limitations) * It is NOT recommended to edit the **Container Settings** through the **SelectedComponent** widget. The reason being is that the **OnPropertyChanged** event does not return which index has been modified. Meaning it is not possible to resolve which container or which item was modified, which means that every container widget and item widget must be updated. Only modify the container settings inside this widget if you really have to. * The normal highlight widget is not supported. An alternate method is used instead. * Item splitting is not supported. * Only basic item collision is supported, no combining or stacking. * The Item Void actor is not meant to be interacted with outside the inventory helper. If you wish to modify the Item Void regularily, consider modifying the InventoryHelper and have the tool modify it for you. * [**Generated item icons do not work**](https://trello.com/c/F1nJdIid/223-generated-item-icons-inside-the-item-library) . It is suggested to open your game, inspecting the item and saving the generated icon to disk, then setting it inside the data asset. [PreviousTools](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools) [NextItem Editor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor) Last updated 1 year ago --- # Item Editor | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor.md) . The item editor is a simple, but powerful tool that allows you to select any item the asset manager can detect and directly edit the asset without opening a new window. This tool is also meant to provide a simple interface for designers to create tools to help with their workflow. There are two tabs, the library and the editor. The library simply is where you can find all your assets and filter them. The second tab is your asset editor. At the bottom you'll find a toolbox. By default there aren't many tools in here, but it is meant for you to expand for your games needs. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor#tool-box) Tool box ------------------------------------------------------------------------------------------------------------------------- With the asset comes a icon editor, a shape editor and a socket manager. * The icon editor allows you to edit the inspect and generated item icon settings, and allowing you to see how the item will look like in game with whatever item widget you have selected. You might want to go into **WBP\_ItemWidgetPreview** and setting the default widget class to a class you commonly use. * The shape editor allows you to easily modify the **DisabledTiles** inside the **IT\_Shape** object, if it has been added to the item. * Tip: You can click and drag to change the state of multiple tiles without having to click over and over again. * The socket manager lets you manage the sockets on the item if it has the **IT\_SocketManager** object. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor#tips-and-tricks) Tips and tricks --------------------------------------------------------------------------------------------------------------------------------------- * You can resize the segments with the white bars. * If you click and drag the item asset icon into the viewport, you can place the item actor, just as if you were dragging the item actor from the content browser. * Right clicking the asset icon will open the item asset just as if you were to double click it in the content browser. * The top section of the library allows you to refresh the library, in case you create new assets while the editor is open. You can also scale the icons up with the slider. The final button will save the currently selected item asset. [PreviousInventory Helper](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper) [NextVersions](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions) Last updated 1 year ago * [Tool box](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor#tool-box) * [Tips and tricks](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor#tips-and-tricks) --- # Bugs | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs.md) . This list is only relevant to the latest version of the plugin. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs#known-bugs) Known Bugs * Instanced structs in some cases can't be modified inside of editor tools, such as the InventoryHelper because the dropdown to open it does not appear. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FwJ3Uo8pjJTBFOrj8YmQt%252Fimage.png%3Falt%3Dmedia%26token%3D7db875e2-304a-4d92-a395-635782713316&width=768&dpr=3&quality=100&sign=5faa2487&sv=2) * Some tools are causing heavy lag spikes. This is an engine bug, the `DetailsView` widget is invalidating itself hundreds of times when it's updated. This issue seems to have started with Unreal 5.4 and was not present in earlier engine versions. * The "Reset to Default Property Value" button for container settings is not resetting values to their proper defaults and it's always showing for all values, even if the value is set to its default. This is an engine bug. * The drag widgets sizing is much larger than it is supposed to be for a couple of frames. There is currently a 0.05 delay inside **WBP\_Drag** to resolve this. This is a band-aid fix, I'll try to resolve this fully in the future. * While inside a editor utility widget, the gameplay tags slate widget is not updating properly. The DetailsView widget is riddled with a few bugs as of at least 5.2 when it comes to custom slate struct widgets. The best you can do right now is open the gameplay tag to see what values are inside of it and adding/removing something to update it, then it'll show the values inside the tag correctly. * In 5.2 and beyond, saving an icon has a chance of crashing the editor. This is happening because Epic modified how this is handled into an async task, but left no delegate for me to bind. For now, a delay is being used instead of a delegate, but on slower computers, the async task might not be finished by the time the delay finishes, causing a crash. If you are crashing, go into **WBP\_InspectDebug** and click on B\_SaveIcon and find its OnPressed event. You'll find a delay and you'll want to increase it. * The inventory component might be falsely reporting it might be "corrupted" or a custom property list is not initialized correctly. This is happening because when a component is declared in C++ and then the ComponentClass is set to a blueprint, it starts loading everything connected to that blueprint. Some assets seem to be breaking something inside of UE's loading process and causing issues. I haven't noticed any patterns, but most of the issues seem to occur when a player character is referenced. Because of this, you really have to mind your hard references, or go through the process of removing the C++ version, which I do not recommend. You should be minding your hard references, especially when it comes to the inventory component. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs#common-problems) Common Problems These aren't bugs, but problems that can be misinterpreted as bugs. * The inspector debugger changes are being set but not being saved after closing the editor. This is because the engine seemingly refuses to label assets as dirty while a gameplay session is active and doesn't label them as dirty after closing the gameplay session. An asset that is dirty will have an asterisk (\*) indicating that you have changes that need to be saved, but since it refuses to label it as dirty, it means that you have to manually open the asset and pressing save, even though there is no star indicating that you have changes that need to be saved. This may be a engine bug or is intended, but it seems that there's nothing I can do about this. * The **WBP\_Highlight** widget and **WBP\_InventoryItem** widget padding doesn't take into account any scaling their parent widgets have to do (like borders). So if you are getting issues with items being dropped in a different tile or an item not lining up properly, there is most likely an issue with your UMG hierarchy/scaling. You might have this problem with scroll bars most of the time. An easy fix for that is to go into the ScrollBox, go into Scrollbar Padding, let's say the scroll bar is on the right side, go into the right side padding and minus the thickness of the bar. * **BP\_PreviewActor**'s automated camera distance is determined by all components which have collision enabled. This means if you have collision hitboxes or something similar on your actors, the camera will try to adjust to fit that in the camera view. Remember to use the tag “**DONOTPREVIEW**” on those collision components if the **BP\_PreviewActor** is copying them. * Your item is not showing up in the asset manager or your getting a "Ignoring PrimaryAssetType Items - Conflicts with SOMECLASSNAME - Asset: ITEMNAMEHERE" in your message log. This happens when there are two identical data assets. This will most likely happen when you have two completely blank data assets. * The highlight widget is going outside the boundaries of the container or is getting clipped. This happens if the sizing of the widget does not match the container dimensions. This is most common if the container is slotted into a canvas panel. If that is the case, you can check "Size To Content". For other widgets, you will have to manage the sizing of the container and in some cases, it's handled automatically. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FDVBejWcMTkUgoVOuZR18%252FInaccurateHighlightProblem1.png%3Falt%3Dmedia%26token%3D71db82d2-89d4-41a8-aa39-ab939471ee6f&width=768&dpr=3&quality=100&sign=6bb7739c&sv=2) In game issue ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252F95WEr4JTBmGQWyKyABrb%252FInaccurateHighlightProblem2.png%3Falt%3Dmedia%26token%3Dddd04ca3-0be7-440c-abfe-ef8286434e26&width=768&dpr=3&quality=100&sign=29d2a49e&sv=2) In editor issue * After adding or changing default values inside **FS\_InventoryItem**, the InventoryHelper will falsely report a value is no longer set to default and will reset it to the wrong value when pressing the reset button. This is happening because the struct inside the InventoryHelper did not get updated. You must go into **EUW\_InventoryHelper** and find **SelectedItem** and update its default settings. The same might happen to the context menu, so you must go to **WBP\_ContextMenu\_EditorOnly** and find **Item** and update its default settings. [PreviousF.A.Q](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q) Last updated 1 year ago * [Known Bugs](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs#known-bugs) * [Common Problems](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs#common-problems) --- # A_ItemActor | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a_itemactor.md) . This is your physical representation of the item. If you already have items/weapons of any sorts, you will want to reparent those classes to this. This is not supposed to run important logic as these can get destroyed and created by the user. (for example equipping and unequipping) In your data asset, you can access this class so whenever you drop the item out of the inventory or want to spawn it in some way, here is how you access the original pickup class. It’s very important when making your items that have a physical representation in the world and can be picked up that the component on that actor references the data asset that references this physical actor. Otherwise when you drop the item, it’ll spawn the wrong class. The setup for pickups goes like this: In your **ContainerSettings** index 0, you set **ContainerType** to **ThisActor** and item index 0 is the pickup data asset. There should be no other items in this items array. Containers that might be attached to the pickup are added after and they can have Inventory or Equipment selected, but never **CurrentItem**. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a_itemactor#custom-blueprint-children) Custom Blueprint Children -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The **BP\_ItemActor** is a optional parent in your hierarchy. It has some code that you will want to copy over to any parents that you have if you wish to make your own, primarily the BeginPlay, Equip and Unequip delegates, and Destroyed event. The C++ inventory compoonent will automatically get added to your actor, but the base C++ version should not be used. You want to click on the InventoryComponent in your components list and set ComponentClass to **BP\_AC\_Inventory** (Or your own child of the inventory component if you've made one) [PreviousClasses and Settings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings) [NextAC\_Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory) Last updated 1 year ago --- # F.A.Q | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q.md) . * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-can-the-system-be-used-for-a-more-traditional-inventory-system-where-all-items-are-1x1) Q: Can the system be used for a more traditional inventory system where all items are 1x1? A: Of course! Containers have styles, and the `Traditional` style converts all items into 1x1. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-will-stats-attributes-or-ability-systems-of-any-kind-be-added) Q: Will stats/attributes or ability systems of any kind be added? A: No. I believe most people should be using the Gameplay Ability System framework as it is becoming the industry standard or something similar (I personally suggest [**GAS Companion**](https://www.unrealengine.com/marketplace/en-US/product/gas-companion) from the marketplace). A lot of people also already have a stat/attribute or ability system in place and I do not want to step on their toes. The [tag system](https://inventoryframework.github.io/workinginthesystem/tagsystem/) does allow you to create basic stats and attributes for items, but I generally recommend people use GAS or a more fleshed out system designed around that. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-will-i-be-adding-any-art-meshes-or-animations-to-the-asset) Q: Will I be adding any art, meshes or animations to the asset? A: No, with the exception of some basic things like the Tile Icon and some other things, just enough so you don’t get any compile errors and can interact with the system before you implement your art. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-does-the-plugin-feature-an-interaction-system) Q: Does the plugin feature an interaction system? A: This plugin does not provide a fleshed-out interaction system for you, but an interface system is integrated in the demo's as that's the foundation of every interaction system I've seen. This is done so your project does not build a dependancy on my interaction system if you ever decide this plugin does not fit your project. The interaction system is designed to be replaced, as most people already have an interaction system already in place. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-does-the-plugin-work-with-commonui-and-enhanced-input) Q: Does the plugin work with CommonUI and Enhanced Input? A: Enhanced Input, of course! CommonUI, yes, but it's not native. CommonUI just reworks how input routing is handled and provides widgets for common UI cases. But due to not everyone liking CommonUI, I am not having IFP depend on CommonUI, so it is not implemented by default. This does not mean IFP does not support gamepad navigation. Please refer to the [documentation](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation) for more information * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-will-i-be-adding-x-feature-system) Q: Will I be adding X feature/system? A: Only if it’s a highly requested feature, only then will I either implement it into the base asset itself or advise you how to make it yourself. You can track what is being worked on and what will be worked on in the future by going to the [Trello board](https://trello.com/b/pE2DJRlb/inventory-framework-plugin) . [Previous1.0.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.0.0) [NextBugs](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs) Last updated 1 year ago * [Q: Can the system be used for a more traditional inventory system where all items are 1x1?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-can-the-system-be-used-for-a-more-traditional-inventory-system-where-all-items-are-1x1) * [Q: Will stats/attributes or ability systems of any kind be added?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-will-stats-attributes-or-ability-systems-of-any-kind-be-added) * [Q: Will I be adding any art, meshes or animations to the asset?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-will-i-be-adding-any-art-meshes-or-animations-to-the-asset) * [Q: Does the plugin feature an interaction system?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-does-the-plugin-feature-an-interaction-system) * [Q: Does the plugin work with CommonUI and Enhanced Input?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-does-the-plugin-work-with-commonui-and-enhanced-input) * [Q: Will I be adding X feature/system?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q#q-will-i-be-adding-x-feature-system) --- # Classes and Settings | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings.md) . [A\_ItemActor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a_itemactor) [AC\_Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory) [BP\_PreviewActor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor) [DA\_CoreItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem) [Traits and Components](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components) [W\_Attachment Parent](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_attachment-parent) [W\_Container](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_container) [W\_Drag](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_drag) [W\_Highlight](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_highlight) [W\_InventoryItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_inventoryitem) [W\_Tile](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_tile) [WBP\_ContextMenu](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_contextmenu) [WBP\_Tooltip](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_tooltip) [PreviousTest Environment](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/test-environment) [NextA\_ItemActor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a_itemactor) Last updated 1 year ago --- # How does the networking work? | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work.md) . * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#listeners) Listeners --------------------------------------------------------------------------------------------------------------------------------------------------- Certain inventory data can become quite large, especially with how many containers and items you allow in an inventory. To optimize, we try to simplify things. Players only receive data from components that they request data from and data from their own components, but also any update from components they are currently interacting with. The component keeps track of the players that are currently interacting with a component with the **Listeners** array, then whenever PlayerA moves, adds, removes or interacts with an item in some way, the component sends RPC calls to the other "listeners" so their widgets and data get updated. For functions that modifies a components data, such as moving an item or modifying an items stack count or modifying any other data, you must remember that clients only have authority over their own component, they do not have authority over other components and thus can't call functions on other components. This is simply how networking in Unreal Engine works. Because of this, most functions require you to call the function on the component the client has authority over. Even though the item you are trying to modify is not on that component. This is why, when you look at some of the source code, the functions are getting the component the item belongs to through its **UniqueID**.**ParentComponent** and modifying that component's data through the component the client has authority over. To simplify the code, any function that attempts to automate the replication for you stores its logic in a function with the same name but with a **Internal\_** prefix. For most functions that modify data in some way, only a single version of that function is available for you to call, and that function handles the replication for you. This is to simplify the amount of functions exposed as it can get very daunting to try and handle every replication scenario and making sure your calling the right function. If you wish to modify how the replication is handled, you can always go into the functions, modify them, or enable the server/client/internal functions to be BlueprintCallable (Example would be **AC\_Inventory** \-> **Internal\_AdjustContainerSize**). spinner Code example[](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#code-example) Copy //Increase the count of an item by @Count void IncreaseItemCount(FS_InventoryItem Item, int32 Count, int32& NewCount) { if(UKismetSystemLibrary::IsStandalone(this)) { //Single player, don't bother with any replication stuff InternalIncreaseItemCount(Item.UniqueID, Count, NewCount); return; } //Update server data S_IncreaseItemCount(Item.UniqueID, Count); //Predict the result if item is stackable. if(Item.Item->CanItemStack() == true) { NewCount = FMath::Clamp(Item.Count + Count, 1, Item.Item->MaxStack); } else { NewCount = Item.Count; } //Notify the player the item is currently busy C_AddItemToNetworkQueue(Item.UniqueID); } //Increase the item count on the server void S_IncreaseItemCount(FS_UniqueID ItemID, int32 Count) { int32 NewStackCount if(GetOwner()->GetRemoteRole() == ROLE_SimulatedProxy) //This is dedicated or listen server. Don't bother with client RPC { InternalIncreaseItemCount(ItemID, Count, NewStackCount); } else //Client is calling, update server, then call client RPC { InternalIncreaseItemCount(ItemID, Count, NewStackCount); C_IncreaseItemCount(ItemID, Count); } for(const auto& CurrentListener : ItemID.ParentComponent->Listeners) { //Update all clients that are currently listening to this component's replication calls. if(CurrentListener->GetOwner()->GetRemoteRole() == ROLE_AutonomousProxy && CurrentListener != this) { CurrentListener->C_IncreaseItemCount(ItemID, Count); } } } //Increase the item count for listening clients void C_IncreaseItemCount_Implementation(FS_UniqueID ItemID, int32 Count) { //Find the item we are processing bool ItemFound; FS_InventoryItem Item; ItemID.ParentComponent->GetItemByUniqueID(ItemID, ItemFound, Item); if(ItemFound) { int32 NewStackCount; InternalIncreaseItemCount(ItemID, Count, NewStackCount); //Item has been processed, remove from network queue C_RemoveItemFromNetworkQueue(Item.UniqueID); } } void UAC_Inventory::InternalIncreaseItemCount(FS_UniqueID ItemID, int32 Count, int32& NewCount) { //Start moodifying the item in here. //This was called on both client and server, so the same logic is ran for everyone. } ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#why-not-just-use-a-multicast-or-repnotify) Why not just use a multicast or RepNotify? Because of how large some RPC's can get, I did not find multicasts to be acceptable for most of the functions. A lot of the RPC's are just simply not relevant for most clients anyways, and managing relevancy is a lot more complicated than a simple array of actors. RepNotify's also can not be used because there is no way to ensure their order. When you label a RPC as "Reliable", Unreal will make sure all reliable RPC's get replicated in the order you called them. Variables will always get replicated, even with packet loss, so they are in a way "reliable", but not truly reliable. Variables will replicate whenever they get an opportunity to, and they have a lower priority than RPC's. RepNotify's also always re-sync the entire array even if one element is updated. So if you'd just update the item count for one item, the entire inventory would be re-replicated. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#requesting-inventory-data) Requesting inventory data ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- IFP does not automatically replicate any inventory data between clients other than their own inventory component. This means that actors in the level, like a chest, for clients will just contain the class defaults. For a client, they must call **C\_RequestServerDataFromOtherComponent** and they will then be added as a listener. Then eventually you will need to manually call **S\_RemoveListener**. An example can be found in **BP\_ItemActor** in the interaction events. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#unique-id) Unique ID --------------------------------------------------------------------------------------------------------------------------------------------------- The **UniqueID** is a simple method to quickly find containers or items, or ensuring containers or items are valid, and for linking some object to an item (Such as the [item components's](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components) ). This is covered in multiple sections in the documentation, but here are some things to consider for networking. * Clients and servers must stay in sync when it comes to UniqueID's. This leaves you with two options; 1. Pre-generate the **UniqueID**'s on the server, then pass them to the client and have your logic assign that **UniqueID** to the item. This is not advised as it can get bad for networking and it is generally cumbersome to program and manage it. 2. Use **GenerateUniqueIDWithSeed**. Now the only thing you need to ensure is that the client and server are using the same seed and they'll both generate the same **UniqueID**. * **UniqueID**'s [scale extremely](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions#network-optimizations) well with RPC's. It is advised to use **UniqueID**'s as often as possible. * There's no way to evaluate from a **UniqueID** if it was assigned to an item or container without going through all items and containers until you find a match. It is not recommended to add more information to this struct as it's meant to be small and simple, so that it gets replicated extremely quickly and cheaply. * **UniqueID**'s from components the client does not have information on will not work. For example, two players are interacting with a chest and Player-1 moves an item from their inventory to the chest, Player-2 will not have the information necessary to move the item on their side, since they do not have the information needed from Player-1's inventory component. Some functions simply need more information than the **UniqueID** can provide. [PreviousHow does the system work?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work) [NextStyle Guide](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide) Last updated 1 year ago * [Listeners](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#listeners) * [Why not just use a multicast or RepNotify?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#why-not-just-use-a-multicast-or-repnotify) * [Requesting inventory data](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#requesting-inventory-data) * [Unique ID](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#unique-id) --- # W_Attachment Parent | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_attachment-parent.md) . The parent widget for widgets that are used to hold the containers an item owns. For example, a gun has a sight and a magazine slot and you want to represent those slots with a container. That container needs to be hosted by _some_ widget. The base widget does not have any kind of layout so you are free to make any layout your project needs. Both the C++ parent and the blueprint child are abstract, so it won't appear in any drop-down menus. These are designed for the intention to have children made from them. [PreviousTraits and Components](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components) [NextW\_Container](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_container) Last updated 1 year ago --- # W_Highlight | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_highlight.md) . This widget is the primary method used for handling the highlight for moving items. An alternative method is used inside the InventoryHelper tool. [PreviousW\_Drag](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_drag) [NextW\_InventoryItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_inventoryitem) Last updated 1 year ago --- # AC_Inventory | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory.md) . This is where the vast majority of the logic is handled and starts. You have full control of when the component activates by calling the **StartComponent** function. When called, the component initializes the containers and the items inside or the pickup if the owning actor is a pickup. This does NOT prepare the widgets versions of the containers and the items. But this function must be called before you display any widgets or any data to the player. To create the widget version of a container and its items, call **BindContainerWithWidget** and hook in the container struct and the container widget. This should give you full control of when you want to construct the widget for a container. Some examples would be when the player opens their inventory, but you don’t want to load all the items' attachment widgets. You could then load the attachment widgets when the player inspects the item. For inventory systems that can get massive with a lot of items inside of it with attachment widgets associated with it, this massively improve performance and memory usage if used correctly. For pickups, I recommend calling **StartComponent** on either **BeginPlay** or when the player is close to the item and has line of sight of the item, as items that have a spawn chance associated with it need that spawn chance rolled. The item might also have items attached to it and be visible, such as a sight on a gun, which also might have a spawn chance and you don’t want that sight to be visible if it failed its spawn chance. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#settings) Settings ----------------------------------------------------------------------------------------------------------------------------------------- The first category is **Settings** and most of these are instance editable, so you’ll be spending most of your time with these settings for your item actors. **ContainerSettings** is where the majority of the work is done. I recommend going into **IFP\_CoreData.h** and find **FS\_ContainerSettings** and looking at the comments for everything as there are some variables that aren’t instance editable. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#optimizing-startcomponent) Optimizing StartComponent --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- When the component starts, a bunch of calculations, compatibility checks and validation occurs. This can be expensive if you initialize hundreds to thousands of items or containers. If you apply the `IFP.Optimization.SkipValidation` tag, these steps are mostly skipped. You are now telling the system that YOU have validated the position, compatibility and so forth. Without this tag, items can take anywhere from 1 microsecond, to 100 microseconds or more, depending on the quantity, size, shape and so forth. With this tag, items consistently take anywhere from 100 nanoseconds to 2 microseconds. * This tag is automatically applied to any save files, since it makes sense to assume that the containers you are trying to save have already been validated in some way. * It is recommended whenever loading a save from a previous version of your game to remove this tag. In this case, you'd want to add some version number to your save files and enabling the **Remove SkipValidation tags** parameter on **StartComponent** if the save files version number does not match the games current version. * Do keep in mind that this has no failsafes. If you apply this tag on an item and odd behavior occurs, you have either found a bug or the tag was applied when it shouldn't have been. * The `InventoryHelper` tool automatically applies this tag to items whenever possible. * The main performance benefits come from applying this tag to items. Very little performance gain happens when applying this to containers. This tag should only be applied to containers in save systems. `IFP` already handles this automatically. * In a few runs of a simple A-B test with 18 items; without this tag it would take on average 340 (total time for all items) microseconds to initialize quite complex items in a large grid container. With the tag, this number dropped to 8 microseconds. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#inventory-extension-components) Inventory Extension Components ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Any actor component on the inventory components owner implementing the **I\_InventoryExtension** interface will be treated as "inventory extension components". These components will receive two events; pre/post **InventoryComponentInitialized** This is especially useful for when **StartComponent** is called during **BeginPlay**, as the order of **BeginPlay**'s can be difficult to predict for actor components, making it difficult to bind to the appropriate delegates to inject any logic before or after **StartComponent** is called. With this interface, you do not have to worry about that. The example project's helper components utilize this feature and can be used as examples. Do note that this means that a component can receive these events \*before\* their own **BeginPlay** is triggered. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#color-settings) Color settings ----------------------------------------------------------------------------------------------------------------------------------------------------- Third category is **ColorSettings** and this is where most of the colors used by the system are dictated. This is set in here so all the widgets can fetch colors easily and so designers can extend any color settings (for example color blind settings) to the user settings. If you want to add any color settings, this place is the preferred place. Item rarity colors are handled in here. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#network-queue) Network Queue --------------------------------------------------------------------------------------------------------------------------------------------------- The component has an array called **NetworkQueue**, these are items that are waiting for a server RPC to finish. If you are writing your own networking code, it is up to you to call **C\_AddItemToNetworkQueue** and **C\_RemoveItemFromNetworkQueue**. This will automatically call **ItemAddedToNetworkQueue** or **ItemRemovedFromNetworkQueue**. If the item widget is available, it'll also call: **W\_InventoryItem** \-> **ParentItemAddedToNetworkQueue** / **ParentItemRemovedFromNetworkQueue** By default, the widgets will play a blinking animation when they are in the network queue. These events are where your designers hook in any logic that alerts the player the item is pending some networking event. This is most often seen as making the item's icon gray-scale or flashing the icon. You will want to implement some way of preventing players from interacting with items that are pending a network event, either by making the widget uninteractable or through code. You can check if an item is in the queue by using: **FL\_InventoryFramework.h** -> **IsItemInNetworkQueue** The Network Queue system is only relevant for clients, it's never used in single player or server scenarios. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#infinite-containers) Infinite containers --------------------------------------------------------------------------------------------------------------------------------------------------------------- Containers can be infinite in either the X or Y direction, the system tries to dynamically resize the container whenever an item is moved, added or removed from it. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#states) States ------------------------------------------------------------------------------------------------------------------------------------- The containers can be in one of three states during development. * The "raw" state is where **UniqueID**'s are not set and containers **BelongsToItem** directions are direct index directions and all object references are null. The component is designed to be in this state for when you call the **StartComponent** function. This is where all the data is "human readable", but most functions won't work. * The "Editor" state is where **Unique**'s have been initialized and **BelongsToItem** are set to the items and containers **UniqueID**'s and some object references might be valid. This state is meant for development and it might make some data not human-readable, and it'll mean most of your functions will work as if you are in a valid game session. Many tools depend on the component being in this state, such as the InventoryHelper. * Finally there's the "Initialized" state. This simply means the gameplay logic has called the **StartComponent** function and you are inside a gameplay session. The component should never be put into this state while you're outside of a game session. You can use **GetComponentState** to resolve what state it is in, and look inside that function to better understand what conditions must be met for each state. There is a function called **ConvertToRawState** which will prepare all containers for a gameplay session. Ideally, this function should not be called during a gameplay session as it's a waste of CPU time. All container data should already be prepped for gameplay. By default, the component calls this function on its **BeginPlay** if it detects the actor was not setup properly and spit out a print string. There is also another function called **ConvertFromRawStateToEditorState** which preps all data to be usable for editor tools. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#attached-spawned-items) Attached spawned items --------------------------------------------------------------------------------------------------------------------------------------------------------------------- An important aspect to remember is that whenever you have a item that has a spawned actor to represent it, such as a gun item inside the players equipment container, the inventory component on the spawned item should NOT be used. This will mostly happen with the equipment system when using Blueprint items. The reason for this is because spawned blueprints can be deleted and restored over and over, so they are unreliable to store any important data. It would also mean that the blueprint would always have to stay alive if you wanted to explore the items containers while the item isn't spawned (In this example, the gun item hasn't been equipped). An items containers always live on the component that own the item, (In this example, the gun's containers live on the character that is holding the gun). To retrieve the items true data, you need to retrieve the UniqueID of the owning item in some way. Generally this means storing the items UniqueID inside your spawned blueprint. **BP\_ItemActor** does this through an interface event called **PassUniqueID** and stores the data inside **RootItemData**. [PreviousA\_ItemActor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a_itemactor) [NextBP\_PreviewActor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor) Last updated 1 year ago * [Settings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#settings) * [Optimizing StartComponent](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#optimizing-startcomponent) * [Inventory Extension Components](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#inventory-extension-components) * [Color settings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#color-settings) * [Network Queue](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#network-queue) * [Infinite containers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#infinite-containers) * [States](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#states) * [Attached spawned items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#attached-spawned-items) --- # WBP_ContextMenu | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_contextmenu.md) . This widget is a good example of a widget that is completely separated from the system, but just uses the item data to interact with the inventory system. You can manage the rules for each button and when they should be visible. [PreviousW\_Tile](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_tile) [NextWBP\_Tooltip](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_tooltip) Last updated 1 year ago --- # W_Container | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_container.md) . This widget is responsible for holding both the tile widgets and item widgets and also acts as a proxy for the component to access any tile widgets or item widgets. The component (**AC\_Inventory**) should not rely on these widgets at all for any data for its functions, like I mentioned at the start of this documentation. Even though there are **ContainerSettings** inside of these, they are immediately overridden by the component when created. They are mainly used as a fallback default, used for previewing how the container will look or used to bind the widgets to a specific container in a component. I recommend looking at the comment on **GetContainerSettings**. To reduce the work for everyone when modifying containers, **W\_Container** has a function (**GetContainerSettings**) to get the **ContainerSettings** straight from the component it belongs to. This way you do not have to update the **ContainerSettings** for the widget every time the container is modified in any way and also allows designers to make children of **W\_Container** and still have access to the same data as other children. **TileSize** refers to how large you want your tile widgets to be. Ideally both dimensions should be the same to minimize stretching. If you decide to not have the dimensions 1:1, your item icons will have to accommodate for your new icon ratio. Yclamp refers to when you want the scroll bar to appear. This should be (Your Tile Y Size) \* (How many Y tiles you want until the scroll bar appears) So if I want mine to appear after 8 tiles while my container is 10 tiles tall and my tile Y size is 60, I would do 8\*60. **TileClass** and **ItemClass** are the default classes used to create the widgets for each instance of a container. It is recommended to try and keep these the same where ever your containers are to try and maintain consistent visuals through out your game. **DA\_CoreItem** has a override map, where if the current containers class is found in that map, it'll then use the item widget in that map instead of the assigned **ItemClass**. This could be useful for when a special item needs it own item widget. [PreviousW\_Attachment Parent](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_attachment-parent) [NextW\_Drag](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_drag) Last updated 1 year ago --- # Traits and Components | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components.md) . [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components#item-trait) Item Trait ------------------------------------------------------------------------------------------------------------------------------------------------------ **Item Traits** are pure data-only UObjects associated with item data assets. They allow you to add variables and functions to an item data asset without modifying the parent data asset. * **Retrieving Data**: Use `GetTraitsByTag` or `GetTraitsByClass` functions. The class version automatically casts to the correct blueprint, while the tag version requires manual casting. * **Use Cases**: Traits are ideal for adding variables or functions that don't fit into the item category, such as quest data, without needing to add that data to the item asset * **Function Limitations**: Traits can run functions but cannot use delays, timers, async tasks, or RPCs. Avoid writing data to trait variables as traits are shared among items with the same data asset. Unique trait instances are not created per item. * **Important Note**: Prefer soft references over hard references to avoid creating a complex web of hard references, which can lead to excessive loading of game assets. Item data bases are one of the biggest culprits to create a large web of hard references in almost every project. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components#item-component) Item Component -------------------------------------------------------------------------------------------------------------------------------------------------------------- **Item Components** are actor components that attach to the owner of the inventory component that drive gameplay logic related to items, such as equipping, consuming, or creating widgets. They can be assigned through any trait derived from `IT_ItemComponentTrait.h`. An ItemComponent relies on a trait, but a trait does not rely on an item component. It's a one-way dependency. * **Requirements**: Each Item Component needs an associated trait to function, but not all traits require an Item Component. * **Role**: Item Components act as proxies between the inventory system and other systems, allowing flexibility without affecting core inventory functionality. They operate like any other actor component, supporting delays, timers, RPCs, etc. * **Replication**: * **Server**: Exists only on the server. * **Client**: Exists only on the client. * **Both**: Created on the server and replicated to the client (typically used). * **Client Requests**: Clients can request the creation of an Item Component with a specific tag to associate with a function. Note that if creating a "Both" component, the function may not return immediately due to RPC delays. * **Paylod**: When a component is created, the client can pass in a payload that gets sent to the server. This struct is not used by the plugin, so it is safe to modify for your projects needs. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components#why-are-they-separated) Why are they separated? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1. Due to the type of logic that components could handle, such as casting, handling abilities, VFX and so forth, you would want it to be soft-referenced. But you can't have it be instanced (as in, able to edit its properties in the item asset) and be soft-referenced. So we allow the trait to be hard-referenced, and the component to be soft-referenced 2. Due to the simplicity of traits, they take up very little memory. Like what was talked about in point 1, we can't soft-reference traits. Actor components have a lot of irrelevant data that doesn't need to be loaded when the item asset is loaded. 3. In some cases, you want to run a function without loading the component class or creating an instance of the component. For example, the item ability trait has a function to "loosely" check if the item ability would even activate successfully after being created. In this case, you can save performance by checking this type of logic inside of the trait, rather than the component. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components#tips-and-tricks) Tips and tricks ---------------------------------------------------------------------------------------------------------------------------------------------------------------- By default, your traits will display their default class name in the drop down menu. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FVz7zWyzv1yIrtXzKSASq%252FBadObjectClassNames.png%3Falt%3Dmedia%26token%3D45a088a1-bf70-4171-b64e-ca38db91f3b8&width=768&dpr=3&quality=100&sign=96a56da9&sv=2) You can change the name they are given inside this drop down menu by following the next steps. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252Fhr7tJtBg3z0p29LtU4o4%252FGoodObjectClassNames.png%3Falt%3Dmedia%26token%3De95e825e-c946-4b39-8d3b-9373323939f5&width=768&dpr=3&quality=100&sign=b4867210&sv=2) \- By going into your Class Settings (1) you can change the class name (2). The drop down menu will now display whatever text you put in here. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FcrO1yrJsyjOMICiGYV9E%252FClassNameExample.png%3Falt%3Dmedia%26token%3Db3b15054-d431-4ed3-b456-2d391101626a&width=768&dpr=3&quality=100&sign=a89b1bea&sv=2) [PreviousDA\_CoreItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem) [NextW\_Attachment Parent](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_attachment-parent) Last updated 1 year ago * [Item Trait](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components#item-trait) * [Item Component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components#item-component) * [Why are they separated?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components#why-are-they-separated) * [Tips and tricks](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components#tips-and-tricks) --- # W_InventoryItem | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_inventoryitem.md) . These are the widget representations of your item. The **GetItemData** function automatically gets the direct struct version of the item it is representing from the component the item belongs to. This is so we don’t store the same item information in two places and whenever the item is updated you don’t need to update the widget as well. This should allow for more designer friendly architecture, as you could make two children of this widget, one for example the normal inventory item widget the player has in their inventory and then another for vendors and you could have them store items in a list format and things would still work together. **WBP\_InventoryItem** \-> **GenerateItemIcon** is where icon generation is handled. It’s pretty straight forward, copying the behavior to other children should be simple. It uses the [**BP\_PreviewActor**](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor) to achieve this. The data asset editor window has a **UI** category which has various settings to adjust or optimize the generated icons. [PreviousW\_Highlight](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_highlight) [NextW\_Tile](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_tile) Last updated 1 year ago --- # External Objects | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects.md) . Both the item struct and container struct has an array of **ExternalObjects**. There are helper functions for both adding and removing widgets from this array. What this array allows you to do is have other widgets receive the same update events from the **I\_ExternalObjects** interface that the item widget and container widget receive without using delegates, which listen to ALL events, where as these events are item and container specific. This can be used for hotbars, ammo counters, quest trackers and more where a specific item needs to be monitored. The example project uses the tooltip widget as an external object, where it is listening to the override settings getting updated so it can update in real time alongside the item widget. For your external widgets to receive these updates, you'll want to go to your class settings (1) and implement the **I\_ExternalObjects** interface (2). You'll then see a **IFP|External Objects** category with all the update events. Some of these are limited to just items or containers and some are sent to both. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252Fu5tNrN8tbKpLkF21eJWj%252FExternalWidgetInterfaceExample.png%3Falt%3Dmedia%26token%3Ddb09bc2e-7dde-4815-9e02-79492fc216ef&width=768&dpr=3&quality=100&sign=de4960e1&sv=2) Utilizing external objects can replace delegate events from the component, but there are still moments where delegates are better, for example a quest tracker keeping track of how much of a specific item data asset you have in your inventory. If any actor component on the inventory components owner implements this interface, they will also receive these events. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects#adding-custom-events) Adding custom events -------------------------------------------------------------------------------------------------------------------------------------------------------- The good news is, you don't even need to modify the **I\_ExternalObjects** interface class. Just simply make some interface, create your function and use the **GetObjectsForItemBroadcast** to get all the objects that want to listen to the event ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252Fb3hsCdXPFocTRQCY1ZSZ%252FExternalObjectsInterfaceExample1.png%3Falt%3Dmedia%26token%3D6fddc5aa-027e-40ae-8038-69164d323fdf&width=768&dpr=3&quality=100&sign=755b37f5&sv=2) [PreviousCrafting](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting) [NextFragments](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments) Last updated 5 months ago --- # W_Tile | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_tile.md) . There is very little logic or variables handled in this widget, as you have to keep in mind that this widget can end up with hundred copies or more, so it can get bad for memory allocation if overdone and if you don’t manage the variables those tiles are initializing. Creating these tiles is by far the most expensive process I’ve found in this component. It is essential they store as little data and perform as few functions as possible so we can optimize the construction cost. [PreviousW\_InventoryItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_inventoryitem) [NextWBP\_ContextMenu](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_contextmenu) Last updated 1 year ago --- # W_Drag | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_drag.md) . Visual representation of the item you are dragging, but also provides updates to **W\_Highlight** whenever you hover over a tile so the highlight widget knows where to move. All data you need when dragging and dropping an item should be stored in this widget. Both **W\_Drag** and **W\_Highlight** are updated inside of **WBP\_Tile** \-> **PerformDrop** and **BP\_AC\_Inventory** \-> **UpdateHighlight** The chain of events begin at **WBP\_InventoryItem** \-> **OnDragDetected**. An important note to consider is that Epic, in their ever-ending glorious top tier coding, have a built in interpolation for the drag and drop drag visual that you CAN NOT interact with without modifying the engine. But you have to go through a lot of trouble to replace the built-in drag and drop system for Unreal. So I leave the drag visual for the drag/drop operation as empty and allow **WBP\_Drag** to drive the visuals and most of the logic. The Drag/Drop operation is primarily just used to trigger the "On Drop" events. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_drag#rotation) Rotation ----------------------------------------------------------------------------------------------------------------------------------- This widget is the primary handler of certain settings when trying to move an item, such as the rotation. You can see an example on EventTick. If you wish to permanently change the system to no longer support 180 and 270 rotation, there is a code comment near the end of EventTick explaining how to enforce only 0 and 90 rotation. [PreviousW\_Container](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_container) [NextW\_Highlight](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w_highlight) Last updated 1 year ago --- # Systems | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems.md) . [Ability System Integration](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration) [Crafting](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting) [External Objects](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects) [Fragments](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments) [Item Query](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query) [Item Sockets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-sockets) [Loot Tables](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables) [Saving and loading](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading) [Tags and Tag Values](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values) [Templates for inventory and containers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers) [Tile Tags](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags) [UI Navigation](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation) [PreviousWBP\_Tooltip](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_tooltip) [NextAbility System Integration](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration) --- # BP_PreviewActor | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor.md) . This is an actor that “should” perfectly duplicate the appearance of any specific actor. It does this by getting all components of the **owning actor** and then duplicating it and reconstructing the hierarchy structure to match the hierarchy structure of the owning actor. This includes any attached actors. It currently supports **SceneComponent**, **PrimitiveSceneComponent**, **ChildActorComponent**, **StaticMeshComponent** and **SkeletalMeshComponent**. Notes regarding **ChildActorComponent**'s[](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#notes-regarding-childactorcomponents) 1. There is currently no way to disable **BeginPlay**, where as with Actor's you can with a ExposedOnSpawn boolean at the beginning of your BeginPlay logic. If you have any logic connected to your **BeginPlay**, you will need to find a way to disable it for the preview if there's any logic you don't want the preview to run. 2. If possible, avoid **ChildActorComponent**'s. They are extremely prone to bugs and odd behaviour, and they don't seem to play well with networking. It should be easy to add compatibility for more components, you’ll have to add them yourself, but the currently supported components should support the vast majority of components that have any sort of visual importance. You can optimize the construction or simply prevent this actor from duplicating a specific component by going into **ComponentTags** and adding “**DONOTPREVIEW**”. Though remember, since the actor is trying to reconstruct the hierarchy setup inside your original actor, any components attached to components that you labeled as “**DONOTPREVIEW**” will break. This actor will render out a render target for you to use however you wish and this is how the item icon generation is handled. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#camera-management) Camera management -------------------------------------------------------------------------------------------------------------------------------------------------------------- The **BP\_PreviewActor** will attempt to find the first component which has a socket called “PreviewCameraSocket” and attach the camera to that socket. If none is found, you’ll get an error message and the camera will stay attached to the PreviewActor’s root. Ideally, all your meshes should have this socket that you want to use this actor on. But to improve prototyping, I’ve added a few options to the item data asset: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FB5NlZbdOdVWNVHhXSZh8%252FPreviewActorAdjustments.png%3Falt%3Dmedia%26token%3Db2d92a44-b4ca-4f69-b96e-35d5b46cef97&width=768&dpr=3&quality=100&sign=d5c5fc52&sv=2) Once you're far enough into production or willing to keep all meshes up to date with the socket, you should remove these four settings. The actor supports auto-generated estimated camera distances, so you don’t have to debug every item to create a camera distance while in a prototyping phase. You can disable this by checking **Use Custom Arm Length**. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#skeletal-meshes) Skeletal Meshes ---------------------------------------------------------------------------------------------------------------------------------------------------------- The default animations for skeletal meshes is retrieved via an interface function **GetEquipmentData**. This allows you to assign what animations the previewed skeletal mesh will play. For now it is only looping one animation, but an animation blueprint can be added to this struct if you wish. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#optimizations) Optimizations ------------------------------------------------------------------------------------------------------------------------------------------------------ It is also up to you to manage the render targets and when they should be released from the GPU. You can see an example in **WBP\_InventoryItem** \-> **TryReleaseGeneratedIcon**. I’ve tried to automate the release and creation for the widgets that come with this plugin, but if you are making a new widget and are new to render scene components, you must call ReleaseRenderTarget2D for the texture. It is hard to create a perfectly automated system, so if you ever encounter an icon vanishing for an item, that means the render target was released improperly. During your prototyping phase, I recommend you just release and wipe the references when the player closes their inventory. Then when you’re in your optimization phase, you can try to optimize this. Do keep in mind that live captures can get very expensive, very quickly, since they are capturing a new image every frame. You can limit it by enabling **CaptureEveryFrame** and limiting the **TickInterval** inside of **SceneCaptureComponent2D**. I have these disabled by default, so if your actor isn’t animating, you need to enable CaptureEveryFrame, or if you're duplicating an item, you can go into its data asset and disable **UseStaticCapture**. Any actor being fed into the preview actor should avoid skeletal meshes as much as possible, as they are approximately 50 TIMES more expensive than most other components to clone. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FttC9mWcnqjymEmPfWwFG%252FProfiler_CloneSkeletalMesh.png%3Falt%3Dmedia%26token%3Db7759a5f-c996-4d62-9048-75bd31aff423&width=768&dpr=3&quality=100&sign=37d54add&sv=2) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#leader-pose) Leader Pose -------------------------------------------------------------------------------------------------------------------------------------------------- To bind two meshes together, you will have to setup their component tags in a specific way. The leader must contain some tag, in this example we'll use `PlayerMesh`. Skeletal Meshes that now want to assign that mesh as their leader pose will then want to add a tag containing the word: `LeaderPose: PlayerMesh`. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#common-issues) Common issues ------------------------------------------------------------------------------------------------------------------------------------------------------ Physics is typically the main culprit for the preview system breaking. If an item or components have physics on by default, they will instantly detach the moment they are initialized. Breaking the entire preview system. Physics will also cause issues with the equipment system, as that system relies on the attachment hierarchy being correct and detaching things due to physics will break it. [PreviousAC\_Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory) [NextDA\_CoreItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem) Last updated 1 year ago * [Camera management](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#camera-management) * [Skeletal Meshes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#skeletal-meshes) * [Optimizations](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#optimizations) * [Leader Pose](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#leader-pose) * [Common issues](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor#common-issues) --- # Item Sockets | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-sockets.md) . `ItemSockets` is a system that allows you to assign a socket to an item, similar to a static or skeletal mesh. This socket contains a name, a local position, a tag, and a rotation. Then using helper functions to get the tile index of that socket (**GetTileForSocket**), with another function allowing you to provide an offset to the sockets tile (**GetTileForSocketWithOffset**). The `ItemSocket` system can be enabled for items by opening the item asset and adding the `Socket Manager` trait. It is recommended to open the `ItemEditor` tool as that will provide you with a editor utility widget to visually assign your sockets. [PreviousItem Query](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query) [NextLoot Tables](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables) Last updated 1 year ago --- # Adding new items during runtime | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime.md) . * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime#single-player) Single player ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- Adding new items during runtime for single player is no problem and has no restrictions. Just call the function **AC\_Inventory** \-> **TryAddNewItem**. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime#multiplayer) Multiplayer ------------------------------------------------------------------------------------------------------------------------------------------------------------------- For multiplayer though, I've had to wrap this function with a very strict safe guard. Clients are under no circumstance allowed to call this function. If they do find a way, they will get kicked. There is simply no circumstance where the client should even have the slightest chance of gaining access to this function as they could potentially feed it bad data and grant themselves any item within your data base. Only the listen server or dedicated server is allowed to use this function. This means if you have a quest system or anything of the sort where the player is granted an item, you will have two options: 1. Pre-store the item in a component and call the **MoveItem** function, but this will permanently remove the item from the old component. Though you could always reset the data after the function is called. 2. The system which is calling **TryAddNewItem** is already owned by the server, and thus is allowed to call the function. [PreviousWorking in the system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system) [NextCreating custom functions](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions) Last updated 1 year ago * [Single player](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime#single-player) * [Multiplayer](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime#multiplayer) --- # Crafting | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting.md) . * * * The inventory system does come with an **optional** module for crafting. The crafting is a completely independent system and the inventory system has no reliance on it. Removing it will have no impact on the inventory system as this is a one-way relationship. The crafting system relies on the inventory, the inventory does not rely on the crafting system. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#classes) Classes ---------------------------------------------------------------------------------------------------------------------- Most classes can be created by right clicking the content browser and going into InventoryFrameworkPlugin -> Crafting, the entire crafting system revolves around two classes: * **AC\_Crafting**: The actor component that handles the crafting and replication. It also stores all recipe's a player owns. * **DA\_CoreCraftingRecipe**: The core crafting recipe data asset, these are your definitions for a recipe. This asset uses four different classes to create the recipe: * **Recipe Requirements**: All must return true for the recipe to be craftable. This is only asked on clients to enable the interaction of some widgets, but then asked again on the server when starting the craft. * **Display Requirement**: All must return true for the recipe to be visible when opening the crafting screen. * **Craft Events**: Code that is ran when a craft is successful, such as playing a sound effect or granting a crafting skill experience. * **Recipe Data**: This is ambiguous data meant mostly for blueprint programmers who don't want to modify or create custom children of the data asset. This allows you to add any data to a recipe, such as "Time to Craft" or a description to display in the UI. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#recipe-handling) Recipe handling -------------------------------------------------------------------------------------------------------------------------------------- Many games have recipes bound to things such as a "crafting bench", which is completely natural. The pain points come when you are deciding where you want to store recipe's and finding out what recipe's the player can and cannot craft. When a player unlocks a recipe, even if it is tied to a unique object such as a crafting bench or area, the player still holds onto the recipe. This is so it is much easier to evaluate how far the player is into the game and evaluating whether or not you should grant the player a recipe as the other object might not be loaded. In general, it is much simpler and efficient to just have the player hold a reference to all recipe's they have unlocked, then either blocking the craft or preventing it from being displayed (or both) through other means, such as applying a tag on the player when they are near a bench and the recipe requires that tag to be displayed. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#widgets) Widgets ---------------------------------------------------------------------------------------------------------------------- The plugin itself does NOT come with any widgets to use the system. Only the example project has widgets and that is the primary learning source for creating custom widgets and UI. These examples are not needed in your project, they are simply an example of how I would use the component and data asset. My setup begins inside of **WBP\_Inventory** \-> **Receive External Component**, which will lead to a subgraph called CraftingExample. Most of the system runs on delegates (For blueprint users, these are most often called Event Dispatchers, in C++ and C#, they are referred to as Delegates, so I will continue calling Event Dispatchers as Delegates), which can be simply handled since the player is responsible for holding all recipe's as mentioned above. I always name any functions related to a delegate with a **D** prefix and most often sort them into their own **Delegates** category. Since the system uses soft references for most recipe's, you can decide whether or not to instantly or async load your recipe's. I've chosen to async load them as that is better for performance. There are no rules on how to make your own widgets when using the crafting system, my system primarily uses the recipe requirements, display requirements, craft events and craft data to design how and when recipe's should be visualized. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#serialization) Serialization ---------------------------------------------------------------------------------------------------------------------------------- To save the players recipe's, the crafting component has an array of "Recipes" which you will want to save and then restore when loading a save. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#timed-crafts) Timed Crafts -------------------------------------------------------------------------------------------------------------------------------- When doing a timed craft, there's a few things to consider. First, you'll want to add the **RD\_TimeToCraft** recipe data to your recipe asset. Then when you are about to perform a craft, you will want to call **GetUniqueCraftHandle** and pass that into **S\_CraftRecipe** and save the value on the client. If you now wish to cancel the craft, for example if the player dies, then you can call **S\_CancelCraft** and pass in the handle. By default, clients do not get any kind of callback for when a craft is starting to handle something like a craft bar. Most games simply do not handle it this way. One way to handle this is to simply start the visual timer - for example a progress bar - instantly. Then retrieve the **RD\_TimeToCraft** data to get the timer length, but then add the players ping on top of that. Other methods would include simply allowing the progress bar to reach the end, but not actually vanish until the server says the craft is finished. The majority of players pings are low enough to not notice most methods. It's up to your code to handle how the visuals are displayed, what events cancel these crafts and for you to store and retrieve these handles. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#removing-the-crafting-system) Removing the crafting system ---------------------------------------------------------------------------------------------------------------------------------------------------------------- To remove the crafting system from the plugin, follow these steps: 1. Remove all references in your project from any of the crafting system. 2. Go into the plugin folder and into Content and delete the Crafting folder. 3. Go into the plugin folder and into Source and delete the IFP\_Crafting and IFP\_Crafting\_Editor folders. [PreviousAbility System Integration](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration) [NextExternal Objects](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects) Last updated 1 year ago * [Classes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#classes) * [Recipe handling](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#recipe-handling) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#widgets) * [Serialization](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#serialization) * [Timed Crafts](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#timed-crafts) * [Removing the crafting system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting#removing-the-crafting-system) --- # Saving and loading | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading.md) . The demo includes an extremely basic save and load system. I will not be implementing anything advanced, because if you ever decide to remove the inventory system from your project, you will have to extract the save and load system from this project. You should have some system which you can bring to all of your projects. Everything is saved in structs, so it should be compatible with your save system. It’s up to your save and load system to manage this, but if you need an example, the demo project has an example of a simple save and load system. But let’s be honest, Unreal Engine’s blueprint save system is not very good and lacks too many fundamental features. If you are going to make your own save and load system, I suggest using C++ as the current Blueprint functionality of Unreal's save and load system is really bad. There are a few C++ saving and loading system tutorials on Youtube which cover how to serialize nearly any data you want, all of which should be compatible with this system. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading#things-to-keep-in-mind) Things to keep in mind -------------------------------------------------------------------------------------------------------------------------------------------------------------- UniqueID's must reset whenever you try to save containers and items. The parent component object reference can not be saved. The component has a function called **GetContainersForSaveState** which provides you with a copy of the containers, but some data has been modified to be compatible with save files. I recommend looking inside this function to better understand what can not be stored in the save file. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading#multiplayer) Multiplayer ---------------------------------------------------------------------------------------------------------------------------------------- When a client connects, it's up to your save system to assign them the appropriate container settings. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading#equipment) Equipment ------------------------------------------------------------------------------------------------------------------------------------ When you load a save, you might want some equipment the player has to become visible. You have two options: 1. The component has a delegate for when it is started, from which you can assign a Trigger Filter inside of the Equipment Item Component. These should be instantaneous attachments and no animations should occur at the same time as they can cancel each other before any critical notifies occur. 2. Your save and load system has the ability to restore actors. From here you must ensure the restored actor gets the owning items UniqueID as a tag, unless you've also implemented a way to save the owning items UniqueID. [PreviousLoot Tables](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables) [NextTags and Tag Values](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values) Last updated 1 year ago * [Things to keep in mind](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading#things-to-keep-in-mind) * [Multiplayer](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading#multiplayer) * [Equipment](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading#equipment) --- # Creating new items | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items.md) . [**Video documentation**](https://youtu.be/GzxE6spwgCQ) * * * Creating new items is very simple. To start off, you'll need to go into the engine and find your content browser, right click and go to **Inventory Framework -> Inventory Item Asset** and a pop up will appear asking you what parent your data asset should derive from. You might have your own children or have removed some of the children that come with the asset, but whatever asset you choose must derive from **DA\_CoreItem** at some point in its hierarchy. I suggest creating a folder for your item and placing the data asset in there. To create a blueprint actor for your item, you will have to create an actor who at some point in its hierarchy is a child of **BP\_ItemActor**, then set that as your **ItemActor** The actor will automatically get the blueprint inventory component assigned to it. You will need to go into the component settings and change a few things. 1. Set **InventoryType** to "**Pickup**" 2. Add one index to **ContainerSettings** and set the **ContainerType** to "**ThisActor**". This will then hide most of the settings except for the items array. 3. Your items array should only have one index, which will be your newly created data asset. All settings can be left to their default. 4. (Optional) If your item has containers associated with it, the data asset should have an array of **DefaultContainers**. You will want to populate these with your containers and also assign the widget. This variable only exists for weapon and equippable item types. An example can be found in the example project with the gun and backpack item. To have the asset manager pick up your data asset, it can not be identical to another data asset. (This includes the base file, so if all your variables are set to default, the asset will not get picked up.) Typically you want to immediately give your item a name and a developer image for the InventoryHelper. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items#creating-new-c-children-of-da_coreitem) Creating new C++ children of DA\_CoreItem --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- You might want to create your own category of items, and since the engine does not allow you to mix C++ and blueprint children of data assets, you are unfortunately forced to create C++ children. I suggest installing the plugin directly to your project, and then creating new children inside the **Items** folder, which is found inside the plugins **Core** folder. [PreviousCreating custom widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets) [NextCompatibility Settings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings) Last updated 1 year ago --- # Tags and Tag Values | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values.md) . [**Gameplay tags**](https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScripting/Tags/) are extremely powerful and this system attempts to allow itself to expand to various needs using not just gameplay tags, but also a value associated with tags. There are two systems, a regular gameplay tag and the second being a tag value system. The component, containers and items can have both through the `Tag and TagValues` fragment. These tags can be updated, removed and added during runtime and are fully replicated. For example; The system does not by default have a durability system. But with the tag value system, you can add a tag Item.Stat.Durability and give it a value, and voila! You now have a durability system! (Of course you have to implement the background logic that would reduce or increase this value). The tag system is fairly simple, containers could use them as labels, for example Container.Type.Fridge and now any food items could have a tag value such as Item.Food.Quality which would slowly go down over time, but while in a container with a Container.Type.Fridge tag, it would decay much slower. There are helper functions for resolving the value of specific tags, finding items or containers with specific tags and more. * * * The add, remove and set functions have the option to "IgnoreNetworkQueue", if this is check to true, the item will not be added or removed from the network queue. This can be useful for moments where you are fine with server and client data not being in sync for a short moment. If you check this to true, you should NOT rely on that tag for any data validation. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values#tag-value-calculation) Tag Value calculation ------------------------------------------------------------------------------------------------------------------------------------------------------------- The Setter functions have a class parameter, which allows you to inject your own calculations before the final value is set. This is a prime location for clamping certain values, such a durability value. You might have a CurrentDurability tag value and a MaxDurability tag value, then whenever you modify CurrentDurability, you can pass in a tag value calculation class that will handle the clamping for you. [PreviousSaving and loading](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading) [NextTemplates for inventory and containers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers) Last updated 1 year ago --- # Sorting Items | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items.md) . There are a few ways to sort items, the primary way people will want to sort items is to also move items. Sorting an items array by itself is very simple, the item library editor tool shows an example of how to sort items alphabetically, but things become slighlty more complicated when you also want to move items inside of a container. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items#adding-sorting-options) Adding sorting options ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- * * * I've designed the function SortAndMoveItem to only require one change for any custom sorting you want to perform. 1. In Async\_InventoryFunctions.h there is an enum called **ESortingType**. You will want to add an option in there (I suggest adding your options to the end, the editor does not like it when you re-order or insert enum entries). 2. I suggest making your own IFP function library or making a IFP section in any of your existing function libraries. This is so if you ever update the plugin, any changes you make to the IFP function library won't be wiped. Then make a function that sorts an array of items. An example can be found in **FL\_InventoryFramework.h** -> SortItemStructsAlphabetically 3. Go into **AC\_Inventory** -> **Internal\_SortAndMoveItems** and you'll find a **SortType** switch statement. You'll want to add your new sort option enum in there and call the sort function you just made. [PreviousSetting up vendors](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors) [NextTools](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools) Last updated 1 year ago --- # Drag and drop | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/drag-and-drop.md) . * * * A lot of the information **PerformDrop** function needs to do its calculations and logic should be stored in **W\_Drag**. This is because setting and resetting all that information for all the tiles to optimize memory is simply just so much hassle compared to just putting your stuff in the drag widget, which is always just 1 of so it’s always optimized for memory and no hassle in managing it. * * * `IFP` takes a similar approach to the default drag and drop operation, but slightly modified to get around 2 hard coded practices in the engine: 1. Drag and drop visual has interpolation that can not be overriden. 2. Drag and Drop operations will only work while holding the drag button, then attempt to drop it the moment that key is released. Where as in some cases, like with gamepad navigation, you want to fully press and release the drag button, move the cursor to its destination, then press and release the button again to perform the drop operation. > It is not possible to completely abandon the engines drag and drop system, because the editor tools get a custom viewport that does not play well with the drag widget that comes with the plugin, so editor tools will not support the custom `IFP` solution. Inside the inventory components class defaults, there is a setting to toggle point 2 from the default behavior and to `IFP`'s custom implementation. If you want to change this behavior during runtime, you'd want to call **GetLocalInventoryComponent** \-> **UseDefaultDragBehavior** To achieve this, item widgets have a **StartItemDrag** and **StopItemDrag** functions, which will handle either the custom implementation or default. Then a custom set of delegates will be called over the default **OnDrop** and **OnDropCancelled**. The widget that is now responsible for handling navigation and input handling is the container widget. [PreviousCompatibility Settings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings) [NextEquipping and unequipping items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items) Last updated 1 year ago --- # Modifying Critical Files | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files.md) . Modifying critical files has its pro's and con's. Removing data is not recommended unless you are ready to fix any problems it might cause. Adding data should not be a problem, but there are some important things you must keep in mind. If your project is single-player only, adding data is a lot safer as there's no network bandwidth you need to manage and no replication you need to manage. This page covers what is safe, dangerous or optimizations you can perform to critical files this system relies on. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files#da_coreitem) DA\_CoreItem ------------------------------------------------------------------------------------------------------------------------------------------------------------- This file is very safe to modify and is intended to be modified. Though it is recommended to make children for each type of item you will have (Weapons, consumables, armor, etc). Though there are several functions you might have to update if you remove any variables or functions. Remember to use soft references as often as possible. In the base plugin there are a lot of children of this class as examples. All of which are safe to remove if some don't fit your project, though I recommend giving them a quick look-over to explore what differences were made to them. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files#fs_inventoryitem) FS\_InventoryItem ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- This struct will eat up most of your network bandwidth, so adding anything to it can be dangerous. Anything being removed from this struct might require a decent amount of reworking some functions. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files#fs_containersettings) FS\_ContainerSettings ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- It is not recommended to remove anything unless you are certain you won't need it. Most of the data, other than the tile map, is extremely small. This struct does contain some small features, like TileTag's, not all projects need this feature, so something like that can be removed. [PreviousEquipping and unequipping items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items) [NextOptimizations](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations) Last updated 1 year ago * [DA\_CoreItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files#da_coreitem) * [FS\_InventoryItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files#fs_inventoryitem) * [FS\_ContainerSettings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files#fs_containersettings) --- # Setting up vendors | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors.md) . * * * To have a inventory component be set to vendor, you will want to go into the component settings and set **InventoryType** to **Vendor**. Right now, the system only considers items that are children of **IDA\_Currency.h** as viable currencies that can be exchanged for a vendor item. Prices are calculated inside **FL\_InventoryFramework.h** -> **GetItemPrice**, and the function that evaluates if a player can afford an item is **AC\_Inventory.h** -> **CanAffordItem**. Remember, you can override an items price inside their override settings. The system by default has an array of currencies which players can use to buy items, but it does not by default provide a way of allowing the player to select which currency to use to buy or sell an item. It simply uses the first available currency it can find. It's up to you to implement that sort of logic. Most games tend to have vendors keep track of how much money the vendor has, then when you sell an item to the vendor they spend their own currency and grant it to the player. There are three vendors in the demo, each showing a different way of handling the vendor logic. If a logic error occurs, for example trying to give the player currency, but they do not have enough space in their inventory, you can call a delegate called **CurrencyAdditionFailed**. This is where you might want to implement some sort of mail system or queue system, as it feels pretty bad for players when they sell an item and they don't get their currency for it. The demo does not include any system for handling this problem. There are many ways of handling vendor behaviour. Nearly every game handles it slightly differently, which is why the framework does not try to handle any of this logic for you at a C++ level. Instead, there are three points in the system where you can inject your own custom logic and rules for handling vendor interactions. 1. The function **AC\_Inventory.h** -> **CanAffordItem** will call a interface function **I\_Inventory.h** -> **MeetsCurrencyCheck**, this simply asks the owner of the component what they value the item as. 2. You can make a child of **BP\_AC\_Inventory** and override the **CanAffordItem** function to implement your own custom logic. 3. The buyer and seller will receive a delegate on both the server and client either after or before the transaction, the notify is handled inside of **WBP\_Tile** \-> **PerformDrop** \-> MoveItem. The delegate is where you would perform any currency exchange, and since the vendor belongs to the server, it's allowed to call **TryAddNewItem** if you want to give either the vendor or player currency after the transaction. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors#using-the-crafting-system-as-a-vendor) Using the crafting system as a vendor ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- A fascinating trick some people have done is using the crafting system as a "vendor". Technically, this is more performant and could potentially be easier to manage. But the vendor will not have a grid of any sorts and will require you to setup most of the logic. This simply revolves around creating the illusion to the player that they are "buying" items, where in reality they are crafting them and using currency as the crafting ingredient. [PreviousOptimizations](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations) [NextSorting Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items) Last updated 1 year ago --- # Compatibility Settings | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings.md) . The **FCompatibilitySettingsFragmentBase** is a simple struct which contains one overridable function; **PassesCompatibilityCheck**. When you execute **CheckCompatibility**, it will check all fragments inside the container that are children of **FCompatibilitySettingsFragmentBase** and if any return false, the item is not considered compatible with the container. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252F6zKLyRQaQptERBrVLSYA%252Fimage.png%3Falt%3Dmedia%26token%3De9555af2-cba4-4404-9a9c-0918517c07e6&width=768&dpr=3&quality=100&sign=458a042f&sv=2) [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings#example) Example -------------------------------------------------------------------------------------------------------------------------------------------------- The plugin comes with a fragment called **FCompatibilitySettingsFragment** and **FTagQueryCompatibilitySettings**, which can both be used as examples as to how to make your own compatibility settings fragment. They can be found inside **CF\_CompatibilitySettings.h** file. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FoasSZ4JdnMAbgaCaMe5o%252Fimage.png%3Falt%3Dmedia%26token%3D6ab4e32c-8792-4863-842a-e2522f8d0157&width=768&dpr=3&quality=100&sign=d9ef4221&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252F6i7AXzeEMMDVwwaIGkjd%252Fimage.png%3Falt%3Dmedia%26token%3Df414964f-16ed-486b-a37a-8d1d3180ce93&width=768&dpr=3&quality=100&sign=871e4f16&sv=2) [PreviousCreating new items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items) [NextDrag and drop](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/drag-and-drop) Last updated 1 year ago --- # Tile Tags | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags.md) . The tile tag fragment is a simple way of adding tags to specific tiles inside of a container. In the base plugin, this system doesn't do much of anything, only being used to hide specific tiles to create custom shaped containers. Tags can be added and removed with the **AddTagsToTile** and **RemoveTagsFromTile** during runtime or edited in the details panel while in the editor. Adding and removing tags will call two delegates: 1. **AC\_Inventory** \-> TileTagsAdded 2. **AC\_Inventory** \-> TileTagsRemoved Binding to these two delegates will let your code respond to any tag updates. An example can be found in **WBP\_DemoTile** \-> **Construct** [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags#networking) Networking ----------------------------------------------------------------------------------------------------------------------------- Even though the `TileTag` system is automatically replicated and can be modified during runtime, it is not recommended to overuse it for multiplayer games. This system can start eating up a lot of bandwidth very quickly, but this of course depends on the scope of your game. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags#use-case) Use case ------------------------------------------------------------------------------------------------------------------------- Like mentioned above, this is primarily used to create custom shaped containers by hiding specific tiles. But this has more use cases that some people have used it for: 1. Locking tiles and unlocking them based on some in game reward or event. 2. Empowering items that are in "empowered" tiles. 3. Items durability slowly improving while in a specific tile. Some have even used the size of an item as a trade-off. Larger items would take more space, leaving the player with less space to carry other items, but the larger items could then occupy more of these beneficial tiles and gain these positive perks. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags#optimizations) Optimizations ----------------------------------------------------------------------------------------------------------------------------------- If your container is large enough, you might want to enable **OptimizeForGameThread**. This will fill the array so it is 1:1 with the tile map, allowing you to instantly retrieve a tiles tags. Leaving this disabled means that the entire array has to be searched until the appropriate tags for the tile can be found. [PreviousTemplates for inventory and containers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers) [NextUI Navigation](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation) Last updated 1 year ago * [Networking](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags#networking) * [Use case](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags#use-case) * [Optimizations](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags#optimizations) --- # Fragments | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments.md) . Fragments are instance editable structs, which can be dynamically added, removed and modified on containers and items. This allows you to remove data from items and containers that wouldn't need said data in the base struct, giving you a chance of optimizing the memory footprint of your game and giving you a platform to add any data you want to both containers and items. This data has native serialization support, so it supports all save systems. Unfortunately, instanced structs can only be made through C++ * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#writing-fragment-code) Writing fragment code --------------------------------------------------------------------------------------------------------------------------------------------------- The plugin has several examples of handling fragment code. The biggest highlights are the template functions provided by the **FL\_IFP\_FragmentHelpers** library. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FjTuexbcHSIBdKsOpX9lw%252Fimage.png%3Falt%3Dmedia%26token%3D0a9b2252-c295-4829-ac4c-1195abe9eb73&width=768&dpr=3&quality=100&sign=a560e08&sv=2) For simple examples, I suggest looking at **Internal\_AddTagToItem** and **StartComponent** or the Add/Remove/Override functions inside the fragment manager. The majority of the time, you are just using the **FindFragment** template function to get a pointer to a fragment to modify it. Depending on how frequently the fragment is used and how advanced you want to get, you might want to create custom functions for modifying the fragment. The tag fragment being the prime example of this. If you don't want to do that or don't need custom functions, you can use the generic **OverrideFragment** functions ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252Fqlcpo4OgEScICAOS48hc%252Fimage.png%3Falt%3Dmedia%26token%3D6404501c-687f-408a-9419-3a63251a7c89&width=768&dpr=3&quality=100&sign=c427a67f&sv=2) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#inheritance) Inheritance ------------------------------------------------------------------------------------------------------------------------------- Fragments follow a specific inheritance setup to allow both containers and items to share certain fragments to reduce duplicate fragments that achieve the same thing. Both the container and item use `FCoreFragment`, but you should most of the time assume the struct is `FContainerFragment` or `FItemFragment`, depending on which struct you are working with. The reason why they use `FCoreFragment` is to allow both to use fragments that apply to both structs, such as the tag fragment. > In a future update, I will be trying to customize the dropdown menu to exclude fragments based on certain settings. For example, excluding the Random Item Count fragment from the dropdown if the item doesn't support stacking. That customization plans on using the virtual functions found on `FCoreFragment` to handle that. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#fragment-manager) Fragment Manager ----------------------------------------------------------------------------------------------------------------------------------------- Due to instanced structs being so young in the engine, I did not feel comfortable putting all the logic around it in the main inventory component. That's why the **AC\_FragmentManager** was made, who will handle everything related to fragments. The **AC\_FragmentManager** is automatically added to the actor for you if it's missing. But if you want to subclass the fragment manager, you can manually add the component to your actor and it'll be used. Alternatively, you can assign a fragment manager class inside the inventory component class defaults. The inventory component has a **GetFragmentManager** function, which hosts all non-static functions related to fragments. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#structure-and-naming-convention) Structure and naming convention ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- Since fragments are only accessible to C++, this is my workflow for enabling as much C++ and Blueprint support: 1. Parent your fragment to `FCoreFragment` if you want it to be shared between both containers and items. Otherwise, you specify which parent you want. 2. Every time you make a fragment, you make a new class and put a function library inside of it to give helper functions to Blueprint programmers. This class's prefix should be `IF_` (Item fragment) or `CF_` (Container Fragment). If it's a global fragment, like the tag fragment, it's just `F_` 3. Always create getter functions. If you are working in single player, I'd recommend making setter functions to simplify your work flow. 4. I will not be supporting multiple instances of the same fragment within the same array. Rather, you should have a fragment contain an array of whatever data you want to have multiple copies of. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#key-functions-to-override) Key functions to override ----------------------------------------------------------------------------------------------------------------------------------------------------------- * **IsCompatibleWithContainer** \- Determines if the fragment is compatible with the container it's being placed in. * **IsCompatibleWithItem** \- Determines if the fragment is compatible with the item it's being placed in. * **SupportsItemAsset** \- Is the fragment allowed in the item asset? Keep in mind, all code utilizing this fragment should not assume the fragment can be in either the item struct or item asset and should not have its data modified while in the item asset. * **ShouldRemoveFragment** \- Whenever a fragment is modified, this function will check if the fragment should be removed. For example, if the fragment has no data inside of it or is no longer being used. * **MergeWithFragment** \- Handles how two fragments are merged. * **GetNetworkingMethod** \- How should the fragment be replicated? * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#networking) Networking ----------------------------------------------------------------------------------------------------------------------------- Fragments use the same networking method as the rest of the inventory. They do not use traditional replication, but rather has RPC's forward all modifications to relevant clients. The fragment manager has six functions for adding, removing and overriding fragments for both containers and items. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#fragments-or-data-only-traits) Fragments or data-only traits ------------------------------------------------------------------------------------------------------------------------------------------------------------------- Fragments are pure data structs that can be added to the container, item struct and/or item asset, where as traits are data-objects limited to just the item asset. The main difference is the simplicity of creating traits and working with them. Fragments are more complicated and Blueprint support is limited, where as traits have full blueprint support and are simpler to work with. Traits main limitation is not changing their variables during runtime, since every item sharing one item asset will have that change reflected for all of them. But that also means that their memory usage is highly efficient. Remember, a unique trait instance is not created per item struct, it's created per item asset. Meanwhile fragments are created per item struct, allowing them to be changed during runtime. (This is assuming the fragment in question is not a fragment in the ItemAssetFragments array, as that array also shares the same limitation of not being mutable during runtime but also being memory efficient.) I generally use traits for everything that are only related to the item asset and is static data that does not change during runtime. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#performance) Performance ------------------------------------------------------------------------------------------------------------------------------- Constructing a fragment is virtually free. So it just comes down to what you do with the fragment that can cause performance issues, for example; hard referencing assets. [PreviousExternal Objects](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects) [NextItem Query](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query) Last updated 8 months ago * [Writing fragment code](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#writing-fragment-code) * [Inheritance](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#inheritance) * [Fragment Manager](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#fragment-manager) * [Structure and naming convention](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#structure-and-naming-convention) * [Key functions to override](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#key-functions-to-override) * [Networking](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#networking) * [Fragments or data-only traits](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#fragments-or-data-only-traits) * [Performance](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments#performance) --- # WBP_Tooltip | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_tooltip.md) . The tooltip widget is an example of [External Objects](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects) . It automatically updates when items receive events, similar to MVVM without using MVVM. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_tooltip#debug-mode) Debug mode -------------------------------------------------------------------------------------------------------------------------------------------- The tooltip can have its debug mode enabled or disabled through the `IFP.Debug.Tooltip` console command [PreviousWBP\_ContextMenu](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp_contextmenu) [NextSystems](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems) Last updated 5 months ago --- # Working in the system | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system.md) . [Adding new items during runtime](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime) [Creating custom functions](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions) [Creating custom widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets) [Creating new items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items) [Compatibility Settings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings) [Drag and drop](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/drag-and-drop) [Equipping and unequipping items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items) [Modifying Critical Files](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files) [Optimizations](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations) [Setting up vendors](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors) [Sorting Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items) [PreviousUI Navigation](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation) [NextAdding new items during runtime](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime) --- # Templates for inventory and containers | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers.md) . IFP features two different types of templates; 1. **Inventory template** - This is a data asset that simply hosts an array of `ContainerSettings`. A inventory component can assign a template data asset to use instead of its own `ContainerSettings` array 1. This is soft referenced by the inventory component. To async load it, you can call **LoadItemAssets** 2. **Container template** - This is a fragment that can be assigned to a container and it will point to a data asset which will be used instead of its own settings. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers#when-to-use) When to use ------------------------------------------------------------------------------------------------------------------------------------------------------------ The primary use case of this system is for teams, or large number of actors who share similar inventories. For example, the player pawn is a critical class in nearly every project, so many team members might be fighting for write-access. By making the inventory component use a separate data asset as a template, the designer who's working on the inventory does not need to fight for write-access on the player pawn. This can also be used in combination with loot tables, for example creating a template for AI, and the templates containers use a loot table to determine what items should populate that template. For example, if the AI is a wolf, then populate its inventory with meat. If the AI is an orc, populate its inventory with weaponry. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers#serialization) Serialization ---------------------------------------------------------------------------------------------------------------------------------------------------------------- To prevent templates from replacing any containers you've saved, **StartComponent** will automatically reasign the **InventoryTemplate** variable to null. The **InventoryTemplate** variable has the `SaveGame` metaproperty assigned, so certain serialization solutions will automatically remember to reasign it to null. But if you aren't using a serialization solution that utilizes that metaproperty flag, you will want to manually remove the inventory template when loading a save \*_**before**_\* calling **StartComponent** [PreviousTags and Tag Values](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values) [NextTile Tags](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags) Last updated 9 months ago * [When to use](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers#when-to-use) * [Serialization](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers#serialization) --- # Item Query | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query.md) . The `ItemQuery` system is a separate module (Just like how the crafting system is a separate module) that includes a system that allows for quickly filtering and querying a specific set of items while supporting multithreading. These queries are very simple; They listen to specific events and if they pass the filtering function, they are added to an array, which can be reused extremely efficiently. To enable item querying, add the **AC\_ItemQueryManager** component to your actor. To add a `ItemQuery` to the manager, either add one to the **ItemQueries** array inside the component... ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FRjXGszfprSEZwKDL4JEW%252Fimage.png%3Falt%3Dmedia%26token%3D329a90e4-a976-4e11-9f80-143bf2764dea&width=768&dpr=3&quality=100&sign=13faae59&sv=2) .. or call **ConstructObjectFromClass** (We use this function so any `ExposeOnSpawn` parameters can be set) or use **NewObject<>()** if you're in C++, and then call **AC\_ItemQueryManager** \-> **RegisterItemQuery** To then get the items from the query, you can either call **AC\_ItemQueryManager** \-> **GetItemsFromQueryByClass**/**GetItemsFromQueryByIdentifier** or call **GetItemsFromQuery** on the item query instance you just created. The `ItemQuery` is now responsible for listening to any events relevant to it. For example, if you wanted to filter out all items with a specific tag, you would listen to the **ItemTagAdded**/**ItemTagRemoved** delegate. If an item had the tag added, you'd register the item. If the item had the tag removed, you're unregister the item. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252F72wgNvWuScECO6rDlg6a%252Fimage.png%3Falt%3Dmedia%26token%3D785f569c-273c-44d8-ab65-030f20bf71f6&width=768&dpr=3&quality=100&sign=ddfc266f&sv=2) Listen to the TagAdded and TagRemoved events ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FpBahiKkAclWFhoM5zVrY%252Fimage.png%3Falt%3Dmedia%26token%3De21c3f56-9386-4278-b3f1-70a18c030b95&width=768&dpr=3&quality=100&sign=4eb925ac&sv=2) If an item suddenly has the desired tags, register it. If the desired tags got removed, unregister the item. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FzAWM3FNxNKT1g0s5VaJV%252Fimage.png%3Falt%3Dmedia%26token%3D33709a6f-d256-4e4a-a992-3e5c2a25c463&width=768&dpr=3&quality=100&sign=baf12e6d&sv=2) DoesItemPassFilter is called whenever you try to register an item. It must pass this filter to get added. By default, all queries will automatically listen to 4 delegates: 1. ComponentStarted - It will try to register all items. 2. ComponentStopped - All items will now be removed from the query. 3. ItemAdded - It will try to register a newly added item 4. ItemRemoved - It will remove the item from the query. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query#creating-a-query-class) Creating a query class ------------------------------------------------------------------------------------------------------------------------------------------------------ To create a `ItemQuery`: 1. Right click the content browser and select InventoryFramework -> Other -> ItemQuery 2. Override the **QueryRegistered** function and bind the relevent delegates your query will use. Then call **RegisterItem** and **UnregisterItem** when needed. 3. Override the **DoesItemPassFilter** to dictate what items will ultimately get registered with the query. The example project includes 3 examples. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query#performance) Performance -------------------------------------------------------------------------------------------------------------------------------- In a test of over 300 items, registering a query that checked for a tag on the item took on average 500 microseconds, which is only 1/32 of a 60 FPS frame budget. Getting those items from the query then took on average 100 microseconds. * For maximum performance, it's recommended to remove the `BlueprintNativeEvent` from the **DoesItemPassFilter** function and only use C++ item queries. As talked about in the `Optimizations` page, removing Blueprint support can improve performance by about 16 times. * The main area that C++ dominates Blueprints are heavy for-loops. Running a similar hard-coded query through blueprint code took a whopping **34.7 milliseconds**. These queries provide a simple interface for blueprint programmers to leverage the speed of C++ while staying in Blueprints by just overriding one function. * The only downside for queries in regards to performance is that they take up memory, but it shouldn't be that much that you'd notice. * Queries can be multithreaded. This can be extremely powerful in the right scenarios. For example, spawning the equipment can be expensive. This is why the manager component will try to multithread its default queries while that is happening, greatly improving CPU utilization. * Do keep in mind that sending a task to a different thread does have a small cost. I advise you to use Unreal Insights to evaluate whether it is worth for your inventory to bother with multithreading or not > Keep in mind, Blueprint debugger does not work when blueprint code is NOT being executed on the game thread. So blueprint breakpoints won't work in the multithreading scenario * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query#storing-extra-information) Storing extra information ------------------------------------------------------------------------------------------------------------------------------------------------------------ Queries do not just have to store a list of items. Since queries are living objects, you can store whatever information you want. The example project includes a query that keeps track of specific item asset and how many of that item asset there are. [PreviousFragments](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments) [NextItem Sockets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-sockets) Last updated 1 year ago * [Creating a query class](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query#creating-a-query-class) * [Performance](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query#performance) * [Storing extra information](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query#storing-extra-information) --- # Creating custom functions | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions.md) . Once you’re comfortable enough in the system to make your own functions and/or change the current functions, here are some things to keep in mind. You should always assume an item does not have a widget version of itself. If you need access to the widget of an item, you can use **GetWidgetForItem**. Remember to check if the widget is valid. Widgets also can’t be transported through a network, so if multiplayer is important to you, your server functions can’t rely on data from widgets. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions#best-practices) Best practices ------------------------------------------------------------------------------------------------------------------------------------------------------------------- * Do not rely on widgets being valid. Your code should as often as possible rely on data from the inventory component, rather than relying on using the widgets as a proxy. * In most contexts, you should assume the data asset is loaded and just fetch the `ItemAsset` variable and assume it has been set. If it isn't, you are then trying to work with an inventory component that hasn't loaded all the items inside of it. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions#finding-items) Finding Items ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Finding an item is a very common scenario when you start making your own functions. The container's **TileMap** combined with an item's **UniqueID** is the most reliable way of finding items. The component includes a function to get an item at item at a specific index of a container called **GetItemAtSpecificIndex**. * The **UniqueID** is the most reliable method of finding a very specific item, container or item component, other than a direct reference to the item, container or item component, but even then a direct reference might get outdated if the player moves the item or modifies it in some way. The **UniqueID** is only updated for containers and items if they are moved to a new component. You can update a outdated item struct by calling **UpdateItemStruct** * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions#network-optimizations) Network optimizations --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- It is recommended, where ever possible, to use the item or container **UniqueID** instead of the struct in your RPC calls, and then have your server use the **UniqueID** to figure out which struct to use. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FNr8SiImYsbRwdICCTWdh%252Fnetworkoptimization.png%3Falt%3Dmedia%26token%3D7a61041c-3b62-4350-9fc6-798475bd58c3&width=768&dpr=3&quality=100&sign=2ea9ab72&sv=2) Here you can see 2 sets of RPC calls. One is **ReduceItemCount** (indicated in red), which is passing the item struct to the server and then to the client. The other is **IncreaseItemCount** (indicated in blue), which is passing the **UniqueID** to the server and the server is then using that **UniqueID** to resolve what item we are trying to modify. Switching to using the **UniqueID** method reduced the RPC size from around 75 bytes down to 13. ||| The only downside is that it is not possible to verify if the client has illegally modified it's data, and it's very difficult to verify that the data inside the item/container are synced. It is up to you whether that is a big enough problem to do this. Some anti-cheat methods already do a very good job at preventing clients from modifying the games data with external tools. If you need to validate the data, you can have the server function still accept the full item/container struct, validate the data, then only pass the **UniqueID** to the client. We covered that [UniqueID's scale](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work#unique-id) extremely well on another page, but to give you an idea of how well it scales, here's an example ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FdQy72RNYUjSmqga6yohZ%252FInventoryItemVSuniqueID.png%3Falt%3Dmedia%26token%3Db5b38f97-723e-44a1-9f08-61e0e8590ffa&width=768&dpr=3&quality=100&sign=2ece6feb&sv=2) These are two functions using an array with 5 entries of **FS\_UniqueID**'s (Blue) and an array with 5 entries of **FS\_InventoryItem** (Red) [PreviousAdding new items during runtime](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime) [NextCreating custom widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets) Last updated 1 year ago * [Best practices](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions#best-practices) * [Finding Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions#finding-items) * [Network optimizations](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions#network-optimizations) --- # Creating custom widgets | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets.md) . * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets#containers-tiles-and-items) Containers, Tiles and Items ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ These three widgets are the ones you'll most likely end up working with the most. To improve the hierarchy, I've tried to not add any components that aren't necessary. Those that are essential for the widgets to function, I've added Getter functions that request the essential widget. This way you're design hierarchy can be in whatever design you want and still use the parent widgets. But this does mean you need to override those functions and passs the widget through as a variable. All three are abstract, so you must either use the widgets in the demo folder or make your own children. Technically, these requirements can be ignored, depending on what features you need and don't need, but you might get some errors. For example; size boxes aren't really required as you can set the sizing on the image, but it requires a bit more work to setup correctly. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets#containers) Containers * Border is needed for scrolling support and sizing (**GetBorder**) * ContainerOverlay holds the item widgets (**GetOverlay**) * Grid panel holds the tiles (**GetGridPanel**) * (Not mandatory, but is recommended) - Scroll box is needed for scrolling (**GetScrollBox**) ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets#tiles) Tiles * There are no requirements in the tiles hierarchy. You don't even need an image! To control the sizing of the widget, a function called **SetWidgetSize** should be overriden and handle the sizing logic from there. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets#inventory-item) Inventory Item * size box to control the size (**GetSizeBox**) * Image for the item icon (**GetImage**) * (Not mandatory, but is recommended) - Loading Throbber for indicating the item is loading (**GetLoadingThrobber**) This widget is updated through the **I\_ExternalObjects** interface. You can see an example of how these updates are used inside **WBP\_DemoInventoryItem**. The hierarchy inside your custom widget can be structured in whatever way you want, but they must contain the above mentioned widgets inside the hierarchy. Nearly every function inside these widgets are designed to be overriden for maximum customization. It is advised to read the [ExternalObjects](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects) page to understand the **I\_ExternalObjects** interface. [PreviousCreating custom functions](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions) [NextCreating new items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items) Last updated 1 year ago * [Containers, Tiles and Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets#containers-tiles-and-items) * [Containers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets#containers) * [Tiles](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets#tiles) * [Inventory Item](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets#inventory-item) --- # Loot Tables | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables.md) . * * * There are tons of ways to handle loot tables, but ultimately all they do is add and/or remove items from an array. The abstract design of this system does try to provide you with an interface that allows you to create any type of loot table system, but that does mean that the loot table is slightly more complicated than some other loot table systems. Here are the design parameters that the loot table system follows: * Handled through a actor component and instanced objects. This means you can create custom loot table systems and even mix multiple types of loot tables. * Usable on any actor with a inventory component, including item actors, interactables, player character, etc. This includes allowing item data assets to declare default loot tables. * Items added through loot tables should also have their loot tables imported, meaning recursive loot tables. * `Modular Game Feature` (`MGF`) support. This means that loot tables should be extendable through content updates/DLC/expansions. The loot table system comprises of 2 parts; A component (loot table) and an array of instanced objects (loot pools) that live inside the component. Game features are still labeled as "Beta", so do expect some bugs around `MGF`'s. But they have been battle tested extensively through Fortnite, last time I heard they had over 200+ `MGF`'s. This system does not rely on `MGF`'s, it's simply meant to be utilized by them. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#loot-table-component) Loot table component --------------------------------------------------------------------------------------------------------------------------------------------------- The loot table component is the heart of the loot table system. When the inventory component calls **StartComponent**, it will first try and find any loot table components and run **PreInventoryInitialized** and forward that to the `Loot Pool Object`'s. Most functions will not work as expected, because this is before anything is initialized. You are just expected to manually modify the **ContainerSetting**'s array as if you were modifying it yourself by hand. Most changes will be done here. Once **StartComponent** is finished, it'll call **PostInventoryInitialized**. All functions will now work just as normal, but you are expected to add most items during the pre-initialization phase. * You can have as many loot table components on an actor as you want. This is primarily used for better `MGF` support. * Loot table components are sorted by their **Priority**. Higher priority components are ran first. This is to allow future components added through `MGF`'s to increase the chances of new content being prioritized. But keep in mind, this gives some loot tables a slight bias over others. * Loot table components are automatically destroyed on clients. They are only utilized by the server. * The **PostInventoryInitialized** function does open up the possibility of doing async loot tables or spacing out loot additions. This should really only be considered if you are doing hundreds of items. It is of course up to you to handle when you start this async operation and implementing it. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#loot-pool-object) Loot Pool object ------------------------------------------------------------------------------------------------------------------------------------------- These objects are what actually try to modify the inventory components **ContainerSetting**'s, store any data and run any meaningful functions. These are stored in the loot table components **LootPools** array. By default, this has nearly nothing inside of it. The plugin comes with 2 examples, a simple loot pool and a advanced loot pool. * Simple example: Contains an array of items, each has a percentage to spawn and the order is then randomized. * Advanced example: This loot pool object has the ability to be globally modified during runtime through `MGF`'s. This system utilizes a world subsystem that only exists on the server and `MGF`'s can dynamically add and remove items from the subsystem. The subsystem has a map of tags and this object fetches the items to use through this tag. This means that these advanced loot pools can be expanded on in future updates very easily, without referencing any assets and allowing the loot to have the same probability as other items in the pool, where as the simple example will always have some bias as one loot pool has to be executed before the new ones added through `MGF`'s are executed. Remember, `MGF`'s are one-way referencable only, in your base game, you shouldn't reference content inside of `MGF`'s. * This system also has the ability to dynamically add/remove items from loot pools during runtime, so you could for example have a chest that has more items inside of it, depending on if the player has defeated a specific boss. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#modular-game-features) Modular Game Features ----------------------------------------------------------------------------------------------------------------------------------------------------- Some games using IFP might get content updates, DLC, expansions, something that adds content to the game, such as items. Loot tables is the primary way that most games handle additional content post-release. * It's not recommended to put item assets into MGF's because it highly complicates how the inventory of all actors is managed. What if the player is wielding a weapon added through a MGF and the MGF gets disabled? Do you delete the item? When it's enabled again, how would you restore it? If you do decide to add item assets through MGF's, then you are responsible for managing inventories if it's ever disabled. The only exception to this is if you are permanently enabling this MGF, like an expansion. Then this scenario won't ever happen. * By default, there are 2 ways to add new content to loot tables. One is to add another loot table component to actors. This follows the same procedure as the standard `Add Components` action MGF's come with. The other is used by the advanced example loot pool object and that is registering more items to the subsystem. If you don't like either option, then you can always implement more methods by creating new loot table objects. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#overriding-the-loot-table-system) Overriding the loot table system --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- If you want to completely override, customize or even implement your own entire custom loot table system, that is also quite easy to do. Just simply override the **ProcessLootTablesPreInitialized** and **ProcessLootTablesPostInitialized** functions in your inventory component. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#pre-loading-assets) Pre-loading assets ----------------------------------------------------------------------------------------------------------------------------------------------- Loot pools have the ability to start loading any assets before the loot table is processed by calling **PreLoadAssets**. It is recommended to roll your spawn chances here, then only load the assets that succeeded their spawn chance and populate a second array with these items. This way you don't uneccessary load any assets that would have failed their spawn chance. * By default, there is nothing calling this function. It is up to you to decide when and how this is called. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#item-asset-loot-tables) Item Asset Loot Tables ------------------------------------------------------------------------------------------------------------------------------------------------------- To have item assets have loot tables, you must override the **GetLootTables** function and pass in an array of loot tables. An example can be found in the `DA_Equippable` and `DA_Weapon` item assets that come with the plugin. When **StartComponent** is called, it'll check any item that has the `IFP.Initialization.IncludeLootTables` tag and then create loot table components with the same settings as the ones declared in the item asset and attach them to the same actor that the inventory component belongs to. This tag is then removed afterwards. Loot tables can get the item they were created from and its containers through the **GetParentItem** and **GetParentItemsContainers** functions. Loot pools have a **GetLootTable** function, so loot pools also have access to this data through this function. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#data-registry) Data Registry ------------------------------------------------------------------------------------------------------------------------------------- `MGF`'s reference a "data registry" which seem to have been introduced around 4.26, but at the time of writing, there is very little documentation and examples of how it works or how best to utilize it, but the lead engine programmer at Epic did discuss it in [this video](https://www.youtube.com/live/7F28p564kuY?si=xX839PLPJHtXyZjN&t=5027) and he even refences a loot table system. I won't be using data registries in the example project for now, because some of the functions around it are still labelled as experimental and due to the lack of documentation or any sources of how to best utilize it. [PreviousItem Sockets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-sockets) [NextSaving and loading](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading) Last updated 1 year ago * [Loot table component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#loot-table-component) * [Loot Pool object](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#loot-pool-object) * [Modular Game Features](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#modular-game-features) * [Overriding the loot table system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#overriding-the-loot-table-system) * [Pre-loading assets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#pre-loading-assets) * [Item Asset Loot Tables](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#item-asset-loot-tables) * [Data Registry](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables#data-registry) --- # Ability System Integration | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration.md) . [**Video tour**](https://youtu.be/rvd6SbspA9E) An important note around `IFP`'s design is that it was NOT built with any specific ability system in mind, but rather have good extension points to allow for it to interact with any ability system and for any ability system to interact with `IFP`. This design philosophy has led to `IFP` being extremely easy to integrate with any ability system. This page will mostly cover `GAS`, since that is the most popular ability used with `IFP`. But concepts can still be adapted to any type of ability system. > In 2.10 a separate module including several classes to help with `GAS` integration is included in the plugin. This does mean that `IFP` has a dependency on `GAS`. To remove that dependency, remove the `IFP_GAS` module folder, then open `InventoryFrameworkPlugin.uplugin` and remove the `IFP_GAS` module from the modules list and the `GameplayAbilities` plugin from the plugins list. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#connecting-ifp-with-your-ability-system) Connecting IFP with your ability system -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The primary way `IFP` is meant to connect to your ability system is through the `Traits and Components` system that can be found in item assets, or by either modifying the item asset or creating specialized children who then contain references to classes, such as an ability class. Then through code, you'd fetch these references and either grant, remove or activate them. The other method would be through the various delegates that come with the inventory component, such as the ItemEquipped delegate is a good candidate to grant the player abilities. Then the primary way of your ability system interacting with `IFP` is through some type of reference to a specific item or a group of items. For example, a gun firing ability could fetch what is currently equipped in a specific container and use data stored on that item to run its logic, such as fire rate. In this case, the ability could remain active for the entire lifetime of the actor and simply continue using data from equipped items to run its logic. This is one of the most performant and perhaps most scalable solution. This also means you are only creating one object to handle this logic rather than creating a new one for each item. * This topic is covered more in [**here**](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#gas-abilities) In some cases, it might be worthwhile adding direct references to either system into the other system, for example adding ability class references to the item asset or modifying abilities to reference and depend on an inventory item. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#native-gas-support) Native GAS support -------------------------------------------------------------------------------------------------------------------------------------------------------------- As mentioned above, 2.10 includes `GAS` support out of the box. This section covers how it works and how to customize it. > Remember, this is just one way of implementing `GAS`. Many projects might have different requirements or different needs. Hence why I made the native `GAS` implementation simple to remove. This is just one way for `GAS` to be implemented with `IFP` * **IT\_GameplayAbilityReferences**, **IT\_GameplayEffectReferences** and **IT\_AttributeSetReferences** are item traits which stores class references and include events for granting and removing their respective system. * The actor component `AC_GASHelper` will handle all items containing these data-only objects and handling the events that grant and remove them. You will want to add this component to the same actor that the inventory component is on. * This component has a simple "Tag Event" system. This is meant to help filter out when to grant and remove abilities and attributes for specific events. These events can be called from anywhere by simply broadcasting the `TagEventActivated` delegate with a tag event. The component will now automatically get all items for that event and attempt to either grant or remove abilities, attributes and effects. * To process an item, you need to call the **ProcessItem** function and pass in an event. This function will call 6 functions, trying to grant and remove any abilities, attributes and effects. If you want to, you can call each function individually or separately. * This component can have a blueprint child and most functions can be overriden to customize its behavior. * By default, this component handles 3 events (You can override the **BindDefaultEvents** function to increase the number of events the component automatically handles): 1. When **AC\_GASHelper** has its **StartHelperComponent** function called. 2. When an item is equipped. 3. When an item is unequipped. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#notes) Notes * This system does not keep track of duplicate items. For example, the player can equip 2 rings sharing the same item asset. When they unequip Ring1, then it will try and remove anything the asset wants removed, even though Ring2 should still grant them the asset wants them to have. To get around this, I'd recommend overriding the **BindDefaultDelegates** and do not call the parent, so it stops handling the `ItemEquipped` and `ItemUnequipped` event and you would now either make your own delegate that tries to accomodate this, or improve the code behind these two delegates, or handle this through some other code somewhere else. * For effects, it is recommended to use `Infinite` effects. If you use `Instant` or `HasDuration`, the effect might not be reversable. For example, modifying an attribute with `Instant` will just modify the attribute and when we try to remove the effect, nothing will happen. If it has `Infinite` duration, then the modification made to the attribute will be reversed when you remove the effect. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#item-component-ability) Item Component Ability ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- `IFP` includes a "ItemAbility" `ItemComponent`, which is not related to `GAS` or any other ability system, but is designed to look and behave very similar to `GAS` abilities (This is the closest `IFP` has to an "ability system"). While you should continue to use `GAS` abilities whenever possible, the levels of networking optimizations that Epic have provided for `GAS` has created a few limitations to `GAS`, which includes: 1. `Instanced Per Execution` does not seem to have replication support anymore. 2. Changing ownership of an instanced ability does not seem to be supported. 3. Having a `GAS` ability treat an item as its owner requires a lot of work (as in, an ability that would use `Instanced Per Actor` would only ever have 1 instance created for the owner of the inventory component, but you might want it to be something like `Instanced Per Item`, so you could have an instance made for an item, but only 1 per item). This ability component is designed to get around these limitations. So again, use `GAS` abilities whenever you can, and only use this component if the above limitations are preventing you from making your ability. To activate an item ability, you can call **TryActivateItemAbility** or **TryActivateEquippedItemAbility** The scope for this ability component is very small to try and reduce complexity and just provide the basic interface of an ability system. Item Components already have networking support, but you will have to implement any RPC's to communicate to clients. By default, item abilities are completely server authoritative. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#creating-a-new-item-ability) Creating a new item ability I advice you make your own item ability parent and ability trait parent, then have all your item abilities be children of your parent and override some functions to fit your project, for example **GetOwnersTags** To create a new ability, create a new child of **ID\_ItemAbility**, or of your item ability parent. * Optional: You can also create a item ability object if you want to expose more variables to the item asset or override some functions. For example, you can override **AllowNewInstance** to customize the "instancing policy" for the ability or the **LooselyCheckCanActivateAbility** function to minimize failed activations. You will now want to open your item asset and add an item ability object to your **Traits and Components** array and assign the **Item Component** to your new item ability [PreviousSystems](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems) [NextCrafting](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting) Last updated 1 year ago * [Connecting IFP with your ability system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#connecting-ifp-with-your-ability-system) * [Native GAS support](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#native-gas-support) * [Notes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#notes) * [Item Component Ability](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#item-component-ability) * [Creating a new item ability](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#creating-a-new-item-ability) --- # UI Navigation | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation.md) . UI Navigation refers to an input such as a controller joystick, gamepad or arrow keys to attempt to navigate tiles and items inside of a container. This is handled through `EnhancedInput` and the `Container` widget. > This documentation covers just container and item navigation. Things like context menu's and so forth fall under common navigation, which has a mariad of ways to handle and there are plenty of resources on how to handle common UI nagivation. To handle navigation between multiple containers, either fill out the `Navigation` settings in the container widget instance or handle it through the `NavigatedOutOfBounds` delegate which will let you know which direction the user last tried to navigate. For example, if they tried to go down, but no valid tile was found, this delegate will go off and say they tried to navigate downwards. You could now grant focus to the container below the container that currently has focus. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FfOLVWekSfTOYpcydnAcD%252FNavigationDetailsPanel.png%3Falt%3Dmedia%26token%3D35fe4449-414f-49c7-b7a1-77e1c529c5bd&width=768&dpr=3&quality=100&sign=d9d45a84&sv=2) > Input action and mapping context references are automatically assigned to the ones that come with `IFP`. The navigation system fetches the class defaults to know what action and context to use. To customize them, go into `BP_AC_Inventory` and change the settings inside of the `Settings -> Input Settings` category. Important As of 5.4, there is a bug with all the properties in the `Navigation` category. Whenever you assign new values, you must recompile and resave the asset yourself. The bug is that the asset is not being marked as dirty and in need of recompilation. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#virtual-cursor) "Virtual" cursor ------------------------------------------------------------------------------------------------------------------------------------------- To simplify a lot of the logic, the container widget will take control of the cursor to act as a "virtual" cursor (Handled in **NativePaint**). `CommonUI` does the same, although they seem to have a "synthetic" cursor. As of writing, I am not able to find any sources, other than reverse engineering `CommonUI`, on how to make your own virtual cursor. The container will return control to the cursor if any movement is detected (**OnMouseMove**) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#dynamic-navigation) Dynamic navigation ------------------------------------------------------------------------------------------------------------------------------------------------- In some cases, containers are added to the screen during runtime, like opening a chest. In this case, the navigation panel above won't work. To override the above settings, you can assign override containers for each direction (for example, NavigateRightContainerOverride variable will override the right input navigation). Here is an example of how that would work: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FV7TCniEEcrF6tkTS2J9h%252FNavigationOverrideExample.png%3Falt%3Dmedia%26token%3Dad5e47e1-e5f1-4c68-be17-8f89d8e5a246&width=768&dpr=3&quality=100&sign=41edbe39&sv=2) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#customizing-navigation) Customizing Navigation --------------------------------------------------------------------------------------------------------------------------------------------------------- If you wish to completely override the navigation system for `IFP` or customize it, there's a small list of functions you can override. Container widget functions: * **OnKeyDown** (All logic starts here) * **GetNextItemToNavigateTo** * **GetNextContainerToNavigateTo** * **NavigationFocusUpdated** * **ItemNavigationFocusUpdated** * **SetCurrentNavigatedItem** Item widget: * **ItemHighlightUpdated** * **StartDragItem** * **StopDragItem** * **CancelDragItem** * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#scroll-boxes) Scroll Boxes ------------------------------------------------------------------------------------------------------------------------------------- By default, containers will keep the currently navigated tile in view within the scrollbox inside that container. But if you navigate to a new container inside your inventory UI that is not in view, you need to handle that, since that is outside of the containers code. Here is a basic example from the example projects inventory UI widget: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252F9VYGGVy8DluhuvlsAW7A%252FScrollBoxNavigationExample.png%3Falt%3Dmedia%26token%3D7e75f80c-6497-4c78-b1e5-6a7302ddfefa&width=768&dpr=3&quality=100&sign=c9c9d4c8&sv=2) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#commonui) CommonUI ----------------------------------------------------------------------------------------------------------------------------- `CommonUI` is not utilized by the plugin due a few reasons, but the primary reason is the lack of easy customizing the navigation around containers. For example, snapping to nearby items rather than navigating tile by tile. The true questions around `CommonUI` that have to be asked is: What does it provide to `IFP` that justifies `IFP` having a dependency on it? Truly, `CommonUI` just provides 2 things: Reworked navigation and new widgets that handle common things. The reworked navigation is great, but lacks customization. The widgets provided by `CommonUI` are not beneficial to `IFP`. Maybe the example project, but not the base plugin. `IFP` can be utilized by `CommonUI`. Many people have designed their inventory screen made out of `CommonUI` panel widgets. But as of writing, `CommonUI` is too complex for beginners, lacks debugging tools and doesn't provide enough to `IFP` to justify being dependend on it. Many people do not want or like `CommonUI` and I dont want to force people to use it. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#commonui-integration) CommonUI integration > This section is a work-in-progress. I personally do not use `CommonUI` and very few people seem to be using `CommonUI` so some details and steps might be missing. * As pointed above, the only thing `CommonUI` provides to `IFP` is the reworked navigation. But their navigation only searches for `CommonActivatableWidget`'s. Depending on how you want to control your navigation, you might want to reparent **W\_Container**, **W\_Tile**, or **W\_InventoryItem** to **UCommonActivatableWidget** so `CommonUI`'s navigation can detect those widgets. [PreviousTile Tags](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags) [NextWorking in the system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system) Last updated 1 year ago * ["Virtual" cursor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#virtual-cursor) * [Dynamic navigation](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#dynamic-navigation) * [Customizing Navigation](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#customizing-navigation) * [Scroll Boxes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#scroll-boxes) * [CommonUI](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#commonui) * [CommonUI integration](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation#commonui-integration) --- # Optimizations | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations.md) . While `IFP` is already extremely optimized, there's a few things you can do and keep in mind to make sure you are getting the absolute most out of `IFP`. To start, lets first cover what are the most expensive parts of `IFP` (Listed in semi-random pattern. It is not possible to 100% be certain what is the MOST expensive in all projects as there are multiple factors as when some things might become more expensive than others): * The biggest performance culprit are the item widgets. About 33% of the cost of making a widget for an item just goes into creating the UMG hierarchy inside the widget. * Finding an available tile during **StartComponent**. The more tiles an item occupies, the more calculations are required to find a spot. This is also where the InventoryHelper can improve performance. If a specific tile is provided to an item, it doesn't have to scan the entire container to find a free tile. This can be alleviated with the `SkipValidation` system, which can be found in the inventory component documentation. * Disabling rotation for items through **AC\_Inventory** \-> **CanItemBeRotated** will reduce the amount of calculations required during **StartComponent**. * Unfortunately, removing some Blueprint features greatly improves performance. Let's take **CheckCompatibility** as an example. In a test with 100 items, this function in total took 1.5ms, but removing the `BlueprintNativeEvent` keyword from the UFUNCTION, which is the keyword that allows the function to be overriden at a Blueprint level, reduced the total time down to 0.090ms. Removing Blueprint support improved the performance by about 16 times. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#separating-lag-spikes) Separating lag spikes --------------------------------------------------------------------------------------------------------------------------------------------------------------------- One of the great benefits of IFP's structure is that it doesn't require widgets to function. Which means we can separate the lag spike of starting the component, creating the inventory, the widgets, and adding the inventory screen to the viewport into four chunks. 1. Loading item assets asynchronously. 2. Calling **StartComponent**. 3. Creating the inventory screen widget. 4. Binding the containers with the widgets inside of the inventory screen. 5. Adding the inventory screen widget to the viewport. * The function `GetDynamicMaterial` is surprisingly expensive the first time it is called and can cause a noticable spike. This is used by the item widgets. If possible, you should try to trigger this function during your loading screen or staggering these function calls, for example creating the inventory screen during the loading screen. Doing all of these at the same time will in some scenarios create a spike that is noticable to players. But separating them will make it (hopefully) invisible to players. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#widgets) Widgets ----------------------------------------------------------------------------------------------------------------------------------------- ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#tiles) Tiles The tile widget is already highly optimized. The hierarchy can be reduced to just an image. (The demo widget has an overlay inside of it for debugging assistance. Removing it will almost double the construction speed. * The only feature in the tile widget that is expensive is the `TileTags` feature. It's not that the functionality behind it is expensive, it's simply the fact that this feature is getting executed per tile and containers can end up being 100+ tiles and the price starts to pile up, which is something you need to keep in mind in general when working with tiles. All your code must be highly optimized when it comes to the tile widget as your code might be spammed by hundreds of tiles within one frame. * If you plan on having a very large amount of tiles, then the simple rendering cost of so many separate widgets might become a limiting factor for you. At this stage, `IFP` can't do any more optimizations. But that doesn't mean you can't. The reason why `IFP` can't do any more optimizations is because this ultimate optimization would remove some features and make some operations slightly more complicated. The TLDR; You want to modify `IFP` so that it only generates one tile widget. Then give it a material that tiles the material you want to use. Now you're only paying for one widget render and only rendering one material. This does mean that a few features, like dynamic shaped containers and tile tags become extremely complicated or not possible to use. This should be a last resort and you should evaluate whether this is worthwhile for you by profiling your project with Unreal Insights. There's 2 other paths you might want to consider before this: * Use the `View` widgets (like `List View`) to host the tiles. These widgets are designed to only spawn a widget when it becomes visible in the viewport. `IFP` might someday implement this natively, as this is a good way of optimizing inventory screens and this should not affect any `IFP` features. * Convert the tile widgets to slate. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#items) Items The item widget will be going under a few optimizations throughout the next updates, but there are some core optimizations you can do: * Generated item icons are and always will be much more expensive than just disabling it and using a texture. The `ItemEditor` tool can take the generated item icons and save them to disk as a texture to assign in the data asset. Getting the best of both worlds, though this will remove any features where the icon updates depending on what is attached to an item, for example attaching a silencer on a gun and having the icon update accordingly. * Staggering out the generated item icons. This is actually a default feature that can easily be enabled in **WBP\_InventoryItem**. * Depending on the simplicity of your equipment, you might want to do what some of the Resident Evil games do. They have a texture for each gun and every combination of it with attachments. Of course, they had very few weapons and very few combinations of equipments. So again, depending on the simplicity of your project, you might want to consider this technique. * Create some of the widget components during runtime. For example, the ItemCount text. If the majority of your items can't be stacked, you are then creating a text widget that will never be shown for a lot of items. By default, `IFP` does not do this as this is generally a more annoying workflow. This really comes down to per projects needs. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#other-notes) Other notes These are notes that aren't directly around `IFP`, but are still useful for all UI design. * If the player can not see the world while looking at the inventory or in an escape menu or something else, you can implement and call this function to completely disable world rendering and gain tremendous frame rate gains: ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FpttT8JKC01S6kt7WTQ0T%252FSetEnableWorldRendering1.png%3Falt%3Dmedia%26token%3D6b97bdc5-fbcc-4280-a469-f58a0bfe4d88&width=768&dpr=3&quality=100&sign=d11ed890&sv=2) ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252F0x4OwhhJw54w1nShKLDI%252FSetEnableWorldRendering2.png%3Falt%3Dmedia%26token%3Da1270309-8364-4f18-afb4-d1d5d4abd792&width=768&dpr=3&quality=100&sign=3d822a46&sv=2) * Epic's [**documentation for optimizing**](https://dev.epicgames.com/documentation/en-us/unreal-engine/optimization-guidelines-for-umg-in-unreal-engine?application_version=5.2) everything related to UMG: [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#networking) Networking ----------------------------------------------------------------------------------------------------------------------------------------------- The only real meaningful thing you can do about network performance is trimming down the `FS_ContainerSettings` and `FS_InventoryItem` struct. For example; if you don't need the overwrite settings for items, you can remove it to reduce the RPC size of all items. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#equipment) Equipment --------------------------------------------------------------------------------------------------------------------------------------------- * Do not use Blueprint Actors for your equipment. They are in some cases 11 times more expensive than skeletal/static meshes. Many people have proven that it is possible to do complex logic, like guns with animations and so forth without using Actor equipments. I personally suggest using GAS and whenever an item is equipped/unequipped, you fetch the mesh and let the GAS ability animate it and so forth. * Equipment easily take up 70%+ of the lag spike caused by **StartComponent**. If you want to keep using lots of equipment, you need to start calling **StartComponent** during your loading screens or managing equipment better. In reality, only the player character should be spawning equipment meshes. [PreviousModifying Critical Files](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files) [NextSetting up vendors](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors) Last updated 6 months ago * [Separating lag spikes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#separating-lag-spikes) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#widgets) * [Tiles](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#tiles) * [Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#items) * [Other notes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#other-notes) * [Networking](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#networking) * [Equipment](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations#equipment) --- # Equipping and unequipping items | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items.md) . This documentation covers the default equipment system. In some cases, you might want to implement your own or use a hybrid solution, which is covered more at the bottom of the page. [Deep dive video](https://youtu.be/Tb7FwW3ri6k) * * * A big problem I try to solve with this system is that I did not want to assume anything about how your actors' meshes are set up, how your equipment setup looked like and I did not want to make a base player or actor blueprint. There are two main reasons behind this decision: First is this allows you complete control over what items are attached to (for example if you have a horse and want to give it armor, but the component is only setup on the player) and secondly is that people might already have a player blueprint hierarchy setup and I did not want to mess with that and some people might not want to use my hierarchy setup. The logic that runs the equipping and unequipping logic is stored in a object and item component called **IT\_Equipment** and **IC\_Equipment** (if you are unfamiliar with the [item component system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components) , I suggest getting familiar with it first) and they use a struct called **EquipmentData**, this struct attempts to solve most issues when it comes to having multiple skeletons, meshes or complex equipment logic, such as having a gun attached to a backpack which is attached to the player character and that gun has a sight attached to it or FPS shooter setups where you have a local arms skeleton and then a full body skeleton. This struct also attempts to keep the system away from hard coding any types of “main weapon” and “secondary weapon” or anything of the sort. I’ve found those types of setups often become cumbersome when a designer wants to add or remove these types of things. Keeping the equipping system inside of a item component provides a modular way for you to allow any item you want to be equippable, or trigger special animations when its added to an items container. It also allows you to easily implement your own system if you want without rewriting C++ code or affecting how the inventory system works at a fundamental level. During my research, I found an astonishing amount of different workflows and processes. It was very daunting to try and solve all of them in one go, and maybe my system isn’t perfect, but it tries to solve as many as possible at once, while still being flexible and adjustable. I recommend reading the comments in the **EquipmentData** struct (Found in **IFP\_CoreData.h**) and going through **IC\_Equipment** (which is an item component found in the plugins folder Core -> ActorParents -> TraitsAndComponents -> Equipment.) and look at the logic in there to get a better understanding of how the system is using this struct. I would explain it here, but it’s so long and extensive that explaining it in just text and pictures would take too long. This component attempts to copy the system that is used in GAS with its **PlayMontageAndWait** function, which creates an object that handles the animation, but I wanted to keep mine inside of Blueprints. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#optimizations) Optimizations For weapons and equippables, I've implemented three methods of creating your equipment mesh (Item reperesentation): 1. Blueprint, this allows you to simply use any blueprint you've made as the item representation. 2. Skeletal mesh 3. Static mesh Blueprint's are about 11 times more expensive to spawn than meshes, but are the most customizable. I recommend staying away from using Blueprint's as your item representation whenever possible. For multiplayer, meshes are encouraged even more as they are very cheap to replicate. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FOR58ZgOR3havgiyx6EZ4%252FProfiler_BlueprintEquipment.png%3Falt%3Dmedia%26token%3Df67f5843-4ebf-4d02-88bf-e309faca7fb7&width=768&dpr=3&quality=100&sign=e6ffe23c&sv=2) Blueprint ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252Ftn8pga1fjT0S3cvVttA3%252FProfiler_StaticMeshEquipment.png%3Falt%3Dmedia%26token%3D79b81c34-d845-473b-a9c9-3ab5c031afd9&width=768&dpr=3&quality=100&sign=a47e8b68&sv=2) Static Mesh Blueprints took 1.5ms, while static mesh only took 0.131ms For skeletal and static meshes, you gain access to most settings you would have in the details panel while editing them in a blueprint regarding Skeletal and Static Meshes[](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#regarding-skeletal-and-static-meshes) The default material section is not available (I assume this is an engine bug?). If you wish to change the default materials, go into Rendering -> Override Materials Notes for optimal multiplayer experience[](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#notes-for-optimal-multiplayer-experience) The way Unreal handles replication for attached actors is not the most elegant. When another player becomes relevant for another client, not all attached actors will get replicated within the same frame, and they might not even replicate in the order that you want them to. Leading to odd snapping or pop-in. This could be awkward if you have naked characters and then the clothing around them are blueprints. This is another reason why it's suggested to stay away from blueprints for multiplayer, as with meshes, since they get attached to the actor itself, when it comes time to replicate it theres no snapping or pop-in. All components on an actor are replicated within the same frame. There is always a chance a packet will be dropped, which is again why you should refrain from blueprints as the engine does a very good job ensuring every mesh component is replicated. For every blueprint, you're adding another actor, and another equipment manager component, and more RPC's and more RepNotify's and each of those have a chance to get dropped. These optimizations of course only matter depending on the scope of your game. This more or less serves as an idea of what to focus on during the optimization phase of your game and what you might have to look for. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#manually-labelling-items-as-equipped-unequipped) Manually labelling items as equipped/unequipped By default, IFP will label an item as equipped or unequipped when an item is added or removed from an equipment container. But in some cases, you want to manually handle this, for example labelling an item that is in a normal grid as equipped. This can be handled through the **UpdateItemsEquipStatus** function. This can accept custom trigger filters to allow for you to filter out what equipment settings to use in the in-built equipment system or to use in your own custom equipment system. * Whenever an item is equipped, a tag is automatically applied, called **EquipTag**. This can be set in the class defaults for the inventory component. This function is never used in base `IFP`, so it is expected for you to handle when and how it is called to equip and unequip an item. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#events) Events There are two events that can activate when equipping and unequipping an item occurs. 1. The first is the component's **ItemEquipped** and **ItemUnequipped** delegate. This is only called when an item is added or removed from a slot. This is only called on the actor that the inventory component the slot belongs to, so equipping a weapon as a player will have the delegate call on the player, not the weapon. 2. Two interface functions also called **ItemEquipped** and **ItemUnequipped** from **I\_Inventory** are called whenever the equipment system spawns or updates the status of an item. For example, equipping a gun so it spawns, then holstering it and unholstering it. * If your settings have the item set as a blueprint, these events are called on the spawned blueprint. For example, equipping a weapon as the player will have the interface functions called on the weapon, not the player. The inverse of point 1. * If your settings have the item set as a static mesh or skeletal mesh, the interface functions are called on the player. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#notes-on-general-equipment-system-design) Notes on general equipment system design * Equipping and unequipping items can get messy, most importantly it can get messy when players start spamming the system with animations, either by quickly equipping and unequipping an item really quickly or equipping multiple items, all trying to activate montages which will interrupt each other. In the demo, items do not play an animation when equipped or unequipped. But they do play an animation when you holster or unholster an item. If you're in multiplayer, the item will also be added to the network queue to prevent clients from spamming the server with RPC's. By default, there is no failsafe if an animation is interrupted as that is something most designers want to implement their own system into. Some designers might want players to be able to cancel animations or cancel the equip if it was interrupted. It is up to you to implement any sort of failsafe if players are finding ways to manipulate this animation cancelling in ways you don't like. * If you're going to have items visible on your character, it is recommended to have at least one setup for every item that instantly attaches the item to the desired location and mesh. This is so when you load a save, you won't get several animations playing at the same time and overlapping each other. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#why-are-all-my-components-getting-renamed) Why are all my components getting renamed? The system automatically tries to keep all components attached to an actor with unique names - including attached actors. This is for 2 reasons: 1. Because of how the preview system works. The preview system attempts to reconstruct the actor it's previewing without fully cloning it. There are ways of perfectly cloning an actor, but those are very expensive and come with their own set of problems. The preview system only looks at the visible components on the actor, including attached actors, and reconstructs it. But problems occur if two components have the same name from 2 different attached actors. When the preview system reconstructs the actor, it finds out what component it was attached to, but it needs to know which component that is on itself, it can't use the object reference. This means that if two components have the same name, it'll mess up which component it should attach to. The simple fix to this is to make sure all components have a unique name. The engine already handles this if you attach a component to an actor and that actor has a component with the same name, but it does not do this for attached actors. 2. The engine does not have failsafes when two components on the same actor have the same name and will crash. But to simplify debugging, only a underscore and a random number is added to the end of it. The rest of the name is untouched. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#where-are-the-items-being-created) Where are the items being created? A separate actor component called **BP\_AC\_EquipmentManager** is created and attached to the owning actor to handle the creation of items. This is handled this way because of replication. Before the system was replicated, this component didn't even exist and the system worked just like it does now. This component is responsible for ensuring items are replicated in the correct order and attaching things in the correct order, in case an item got replicated before the item it is attached to is replicated. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#common-issues) Common issues Physics is typically the main culprit for the equipment system breaking. If an item or components have physics on by default, they will instantly detach the moment they are initialized. Breaking the entire equipment system. Physics will also cause issues with generated item icons, as that system relies on the attachment hierarchy being correct and detaching things due to physics will break it. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#custom-equipment-system) Custom equipment system It's fairly simple to completely replace the equipment system or use a hybrid solution. To understand the beginning of the chain, the equipment system begins on the actor's Inventory -> ItemEquipped delegate event. This is where you'd inject any modifications to the base behavior of the equipment system. In some cases, it's simpler to just swap out a mesh with a new one. For example, the player might have a default jacket if no other jacket is equipped. In this case, it's much simpler to just use a custom equipment object which holds that other mesh and swap the default jacket mesh with the new one. It all comes down to the complexity of your game. The default equipment system tries to cover **a lot** of different and complex scenarios, thus it has become big and can be overcomplicated depending on the simplicity of your project. [PreviousDrag and drop](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/drag-and-drop) [NextModifying Critical Files](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files) Last updated 1 year ago * [Optimizations](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#optimizations) * [Manually labelling items as equipped/unequipped](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#manually-labelling-items-as-equipped-unequipped) * [Events](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#events) * [Notes on general equipment system design](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#notes-on-general-equipment-system-design) * [Why are all my components getting renamed?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#why-are-all-my-components-getting-renamed) * [Where are the items being created?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#where-are-the-items-being-created) * [Common issues](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#common-issues) * [Custom equipment system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items#custom-equipment-system) --- # DA_CoreItem | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem.md) . * * * This is the data asset that is responsible for the base information for your items. I highly suggest looking at the **DA\_CoreItem.h** file to see all the settings, functions and comments. You can show and hide certain settings depending on your setup, and I use that a lot with the **ItemType** enum. Look at all the options, check out the meta properties (EditCondition and EditConditionHides) to see how it’s done, and you can then implement your own options and rulesets for their visibility. Keep in mind, these settings are only HIDDEN, not disabled in the data asset editor, you can still access those variables from the data asset in blueprints and C++ and you have to remember that when making your functions and gameplay logic. One of the most important settings to set up here is **EItemType** as many functions use this enum to do casts to the proper children of this asset. Whenever you make a new child, remember to go into the .cpp file and set the default value. You can see an example inside all the .cpp children of this. If you are new to C++ or Unreal Engine, I suggest looking [**here**](https://benui.ca/unreal/uproperty/) to find all the specifiers you can give each variable. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#creating-new-items) Creating new items ------------------------------------------------------------------------------------------------------------------------------------------------------------ [**Video documentation**](https://youtu.be/GzxE6spwgCQ) (slightly outdated, for example the content browser and item actor name have been changed, but majority of it is still relevant. The only thing that should be ignored is around `06:23`, I state that you should import the containers from the data asset into the item actor. This is no longer needed, only the first index needs to be setup.) Creating new items is very simple. To start off, you'll need to go into the engine and find your content browser, right click and go to **Inventory Framework -> Inventory Item Asset** and a pop up will appear asking you what parent your data asset should derive from. You might have your own children or have removed some of the children that come with the asset, but whatever asset you choose must derive from **DA\_CoreItem** at some point in its hierarchy. I suggest creating a folder for your item and placing the data asset in there. To create a blueprint actor for your item, you will have to create an actor who at some point in its hierarchy is a child of **A\_ItemActor** (The blueprint child is called **BP\_ItemActor**), then set that as your **ItemActor** The actor will automatically get the blueprint inventory component assigned to it. You will need to go into the component settings and change a few things. 1. Set **InventoryType** to "**Pickup**" 2. Add one index to **ContainerSettings** and set the **ContainerType** to "**ThisActor**". This will then hide most of the settings except for the items array. 3. Your items array should only have one index, which will be your newly created data asset. All settings can be left to their default. 4. (Optional) If your item has containers associated with it, the data asset should have an array of **DefaultContainers**. You will want to populate these with your containers and also assign the widget. Only available to supported data assets, such as **IDA\_Equippable** and **IDA\_Weapon**, to create your own item asset with container support, override the **GetDefaultContainers**. An example can be found in the example project with the gun and backpack item. To have the asset manager pick up your data asset, it can not be identical to another data asset. (This includes the base file, so if all your variables are set to default, the asset will not get picked up.) Typically you want to immediately give your item a name and a developer image for the InventoryHelper. * * * ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#creating-new-c-children-of-da_coreitem) Creating new C++ children of DA\_CoreItem You might want to create your own category of items, and since the engine does not allow you to mix C++ and blueprint children of data assets, you are unfortunately forced to create C++ children. I suggest installing the plugin directly to your project, and then creating new children inside the **Items** folder, which is found inside the plugins **Core** folder. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#changing-the-item-actor-class) Changing the Item Actor class ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Currently your item actors must be a child of **AA\_ItemActor**. If you want to change this, you can change it like so: From To AActor can be swapped out for any class, it does not need to be AActor, but it must be a child of AActor. +++ * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#custom-shapes) Custom shapes -------------------------------------------------------------------------------------------------------------------------------------------------- This inventory system features container styles where items can be different lengths and different heights. The way you define your shape is by adding the Custom Shape trait to your **TraitsAndComponents** array and using the **DisabledTiles** array. Though this is not very pleasant to work with in its raw array format. It is recommended to use the [ItemEditor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor) , where you'll find a toolbox with a few tools inside of it, one being the shape editor. Which gives you a much better UI to work with. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#asset-verification) Asset verification ------------------------------------------------------------------------------------------------------------------------------------------------------------ To aid quality assurance, the data asset will run custom data verification when the asset is saved. The verification validates everything in the following process: 1. Use the **ValidationClass** in the **DeveloperSettngs** category to execute its **VerifyData** function. (Because we can't access a blueprint graph in each instance of a data asset, we do this to get around that limitation.) 2. **ValidationClass** \-> **VerifyData** will run some code to check if any mistakes have been made. Since every project is different, it is suggested to create your own child of **O\_ItemAssetValidation** and write your own code. To validate the data of trait references, an interface function from the **I\_Validation.h** interface also named **VerifyData** is called. You can see an example of this inside of **O\_BasicItemValidation** and **IT\_Consumable** 3. If any error messages are created during any of the **VerifyData** functions, you'll get a message at the bottom right stating the error message. If the **ErrorMessages** array is empty, the item passes the verification. Do note, if an item does not pass the verification, it does NOT prevent you from playing the game. Remember, modifying any variables from a data asset's object reference will change the base asset. This feature is great for a system like this. For example, if you want a specific setting to always be set to something specific, you could programatically change the setting inside these validators. Ensuring these settings remain consistent across a large data-base. I personally use this to ensure all my first-person meshes always have their shadows and collision disabled. If I ever have to change this setting, I just have to change the validator and resave all of my assets and my changes will be reflected across all current and future assets. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#where-to-store-runtime-logic) Where to store runtime logic -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- As the plugin has grown, more and more features have been added, blurring the definition of what an "item" is and where any gameplay logic should be stored. All items are data assets. Then when the inventory is made, a struct is made, which contains all data that can be modified during runtime and this data is replicated under specific conditions. * Data inside of data assets should NOT be modified during runtime. If you have 2 guns in your inventory, then change any data inside the asset, it'll change for both of the guns. But modifying the struct for a gun will only modify that specific struct. The four primary options below leave you with many options to tackle where to store your data and logic. It's up to you to resolve which method is best for what you are trying to accomplish. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#gas-abilities-or-helper-components) GAS abilities or helper components What I, and many others have been doing, is simply constructing one object, a GAS ability or helper actor component, and having that run the logic for, let's say, a gun item. Whenever you swap weapons, you'd just send an event to the ability or component and it would update what weapon is equipped. This approach has a host of benefits: * Many performance benefits. * Simpler for source control. * Easier to find gameplay logic that might not have been touched in some time. * Easier to maintain. * Far fewer points of failure. For each blueprint you create to handle runtime logic, it's another point of failure. This approach minimizes the amount of blueprints, and thus reducing the amount of point of failures. I would recommend using GAS over all other options whenever you can, but of course, not all use cases are the same. There is no ultimate solution that covers every scenario. I personally recommend using [**GAS Companion**](https://www.unrealengine.com/marketplace/en-US/product/gas-companion) and/or [**Gameplay Blueprint Attributes**](https://www.unrealengine.com/marketplace/en-US/product/gameplay-blueprint-attributes) to help with your GAS implementation. * The only downside of GAS that I've found is that it is extremely difficult to have abilities be "instanced per item". As in, a new ability instance is created for each item instance without overriding a lot of C++ code and having a really good understanding of how GAS works under the hood. This type of logic can be achieved with the [`ItemAbility`](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration#item-component-ability) item component. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#traits-and-components) Traits and Components Data assets have "[traits" and "components](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#traits-and-components) ", which I recommend you read the documentation for, but in essence, they are: * Traits: Extra data you can add to any specific asset without creating a new parent. Essentially giving you "horizontal" hierarchy, just like how interfaces add functions to a class without reparenting it. * Example: You have a sword and a health potion asset. Both of these can be crafted, but you don't want to create a "Craftable" item asset to insert into their hierarchy. Not all swords and not all potions might be craftable. You can now add an trait to any asset that has a recipe and have that trait link to that recipe data asset. You can now ask your data asset if it is "craftable" without asking your entire recipe data base if it has a recipe for that item. * Components: Actor components that can be created during runtime and are attached to the same actor that the inventory component lives on. These can run gameplay logic and destroyed during runtime, just like any other actor component. These are tied to traits so they can also be thought of as "horizontal" hierarchy. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#item-actor) Item actor Then there's the optional actor to spawn when the item is dropped, or in some cases equipped. These can be destroyed and created frequently, so it shouldn't really be trusted with a lot of gameplay logic. This should be treated as just the "visual representation" of your item. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#item-instance) Item Instance `ItemInstance`'s are optional objects created when an item struct is created, and they're tied together. Unlike actors, `ItemInstance`'s can be trusted to handle gameplay logic. * **Assigning an instance with an item**: There are two ways to assign an `ItemInstance`'s with an `ItemAsset`: 1. **Data Asset Default**: The default instance is set in the data asset. This is the recommended way. 2. **Override per Struct**: Individual struct instances can override variables for more customization. 3. **Recommendation**: I highly recommend using the first method as that is soft-referenced. * **Replication**: Fully supported and can be optimized with custom replication conditions. * **Restrictions**: By default, assigning an `ItemInstance` in the item struct has 2 rules: 1. "Wild" `ItemInstance`'s are not allowed. This refers to items which have no default `ItemInstance` assigned in the item asset, but you still want to add one to the item struct. It is highly advised to keep this rule enabled to prevent random items having random item instances as keeping track of this is extremely difficult in medium to large projects. 2. You are not allowed to select `ItemInstance`'s that do not match the same class that was assigned in the item asset. This is to prevent two identical items having two different ItemInstance classes, leading to odd behavior.\*/ 3. To disable either or both of these restrictions, modify **FL\_InventoryFramework** \-> **ProcessContainerAndItemCustomizations** * **Serialization (Experimental)**: Item Instances can be serialized, saving only variables marked with the `SaveGame` flag. This feature is experimental and may change in future updates, so it's not recommended for production. I recommend going with a much more robust serialization system that covers much more than just the inventory. * * * #### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#creation-and-destruction) Creation & Destruction * **Creation**: Item Instances are created during `StartComponent` and remain tied to the item until the item is destroyed, unless you enable **ConstructOnRequest**. Then it will only be constructed when you call **GetItemsInstance**. * **Destruction**: They stay alive until garbage collection activates, just like widgets. Use `IsDestroyed` to check their status. * * * #### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#networking) Networking * `ItemInstances`'s replicate to all clients relevant to the inventory owner. However, the item struct data itself isn't replicated and shouldn't be trusted on non-owner clients due to networking optimizations `IFP` enforces. * `ItemInstances`'s can declare their own replication conditions, allowing for optimized network performance (e.g., replicating only to the owner or server-only). * **Important**: If you move the inventory component to the player state for seamless travel, `ItemInstance`'s will replicate to every client. To avoid this, use replication conditions or consider not using `ItemInstance`'s, depending on your game's needs. #### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#performance) Performance * Constructing these `ItemInstance`'s is cheap, but if you plan on using hundreds of these, the small cost can pile up. I highly recommend leaving the **ConstructOnRequest** option set to true. The main worry you might need to consider is the garbage collector. The developers of Hogwarts Legacy had this problem where they abused instanced objects so much that the garbage collector would cause hitches, though I am not sure as to how many objects they were making. I suggest only making these instances for items that actually need it. * If you have a pooling system, then I will continue recommending having **ConstructOnRequest** enabled, then overriding the **RemoveObject** function to no longer mark the object as garbage and move the `ItemInstance` into your pooling system, then modifying **GetItemsInstance** to access your pooling system. [PreviousBP\_PreviewActor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp_previewactor) [NextTraits and Components](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components) Last updated 1 year ago * [Creating new items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#creating-new-items) * [Creating new C++ children of DA\_CoreItem](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#creating-new-c-children-of-da_coreitem) * [Changing the Item Actor class](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#changing-the-item-actor-class) * [Custom shapes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#custom-shapes) * [Asset verification](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#asset-verification) * [Where to store runtime logic](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#where-to-store-runtime-logic) * [GAS abilities or helper components](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#gas-abilities-or-helper-components) * [Traits and Components](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#traits-and-components) * [Item actor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#item-actor) * [Item Instance](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da_coreitem#item-instance) Copy UPROPERTY(EditAnywhere, BlueprintReadOnly, Category="CoreSettings") TSoftClassPtr ItemActor = nullptr; Copy UPROPERTY(EditAnywhere, BlueprintReadOnly, Category="CoreSettings") TSoftClassPtr ItemActor = nullptr; --- # 3.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0.md) . Engine support: 5.5 IFP is implementing instanced structs! A new feature in 5.5 that many in the community have started calling "Fragments". This means that a large portion of the code base is changing to utilize fragments and has thus constituted this update to become **version 3** [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#fragments) Fragments ---------------------------------------------------------------------------------------------------------------------- ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#why) Why? Short answer: Memory optimizations, feature improvements and future proofing. Long answer: Both the container and item structs have a lot of redundant data for most projects or in certain contexts. For example: * **Override settings:** Use 1/3 of item struct memory but are rarely needed. * **Random min/max counts:** Only relevant during initialization for stackable items. * **Compatibility settings:** Occupy 25%+ of container memory but aren't used by all containers. Every time a feature is added to item or container structs, the memory size increases for every project and struct—even those not using that feature. Blueprints didn't support hierarchical structs and the editor provided no UI for them, which forced me to make this sacrifice. However, in Unreal Engine 5.5, "Instanced Structs" have become part of the core engine, enabling Blueprint support for hierarchical structs. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#key-benefits) Key Benefits * **Reduced memory usage:** * Item struct size: **276 bytes → 112 bytes (2.5x improvement)** * Container struct size: **400 bytes → 208 bytes** * This also means IFP's networking is much more efficient now. * **Customization:** Add any data to container and items structs without worrying about future updates overriding your changes. For instance, you can now create a child of the new CompatibilitySettings fragment and implement your own settings. Or create a fragment with custom data to make more unique item customization. * **Networking efficiency:** While networking in IFP is complex, it's extremely efficient. Due to the small size of the average fragment, it's now possible to create a generic function that takes any fragment and syncs it with all relevant clients. This simplifies the creation of replicable item data in IFP. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#transition-process) Transition Process * Properties moved to fragments will be marked as `_DEPRECATED`. Transition code will automatically transfer settings when objects load. This code can be found in the **PostLoad** function. So remember, this will only be executed when the object is loaded. So for assets, make sure to open them to fully make sure they got loaded, and for all actors in your level, look at their inventory component to make sure everything executed correctly. * Item assets for some reason would have their data wiped if renamed with `_DEPRECATED`. So Tags and TagValues inside the data asset aren't labelled as deperecated, but should be treated as such. * Backup projects during migration. Deprecated properties and transition code will be removed in **6 months**, so update before then to avoid losing settings. I will ping everyone on Discord before this code is removed to remind everyone. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#future-proofing) Future Proofing Fragments offer modular customization, enabling unique item and container configurations without altering the base plugin. Examples: * Extend the compatibility settings system into an item fragment, allowing all its containers to use those settings instead of—or in combination with—their own * Creating a “Container template” fragment that links to a data asset with pre-defined settings, allowing you to make global changes to many containers across different actors and items throughout the game in one place. * Adding "Socket Fragments" to store item references near sockets. Fragments make IFP more flexible, scalable, and prepared for evolving project needs. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#items) Items -------------------------------------------------------------------------------------------------------------- * The item struct now stores a soft reference to the item asset and the regular hard reference has been hidden. The soft reference will automatically populate and reset the hard reference during the **PostLoad** event. Added a **LoadItemAssets** function to async load the assets, but if they aren't loaded when **StartComponent** is called, then they will be loaded instantly. Important API change: This means that the **ItemAsset** variable is null before **StartComponent** or **LoadItemAssets** is called and whenever you are creating a item struct through the `Make S_InventoryItem` node, you should fill in the soft reference. * The item struct header has been customized to show an icon of the item asset inside of it. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#fragments-1) Fragments ------------------------------------------------------------------------------------------------------------------------ * New default items fragment allows you to safely add default items to an items container. This is recursive. * I highly suggest using the `DefaultItems` fragment rather than `ItemsContainers` fragment and to stop using the **BelongsToItem** variable. Code comment explains why this fragment is safe. * Tile tags can now be optimized for the game thread. It does this by filling in the empty spaces so the array is 1:1 with the tile map, which makes getting a tag for a tile be searchable in constant time rather than linear time [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#bug-fixes) Bug fixes ---------------------------------------------------------------------------------------------------------------------- * GAS effects would only be activated if the tag event also had an attribute associated with it. [Previous3.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1) [Next2.11](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11) Last updated 5 months ago * [Fragments](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#fragments) * [Why?](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#why) * [Key Benefits](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#key-benefits) * [Transition Process](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#transition-process) * [Future Proofing](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#future-proofing) * [Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#items) * [Fragments](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#fragments-1) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0#bug-fixes) --- # 1.1.1 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1.md) . Engine support: 5.1 and 5.2 [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1#improvements) Improvements ------------------------------------------------------------------------------------------------------------------------------ * Preview actor now destroys its own collider actor when itself is destroyed. * Refreshing the preview actor is now faster. * General code cleanup and unused variables have been removed. * Items can now be labelled as "new". This label can be removed at any point. This can help players find out what is new in their inventory and they haven't interacted with yet. * Items that do not have their containers added to the ContainerSettings array will now retrieve their default containers from the data asset and add those to the component when it is started. * A [tag system](https://inventoryframework.github.io/workinginthesystem/tagsystem/) has been added, allowing you to add tags to items and containers, and also associated values to certain tags. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1#tools) Tools ---------------------------------------------------------------------------------------------------------------- * New tool as been added, the [ItemEditor](https://inventoryframework.github.io/tools/itemeditor/) . * Added function library for editor tools. * Common data base widget added so it is easy and fast to add your item data base to any editor tool. * It is now possible to generate item icons while in the editor. * Improved multiple widgets behavior and accessability while in the editor. * Added a tool for previewing how an item widget will appear in-game while in the editor. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1#bug-fixes) Bug fixes ------------------------------------------------------------------------------------------------------------------------ * Refreshing the preview actor no longer breaks on shipping build for some actors. * Preview actor no longer 1-frame snaps or resets visual effects when refreshed. It now resolves what components have and have not been duplicated and only updates those. * Fixed an issue where item rarity colors were not working while in the editor. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1#id-1.1.1) 1.1.1 ------------------------------------------------------------------------------------------------------------------- Note: This is 5.2 only. Apparently Epic decided after manually reviewing the 5.1 version within 7 minutes said "There were no notable differences" so they just won't accept it... * Autonomous Proxies on listen no longer is breaking replication. * When an item was dropped, the containers belonging to any children item were not being removed properly. [Previous1.2.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0) [Next1.0.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.0.0) * [Improvements](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1#improvements) * [Tools](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1#tools) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1#bug-fixes) * [1.1.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1#id-1.1.1) --- # 2.7.1 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1.md) . Engine support: 5.3 and 5.4 This update might cause a few compile errors for those updating, the interaction interface has been split into two and some functions have been removed. Greatly simplifying the process of implementing a custom interaction system. On top of that, the tile and item widgets have been updated, drastically improving their performance. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#inventory) Inventory ------------------------------------------------------------------------------------------------------------------------ * **GetFirstAvailableTile** is now on average 6-12 times faster in large containers. This has significantly sped up item sorting and **StartComponent** in scenarios where containers have random tiles assigned to items, so for save files or items with assigned tiles, this won't have an impact. * Added **TryAddNewItemByDataAsset** function. * Added **CheckForSpaceForShape** function. * Added **GetOwningItemForContainer** function. * Added **DoesContainerBelongToComponentOwner** function. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#widgets) Widgets -------------------------------------------------------------------------------------------------------------------- * **W\_Tile** -> **ParentContainer** is now exposed on spawn. **WBP\_InventoryItem** -> **GetSize** and **GetDimensions** have been deprecated. A lot of performance improvements have been made: * **WBP\_DemoInventoryItem** has been optimized. If no custom shape object is found, it'll just spawn one background tile and stretch it across the items size. * Drawing the custom shape for custom shaped grid items is now twice as fast. * The demo tile construction time has been reduced from 0.034ms on average to 0.013ms on average, drastically reducing the hitch from opening a very large container. * Several improvements to a handful of functions and widget hierarchies have been improved and drastically reduced the spike when opening the inventory for the first time. * The `SizeBox` requirement has been removed from **W\_Tile**. Documentation has been updated. * Demo widgets have been updated to no longer use a `SizeBox`. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#interfaces) Interfaces -------------------------------------------------------------------------------------------------------------------------- * **BPI\_Interaction** has been split in two and some functions removed. Added new interface **BPI\_IFP\_Helpers** to simplify custom interaction system implementations. Documentation updated. * **BPI\_Interaction** has been moved into the demo folder to help make it clear that it is an example interaction system. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#bugs) Bugs -------------------------------------------------------------------------------------------------------------- * Highlight widget was broken on Infinite grids * **W\_Tile** was causing crashes in some scenarios * Moving an item as a client would cause the item widget variable to go null * Infinite grids wouldn't resize in some scenarios. * **CanSwapLocations** could cause a crash for clients and would give false positives in some scenarios. * **IsTileValid** would report false positives in some scenarios for infinite containers. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#id-2.7.1-bug-fixes-5.4-only) 2.7.1 bug fixes (5.4 only) ----------------------------------------------------------------------------------------------------------------------------------------------------------- All of these fixes are very small and can easily be manually implemented. Reference the `bug-fixes` channel on the discord posts between 27th March - 15th April * **GetItemDriver** was not returning the correct driver. * **TryAddNewItem** Could fail in some scenarios. * The item data in the quick loot window could become stale in some scenarios, causing the **MoveItem** to fail. * Item icons could squish when re-opening the inventory. * When revealing hidden equipment, the equipment events were being called with the wrong data. * Splitting an item would cause the original item widget to behave as if it was item 0 in its container. * **DataObject** for drivers was not replicated. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#color-sheet) Color Sheet: ----------------------------------------------------------------------------------------------------------------------------- **functions** - **variable** - **category** - **class** [Previous2.8.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1) [Next2.6.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#inventory) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#widgets) * [Interfaces](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#interfaces) * [Bugs](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#bugs) * [2.7.1 bug fixes (5.4 only)](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#id-2.7.1-bug-fixes-5.4-only) * [Color Sheet:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1#color-sheet) --- # 1.2.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0.md) . [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#id-1.2.0) 1.2.0 ------------------------------------------------------------------------------------------------------------------- Engine support: 5.2 [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#important-for-those-updating) Important for those updating: --------------------------------------------------------------------------------------------------------------------------------------------------------------- Because both the container struct and item struct were modified in this update, it means that a lot of blueprints were updated and might override any chances you might have made. Remember to backup your version before installing. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#component) Component * **FindFirstAvailableContainerAndTile** and **FindFirstAvailableTile** have been replaced with **GetFirstAvailableContainerAndTile** and **GetFirstAvailableTile**. These functions can now also be overriden at a blueprint level to allow designers to implement their own rules of how the system finds available containers and tiles. * **CheckForSpace** and **CheckBothRotationsForSpace** has been updated to return an array of items that were in the way instead of just the first item. * Added function for checking if items can be swapped and another function for swapping 2 item locations. * Added **UpdateItemsOverrideSettings** so override settings can be updated in a live multiplayer session. Another function called **CanActorChangeItemOverrideSettings** has been added and it will ask the server if an actor is allowed to modify an items override settings. By default, this is set to always return true. You can override this function at a blueprint level. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#items) Items * Default item tags have been implemented. These are defined in the item data asset, whenever a component is started and an item does not have any of the tags from the data asset, they will automatically be applied. * **ContainerName** has been labelled as deprecated and will be replaced with **ContainerIdentifier** tag, making it easier for renaming a container and reduces human error when binding containers with their widget representation. * During 1.2 both the **ContainerName** will continue to work for most functions, as most have been updated to use **ContainerIdentifier** instead, but **ContainerName** will be fully removed in the next update. It's recommended to update your containers immediately. * The physical actor for an item no longer requires any containers to be setup inside the blueprint. When the component is started, it'll automatically add the default containers from the data asset. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#item-drivers) Item drivers * Item drivers now have the option to "follow" the item they were created by. This means that if a driver is created for an item and the item is moved to a new actor, that driver is moved as well to the new actor. The driver is not destroyed and reconstructed, it will retain all information and continue running any timer logic. * Drivers are now referenced by the item struct, giving easy access to access an items item driver. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#widgets) Widgets * The update functions inside of **W\_InventoryItem** have been labelled as deprecated. * New **I\_WidgetUpdates** interface added, contains all the update functions that were deprecated in **W\_InventoryItem** * During 1.2 both the deprecated functions and the interface events will be called, but the update functions inside of **W\_InventoryItem** will be fully removed in the next update. * Item struct and container struct now has an array of "**External Widgets**", making it easier to manage hotbars, quest trackers and any other widget that is listening to any item updates without listening to a bunch of delegates. Documentation can be found [here](https://inventoryframework.github.io/workinginthesystem/externalwidgets/) * External widgets get all the same Update functions that the item widget and container widget does from the **I\_WidgetUpdates** interface. * More update functions have been added for tags, tag values and equip/unequip events. * Add, Remove and Get External Widgets helper functions for both items and containers have been added. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#example-project) Example Project * Added two quick slot example, one for global tracking where a specific item asset is tracked across the entire inventory, and another for a specific slot. * In the context menu, the Equip and Unequip buttons now actually... You know... Equips and unequips the item... * Example project has been updated to no longer use any of the deprecated features. * Gameplay tags have been moved to a data table. * The tooltip widget has been updated to use the external widget system to provide a simple example of the new external widget system. * Objects now have a better display name. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#bug-fixes) Bug fixes * When splitting an item, the newly created item widget would get created in the incorrect location. * When trying to move an item on the same slot but with a new rotation, it would not update the rotation. * Generated item icon were being stretched in certain scenarios. * Item count was getting reset to default if it was dropped. * Random min/max count could be called multiple times. * The item and container tag delegates are no longer getting spammed. * GetItemDimensions could sometimes return wrong values * Set/Remove tag value and IncreaseItemCount wasn't using the new replication system. [Previous2.0.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1) [Next1.1.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1) * [1.2.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#id-1.2.0) * [Important for those updating:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#important-for-those-updating) * [Component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#component) * [Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#items) * [Item drivers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#item-drivers) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#widgets) * [Example Project](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#example-project) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0#bug-fixes) --- # 2.1.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0.md) . Engine support: 5.2 and 5.3 * * * This update focuses on improving developer tools, improving workflow, losening restrictions around item hierarchy and example project updates. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#item-actor) Item actor -------------------------------------------------------------------------------------------------------------------------- * The hierarchy around **A\_ItemPhysicalRepresentation** and **BP\_SM\_ItemPhysical** has been improved. The inventory component is now added in C++. This does mean **BP\_SM\_ItemPhysical** has 2 inventory components for this update. One is labelled deprecated, and you will have to start moving your component settings, such as the **InventoryType**, **ContainerSettings** and **WidgetClass** over to the new one. A button has been added to the actor which will copy over the settings from the deprecated component to the new one. These changes make the blueprint child much more optional and leaves only a few delegates you'll want to setup in any custom children. * Added **StartInventoryOnBeginPlay** variable as now the inventory component is started inside C++, this will let blueprint designers disable **StartComponent** on **BeginPlay** in case they want to customize when it's called. * **RootItemID** is now replicated. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#inventory-component) Inventory component -------------------------------------------------------------------------------------------------------------------------------------------- * Added a tag system to the inventory component, though these tags are always replicated and use the default replication system, they do not use the custom replication system the other tag systems use. * Added a quick loot widget, which lets you preview items inside of a component before looting it or opening it, then letting you select and loot specific items without picking up the item or opening it. * Improved how containers are replicated and reduced RPC calls. * ItemMoved delegate has been update to provide both the old and new item data * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#tag-system) Tag system -------------------------------------------------------------------------------------------------------------------------- * A new tag value calculation class has been added (**O\_TagValueCalculation**). These classes can be passed into **SetTagValue** for both items and containers and it'll allow you to have one place to adjust any values based on some relationship a tag might have with another tag. For example, a durability tag might need to be clamped to a max durability tag. Instead of pre-clamping **SetTagValue** parameter everywhere inside your code, you now have one spot to perform these adjustments. An example can be found in the example project inside Blueprints -> TagCalculations -> **TVC\_DurabilityCalculation** * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#preview-system) Preview system ---------------------------------------------------------------------------------------------------------------------------------- * Relative location and rotation for the camera has been reworked slightly to resolve some issues. The spring arm location is now applied to the scene capture component instead of the spring arm. * Saving an icon during runtime seems to no longer be supported in 5.2 by Epic, the button is now automatically removed while in-game. You can still save an icon inside the ItemEditor tool. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#editor-tools) Editor tools ------------------------------------------------------------------------------------------------------------------------------ * General UI language has been updated and will continue being updated to feel more like it comes straight out of the box as a Unreal Engine tool, instead of looking like a custom tool with my own personal UI language. * Inspect debug widget has received a major revamp, is now more clear, less clutter, and less buggy. * You can now pan the preview actor around by using the right mouse button. * Item Widget preview has been updated to let you select a tile widget to use as a background and added controls to help with sizing the widget to accurate numbers instead of the scale slider. * The item editor's resizing for the filters and toolbox has been reworked to clear up a collision issue that was happening with sliders. * You can now shift + right click on a asset icon inside the asset library to open the items actor blueprint (If available). * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#equipment-system) Equipment System -------------------------------------------------------------------------------------------------------------------------------------- * Tags can be added and removed when driver starts, ends or on specific montage notifies. The example project uses this on the gun to enable/disable firing at specific points. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#bug-fixes) Bug fixes ------------------------------------------------------------------------------------------------------------------------ * InventoryHelper would not scale correctly when the editor scaling was not set to 1 * **MoveItem** could cause crashes in some scenarios where multiple clients were interacting with the same component. * **CheckAllRotations** was missing UFUNCTION specifier * Sorting items in a list container was not behaving correctly. * Items belonging to a vendor could be dropped without performing any transaction. * TagValueUpdated interface call was not working correctly. * Moving an item into an infinite container could break if the container had to expand to accommodate the item. * **GetAllContainersAssociatedWithItem** could break if an item contained another item that had a container. [Previous2.2.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0) [Next2.0.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1) * [Item actor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#item-actor) * [Inventory component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#inventory-component) * [Tag system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#tag-system) * [Preview system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#preview-system) * [Editor tools](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#editor-tools) * [Equipment System](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#equipment-system) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0#bug-fixes) --- # 2.8.1 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1.md) . Engine support: 5.4 The "Need for Speed" edition This is one of the biggest updates since 2.0 and was on the border of becoming version 3.0. This update changes a good chunk of behaviour under the hood and brings lots of optimizations. `IFP` is already extremely fast and is probably the fastest and most feature-rich inventory system on the marketplace, but that doesn't mean there isn't room for improvements. Highlights: * Added **ItemStructObject**'s, which are a brand new way of handling gameplay logic for items. This is one of the biggest and most exciting features added to `IFP` since release. * Improved editor workflow. * Several performance improvements. * Updated documentation. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#items) Items ---------------------------------------------------------------------------------------------------------------- * Added **ItemStructObject**'s, which are a brand new way of handling gameplay logic for items. [Documentation](https://inventoryframework.github.io/classes-and-settings/da_coreitem/) has been added * You can now drag the item data asset into the viewport to place the item actor. This is also possible by clicking and dragging the asset icon in the `ItemEditor` tool. * The `VerifyData` button has been removed. The logic has been moved into the `IsDataValid` function, which is ran whenever an asset is saved. * Added buttons for opening the item actor and item struct object. * Item assets thumbnails in the content browser and drop down windows now use their inventory image or the developer image as the thumbnail image. * Added **ItemType** tag to items to simplify the item type logic for items. * Shape is now baked into the data asset, greatly improving the performance of several functions that relied on the items shape. * **GetItemDescription** will now replace any text that includes "< Tag value name >" with the value of that tag value. For example; "Current Durability: " will be changed to Current Durability: 20" if the tag value was 20. The apple, helmet and gun items uses this for an example. You can also style your floats with the new `Rich Text Wrapper` parameter. (Read code comment for more info) * Items can now have sockets, just like a static mesh or a skeletal mesh. This is achieved through the socket manager object on the item asset and can be edited through the `ItemEditor` toolbox. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#inventory) Inventory ------------------------------------------------------------------------------------------------------------------------ * When replicating containers to clients, server now clears the tile map when sending the RPC and has clients regenerate it when it reaches them, resulting in an average 20% smaller RPC sizes. * A new **ID\_Map** system has been added. This allows the system to find ANY container or item in constant time, meaning it takes the same amount of time to find a container or item in index 0 as it takes to find a container or item at index 1000. This also means that **GetItemByUniqueID** has been reworked and is virtually free and this has had a tremendous performance improvement for projects with hundreds of containers or items in one inventory component. * A new **IndexCoordinates** system has been added, allowing the system to instantly convert a tile into an index. This wasn't expensive, but the system used this convertion so much, the small cost started to pile up. * **GetFirstAvailableTile** is no longer blueprint overridable. * The inventory component now has a custom icon. * Added **GetItemCount** function. * Added **GetItemsByType** function. * Added **GetItemsParentContainer** function. * Added a **DoNotBind** parameter to **CreateAttachmentWidgetForItem** so it's easier for people to do custom bindings. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#interfaces) Interfaces -------------------------------------------------------------------------------------------------------------------------- * The **I\_WidgetUpdates** interface has been renamed to **I\_ExternalObjects**. The \`ExternalWidgets system has also been reworked to not be limited to just widgets. * Many of the functions inside of **I\_WidgetUpdates** have been reworked to expose more parameters and have better categories. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#tools) Tools ---------------------------------------------------------------------------------------------------------------- * The `ItemEditor` tool has had a layout make-over. * The `ItemInspector` tool has been disabled for runtime. Should only be used in the `ItemEditor` from now on. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#preview-actor) Preview Actor -------------------------------------------------------------------------------------------------------------------------------- * The collider actor has been removed. This actor was a overkill solution to a rare bug. This has also improved the garbage collector performance. * Added a new option to skip the cloning process. If enabled, it'll just attach itself to the owner. This has almost doubled its performance. * All actors spawned by the preview actor now get labeled as one with the new **I\_Inventory** -> **SetIsPreviewActor** function. You can then use the **I\_Inventory** -> **IsPreviewActor** to find out if that actor instance is a part of the preview actor system or not. * Preview actor now supports leader poses. Documentation has been updated. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#documentation) Documentation -------------------------------------------------------------------------------------------------------------------------------- * `DA_CoreItem` has been updated. * A new `Optimizations` page has been added. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#bugs) Bugs -------------------------------------------------------------------------------------------------------------- * Default items declared in the item data asset containers would fail to spawn. * Item struct in item data asset containers would say "No Item Available" * Widget factories were using the wrong blueprint type. * Crash if invalid data was passed into **GetItemsTagValues** * Generated item icons would go into the wrong folder. * Clicking on a specific spot on non-custom shaped items did not treat that spot as the anchor point. ### [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#id-2.8.1) 2.8.1 * Disabled struct object creation on preview actor instances. Bug fixes: * Clients item data would not include the item struct object in some scenarios. * Moving an item via double click could cause item duplication. * Dropped items would not have their containers setup correctly, which would also cause those containers to get lost when picking up a dropped item. * The stack variables inside the data asset would get hidden if max stack was set to 1. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#color-sheet) Color Sheet: ----------------------------------------------------------------------------------------------------------------------------- **functions** - **variable** - **category** - **class** [Previous2.9.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0) [Next2.7.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1) * [Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#items) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#inventory) * [Interfaces](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#interfaces) * [Tools](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#tools) * [Preview Actor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#preview-actor) * [Documentation](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#documentation) * [Bugs](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#bugs) * [2.8.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#id-2.8.1) * [Color Sheet:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1#color-sheet) --- # 2.0.1 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1.md) . Engine support: 5.2 * * * !!!Important Many files have received a large rework/updates and it's not possible to downgrade safely to 1.2. Remember to make backups of your project if you are updating from an older version. Here is a list of files that have received major changes: Blueprints: * BP\_AC\_Inventory * WBP\_DemoInventoryItem * WBP\_Drag * WBP\_Highlight * EUW\_InventoryHelper * WBP\_ItemWidgetPreview C++: * AC\_Inventory * DA\_CoreItem * FL\_InventoryFramework !!! * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#highlights) Highlights -------------------------------------------------------------------------------------------------------------------------- * Custom shaped items. * Rotations support for 180 and 270 degrees added. * QA validation system for data assets. * Increased focus on Objects for item data. * Improvements to how item and container widgets are referenced. * Mutlithreaded sorting function * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#items) Items ---------------------------------------------------------------------------------------------------------------- * A [validation system](https://inventoryframework.github.io/classes-and-settings/da_coreitem/#asset-verification) has been added to the data asset to help with QA. * This is achieved through a validation class (so you can write your validation at a blueprint level) and a interface function from **I\_Validation**. The plugin comes with a basic example. * Items can now be rotated 0, 90, 180 and 270 degrees. * The function **CheckBothRotationsForSpace** has been deprecated because the name does not make sense anymore. Has been replaced with **CheckAllRotationsForSpace** * Items now support [custom shapes](https://inventoryframework.github.io/classes-and-settings/da_coreitem/#custom-shapes) . This can be enabled by adding the "Custom Shape" object to an items data asset. * Helper functions for rotating and evaluating an items shape have been added. * Added **GetNearbyItems** function. * The following enums have been deprecated and replaced with the items tags: * Item rarity * Equipment slot * Equipment type * Weapon type * Attachment type This change has a host of benefits. It is one less reason to install locally, easier to expand, manage and more. This also has the benefit of allowing all of these to be easily overridable during runtime. This also means **CompatibilitySettings** and **CheckCompatibility** has been updated. **CheckCompatibility** will no longer check the deprecated enums to reduce confusion for new people. * The following variables have been deprecated and replaced with objects: * Price and Default Accepted Currencies moved to **IO\_Pricing** * The first multithreaded sorting function has been added. For now I'm starting with just sorting by name to find out if the current approach works. If the current approach works, I'll start working on more sorting functions and hopefully make a tutorial on how to make your own custom sorting function. * Added **AssetTags** and **AssetTagValues** to the data asset. These are similar to the default tags, except they are NOT added to the item struct and can not be modified, removed or added during runtime. * When an item is equipped and using a blueprint actor as it's physical representation, the root items **UniqueID** is now passed to the actor and stored inside **RootItemID**, allowing the spawned actor to access it's true item data. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#tag-system) Tag system -------------------------------------------------------------------------------------------------------------------------- * Various functions have been added to validate if a tag and tag values can or can not be added, removed or set for both items and containers. * The Tag value struct now has a custom editor slate widget to make it easier to work with and take up less space. * Note: As of 5.2, there's a bug with some custom structs and editor utility widgets not displaying the custom struct correctly. To get around this, I've made it so it displays the default struct widget while inside a editor utility widget. * **TileTags** have been added for containers to replace **HiddenSlots** and **LockedSlots**, which are now deprecated. This is a prototype, it currently can not be modified during runtime for multiplayer and there are no events for when a tag is removed or added. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#widgets) Widgets -------------------------------------------------------------------------------------------------------------------- * Both the drag and highlight widget have been updated to behave more intuitively with custom shaped items. This also means both have been reworked quite heavily. For non-grid containers, the behavior should remain the same as before. * The drag and drop operation no longer has a visual and **WBP\_Drag** is now added to the screen (You might have to set the ZOrder). This is to resolve a interpoloation issue you could not control inside the drag and drop operation drag visual and improve the consistency of **WBP\_Drag**. * Attachment widgets no longer need a reference to the parent items widget. * Attachment widgets now remove themselves correctly from the parent item when it is destroyed. * Both the item struct and container struct now reference the item widget and container widget respectively. * **AC\_Inventory** -> **ContainerWidgets** has been deprecated as the container struct now references the container widgets. Added **GetAllContainerWidgets** and **RemoveAllContainerWidgets** to replace the array. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#objects-and-drivers) Objects and drivers -------------------------------------------------------------------------------------------------------------------------------------------- * Objects have had their hierarchy changed. There is now a "pure" (**O\_PureItemObject**) item object below the regular item object, which is now meant for data only objects. This is to optimize memory footprint as the framework becomes more focused on objects and for projects that are heavily utilizing the object system. * **ConstructionMethod** is getting deprecated. You should reparent your data-only objects to **O\_PureItemObject**. * Objects can now prevent multiple copies of themselves inside an item assets **ObjectsAndDrivers** array. By default this is set to false, to change it you must override the **AllowMultipleCopiesInDataAsset** function. * Objects now get notified when they are added to the item assets array with **AddedToItemAsset**. Allowing for more complicated default variables. * Added object for pricing (**IO\_Pricing**). * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#tools) Tools ---------------------------------------------------------------------------------------------------------------- * A shape editor has been added to the **ItemEditor**'s toolbox. * A conversion tool has been added to help convert the deprecated enums listed above into gameplay tags and move some deprecated variables into their new objects. This tool will be removed in 2.1 and is only meant to help those upgrading from 1.2 to 2.0. * Container handle bar context menu has been removed from the inventory helper. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#bug-fixes) Bug fixes ------------------------------------------------------------------------------------------------------------------------ * When removing an item as listen server, it would attempt to remove the item twice. * Attachment widgets were not being removed correctly in some scenarios. * **GetItemDriver** was not returning client-only objects for single player sessions. * Skeletal mesh equipment animations could end up in an infinite loop if they contained a MontageNotify with the same name as their WaitForNotify. * Equipment system for clients would try to play an animation on skeletal meshes with WaitForNotify and then create it, causing the animation to not play as the mesh had not been replicated yet. * Updating the unequip location for static and skeletal meshes was not functioning correctly. * **CheckCompatibility** would not take the items default tags and tag values into consideration while in the editor. * Increase and Decrease item count could crash if invalid item data was passed in. * **TryAddNewItem** could cause issues with **CheckCompatibility** [Previous2.1.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0) [Next1.2.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0) * [Highlights](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#highlights) * [Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#items) * [Tag system](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#tag-system) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#widgets) * [Objects and drivers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#objects-and-drivers) * [Tools](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#tools) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1#bug-fixes) --- # Versions | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions.md) . [3.4](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4) [3.3.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1) [3.2.2](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2) [3.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1) [3.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0) [2.11](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11) [2.10.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1) [2.9.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0) [2.8.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1) [2.7.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1) [2.6.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0) [2.5.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1) [2.4.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0) [2.3.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0) [2.2.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0) [2.1.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0) [2.0.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1) [1.2.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0) [1.1.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1) [1.0.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.0.0) [PreviousItem Editor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor) [Next3.4](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4) --- # 1.0.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.0.0.md) . Engine support: 5.1 * Official release [Previous1.1.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1) [NextF.A.Q](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q) --- # 3.4 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4.md) . [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#inventory) Inventory ---------------------------------------------------------------------------------------------------------------------- * **TryAddNewItem** has been updated to better utilize recent updates reworks and new features and should be more consistent and in-line with new `IFP` features. It's also far more server-authoritative now, nearly all processing is done on the server, reducing game thread time on clients. * Many deprecated properties have now been removed. Most notably deprecated data inside **FS\_ContainerSettings**, **FS\_InventoryItem** and **DA\_CoreItem** * The **Count** parameter is now a slider. It checks the items max count to clamp the sliders max value, making it far easier for designers who didn't design the item understand what the max count is, without opening the item asset. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#vendors) Vendors ------------------------------------------------------------------------------------------------------------------ The logic around vendors and currency exchange has been slightly rehauled and many old bugs and issues have been resolved. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#omnitoolbox-support) OmniToolbox support ------------------------------------------------------------------------------------------------------------------------------------------ * Many assets now have a "Documentation" button near the save or compile button that helps direct users to the documentation for that specific asset. * Traits can add to this list ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252Fyv2xD4noLH3hCbtGz7Fv%252Fimage.png%3Falt%3Dmedia%26token%3Da5e5cea1-e351-4700-b80e-06c208f7ff9d&width=768&dpr=3&quality=100&sign=effa05bb&sv=2) [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#tooltip) Tooltip ------------------------------------------------------------------------------------------------------------------ * There's now a C++ parent for the tooltip widget. **WBP\_Tooltip** has been reparented to **W\_Tooltip** * Added a new console variable to enable and disable the tooltips debug mode. Documentation has been updated. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#bug-fixes) Bug fixes ---------------------------------------------------------------------------------------------------------------------- * SplitItem's return value for Item1RemainingCount was incorrect. In some cases, Item2RemainingCount could also be incorrect. * **CanSplitItem** was not treating containers with no tile map the same way as other functions were * Compile errors for Mac and certain Linux compilers around TInstancedStruct should now be resolved * Fixed an issue where gamepad navigation had stopped working for 5.7 [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#color-sheet) Color Sheet: --------------------------------------------------------------------------------------------------------------------------- **functions** - **variable** \- **category** \- **class** [PreviousVersions](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions) [Next3.3.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1) Last updated 1 month ago * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#inventory) * [Vendors](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#vendors) * [OmniToolbox support](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#omnitoolbox-support) * [Tooltip](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#tooltip) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#bug-fixes) * [Color Sheet:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4#color-sheet) --- # 2.4.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0.md) . Engine support: 5.3 * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0#example-project) Example Project ------------------------------------------------------------------------------------------------------------------------------------ * The UI styling has been reworked. * Added example for tracking tag values on equipped items, such as an armor stat. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0#widgets) Widgets -------------------------------------------------------------------------------------------------------------------- * Custom shaped items can now have padding and rounded corners. An object has been added that stores all the information for each item to save on performance. * Container widgets can now override their tiles default brush settings. * Added a **GenerateItemIcon** macro (Only available to widgets) [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0#crafting) Crafting ---------------------------------------------------------------------------------------------------------------------- A crafting system has been added. It is important to note that the crafting system has been designed to be 100% removable and the inventory system has zero reliance on it. If you do not want a crafting system and want to reduce the size of your packaged game and/or don't want to deal with the bloat, the system has been contained within a separate folder. If you are updating your project and want to use the crafting system, you will want to go into your project settings -> Asset Manager and add a new index and set "Primary Asset Type" to "CraftingRecipes", set the asset base class to **DA\_CoreCraftingRecipe**, then go into Directories and add all locations where you might store your recipe's. [**Documentation for the crafting system**](https://inventoryframework.github.io/crafting/) * Added crafting category to the content browser context menu [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0#bugs) Bugs -------------------------------------------------------------------------------------------------------------- * An item actor would not destroy itself if it had to stack with another item when looted through the quick loot options. * **TryAddNewItem** would not apply the correct rotation in some scenarios. * The ItemAdded delegate would not have the most up to date version of the item struct. * When dropping an item, you could get spammed with "UObject is data-only. No item driver available." * **GetItemDriver** was using the wrong object class for its object paramater. * the **SellItem** function helper was not setup correctly, leading to clients not being able to use it. * Added a temporary solution to icon generation crashing the engine. If you are still crashing, you'll want to increase the delay inside **WBP\_InspectDebug** [Previous2.5.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1) [Next2.3.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0) * [Example Project](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0#example-project) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0#widgets) * [Crafting](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0#crafting) * [Bugs](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0#bugs) --- # 2.10.1 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1.md) . Engine support: 5.4 > The documentation has a new category - `Systems` - Some documentation has been moved and some has been added to this category. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#item-query) Item Query --------------------------------------------------------------------------------------------------------------------------- * Added a new multithreaded `ItemQuery` system, documentation can be found [**here**](https://inventoryframework.github.io/systems/itemquery/) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#inventory) Inventory ------------------------------------------------------------------------------------------------------------------------- * Added native container UI navigation support, for example using a controller to navigate around a container. Documentation can be found [**here**](https://inventoryframework.github.io/systems/uinavigation/) * Item widgets can now have a custom drag and drop system to help with gamepad navigation. `Drag and Drop` documentation has been updated. * Inventory component now has a reference to the drag widget to help evaluate whether the player is currently dragging an item and retrieving that item. * Many **GetParentCompoent** functions have been renamed to **GetInventory** * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#gas) GAS ------------------------------------------------------------------------------------------------------------- * Native `GAS` integration has been added through a new module. Documentation can be found [**here**](https://inventoryframework.github.io/systems/AbilitySystem/) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#drivers) Drivers --------------------------------------------------------------------------------------------------------------------- * Drivers now have a payload parameter to pass custom data from clients to server. * Added a new "item ability" driver. Documentation can be found [**here**](https://inventoryframework.github.io/systems/AbilitySystem/#item-ability-driver) * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#crafting) Crafting ----------------------------------------------------------------------------------------------------------------------- * Added native support for "timed crafts". Documentation has been updated. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#bug-fixes) Bug fixes: -------------------------------------------------------------------------------------------------------------------------- * The Item actor would be destroyed if the player moves an item from its own inventory if the item was in container 0 and was item index 0 * The ItemDropped event was not being called. * ApplyTileOffset could go 1 tile out of bounds. * Item icons were not updating when unequipping items inside of them. * Splitting an item as a client on a different component would lead to the original items count not updating. * Reverted a bug fix from 2.9 where the equipment manager was not removing tags when unequipping an item to fix an issue where the items visuals were not being removed when an item was unequipped by moving the item to another inventory component, such as a chest * Item icons could stretch or shrink in some cases. * TryAddNewItem could cause a crash in some cases. * GetItemsVisual was not working for blueprint equipment on clients * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#id-2.10.1-bug-fixes) 2.10.1 Bug fixes: ------------------------------------------------------------------------------------------------------------------------------------------- * Items would not craft if they were missing the `TimeToCraft` recipe data. * Debugging code was being used in `LootItem` resulting in it not working as expected. * Unequipping a static mesh equipment would also unequip the parent actor it was attached to. [Previous2.11](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11) [Next2.9.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0) * [Item Query](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#item-query) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#inventory) * [GAS](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#gas) * [Drivers](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#drivers) * [Crafting](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#crafting) * [Bug fixes:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#bug-fixes) * [2.10.1 Bug fixes:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1#id-2.10.1-bug-fixes) --- # 2.5.1 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1.md) . Engine support: 5.3 * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#inventory) Inventory ------------------------------------------------------------------------------------------------------------------------ * Sorting has been slightly reworked and is much more reliable. The Async function is no longer deprecated. * Added **GetItemRef** macro for blueprints. * Added **GetItemsTags** and **GetItemsTagValues** helper functions. * Added **IsItemEquipped** helper function. * The deprecated inventory component has been removed from **BP\_ItemActor**. * **MeetsCurrencyCheck** now passes the buyer component, so designers can use external systems to use as currencies. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#widgets) Widgets -------------------------------------------------------------------------------------------------------------------- * Added the option to disable dragging on item widgets. * Improved how container widget variable is set. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#equipment) Equipment ------------------------------------------------------------------------------------------------------------------------ * When an item is equipped, two interface events will be called on either the player or the spawned blueprint, depending on the settings. The equipment documentation page has been updated to include a new "Events" section. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#bugs) Bugs -------------------------------------------------------------------------------------------------------------- * Item widget would spam errors if a craft widget had to generate an item icon. * Dragging an item widget with no hosting container widget could crash the engine. * **CheckCompatibility** was not checking asset tags and tag values. * Data base search was not checking asset tags and tag values. * Looting a stackable item as a client could cause a crash. * The Preview Actor was not resetting master pose reference on skeletal meshes. * **GetNearbyItemsDirectional** was wrapping to the next line if the scan went to the border of a container. * **GetFirstAvailableTile** could return invalid rotation enum * Context menu was showing the Drop and Destroy option on items they did not have authority over. * Listen Server could no longer interact with chests. * ItemUnequipped delegate was firing off after the item had been removed from the inventory, leading to some functions not being usable after the delegate. * Moving items around in some orders could cause the incorrect item data to be removed. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#color-sheet) Color Sheet: ----------------------------------------------------------------------------------------------------------------------------- **functions** - **Variable** - **category** - **class** [Previous2.6.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0) [Next2.4.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#inventory) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#widgets) * [Equipment](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#equipment) * [Bugs](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#bugs) * [Color Sheet:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1#color-sheet) --- # 3.3.1 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1.md) . [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#inventory-component) Inventory Component -------------------------------------------------------------------------------------------------------------------------------------------- * Count is now revealed if ShowCount is set to true. This is automatically set, but can be changed by fragments. The random count fragment shows an example of this. * A new template system has been introduced. [Documentation can be found here](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers) * Added a new **PreItemRemoved** delegate * Unique ID's are now global and never change when items move from one inventory to another. Once an item or container has received an ID, it will remain valid for as long as that item exists. * This is slightly experimental. The old system can be toggled through the runtime IFP project settings. * **StartComponent** now calls numerous virtual functions. This can help projects inject custom logic into the inventory initialization process. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#quality-of-life) Quality of Life ------------------------------------------------------------------------------------------------------------------------------------ * Many functions inside the item asset are now virtual. * The function library can now be overriden. Greatly improving a projects ability to override some of IFP's functionality without touching the source code. * Not all functions have been made virtual, but the most popular ones have been made virtual. More will be added when people ask for them. ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FUadVANfjQn5tfaksyh5a%252Fimage.png%3Falt%3Dmedia%26token%3D736b2ffe-7f2b-49f6-826c-d67727fbfc44&width=768&dpr=3&quality=100&sign=ced23905&sv=2) [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#editor) Editor ------------------------------------------------------------------------------------------------------------------ * The struct customization for containers and items have been improved and should now work no matter where the struct is, meaning the custom title and other utilities are no longer restricted to just the inventory component or some item assets. * The item count variable is now revealed when an item is stackable and has no random count fragment assigned. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#bug-fixes) Bug fixes ------------------------------------------------------------------------------------------------------------------------ * **GetItemsPrice** had a faulty if else statement leading to all items being worth 0 * **AdjustContainerSize** was miscalculating items TileIndex so items were moving to wrong places * **ItemMoved** was not returning the correct **ItemIndex** * Odd crash from containers tick event [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#id-3.3.1-fixes) 3.3.1 fixes ------------------------------------------------------------------------------------------------------------------------------- * **GetContainerSettingsForSpawningItem** was not wiping the item widget reference. * **GetItemsShapeWithContext** would unnecessarily validate the item, when it doesn't need to. This would cause **GetFirstAvailableContainerAndTile** to break only for grid containers * Item instances were getting their ItemID assigned in the editor, causing a crash when opening a context menu in the blueprint. [Previous3.4](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4) [Next3.2.2](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2) Last updated 8 months ago * [Inventory Component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#inventory-component) * [Quality of Life](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#quality-of-life) * [Editor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#editor) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#bug-fixes) * [3.3.1 fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1#id-3.3.1-fixes) --- # 3.2.2 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2.md) . Engine support: 5.5 and 5.6 [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#inventory-extensions) Inventory Extensions ---------------------------------------------------------------------------------------------------------------------------------------------- New system to simplify the creation of helper components, like the ones found in the example project. * [**Documentation**](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac_inventory#inventory-extension-components) for the inventory component has been updated [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#external-objects) External Objects -------------------------------------------------------------------------------------------------------------------------------------- * If any actor component on the inventory owner has the **I\_ExternalObject**'s interface, they will now receive these events. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#project-settings) Project Settings -------------------------------------------------------------------------------------------------------------------------------------- * `IFP`now includes 2 project settings; editor and runtime. * Runtime project settings will be slowly getting expanded to allow for tweaking `IFP`'s default behavior without changing source code, and providing some QoL features that the editor version could not. * Runtime project settings now allow you to remove specific fragments from the dropdown menu, allowing you to "disable" certain fragments for a project if the project has deemed a specific fragment should never be used. * Certain rotations can now be disabled through the project settings. This allows projects to go back to traditional 0-90 degree's without making their own or modifying the drag widget. * **GetLocalInventoryComponent** can now be altered from the runtime project settings to retrieve the inventory component from the player controller. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#fragments) Fragments ------------------------------------------------------------------------------------------------------------------------ Fragments dropdown menu's filtering is now more advanced. * For item asset fragments, it will hide all fragments that return false through **SupportsItemAsset** * Fragments can now opt out of the dropdown menu by overriding **DoNotShowInDropdown** and returning true. Useful for fragments that are only applied during runtime. * The **CompatibilitySettings** fragment has been slightly reworked, enabling far more customization. [**Documentation**](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings) has been added [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#inventory-component) Inventory Component -------------------------------------------------------------------------------------------------------------------------------------------- * Every function is now categorised under "Inventory Component" to help organize all the functions into one dropdown. * Improved support for the inventory component being used on the player controller. * The `ItemEquipped`delegate will now trigger on clients when they receive their container data. * The client RPC for **MoveItem** has been significantly reduced and scales far better. It now passes the **UniqueID** of the containers and the client is now responsible for resolving them on their end, rather than sending the full container settings struct through the RPC. * Added two new functions; **AddContainer** and **RemoveContainer**. * Added two new delegates for these functions; `ContainerAdded`and `ContainerRemvoed` [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#bug-fixes) Bug fixes ------------------------------------------------------------------------------------------------------------------------ * Fragments from the item assets **ItemStructFragments** were not being appended to item structs. * The item struct title was not being updated to match the overriden name, if one was assigned. * **GetItemsVisual** was not functioning correctly * Listeners were not being removed correctly * Item instances declared in the item struct with **ConstructOnRequest** set to true will not receive the **ItemID** * Adding a tag to a tile inside of a container that didn't have the tile tags fragment would cause a crash. * The drag widget would be massive for a few frames on some computers. * Rarity color sheet was not working on sub classes of the inventory component. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#id-3.2.1-bug-fixes) 3.2.1 Bug fixes --------------------------------------------------------------------------------------------------------------------------------------- * Changing an items shape through the shape editor would not properly call **BakeShapes**, leading to the shape not getting applied. * **BP\_Interactable** had not been updated to use the new **RemoveListener** function. [Previous3.3.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1) [Next3.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1) Last updated 1 year ago * [Inventory Extensions](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#inventory-extensions) * [External Objects](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#external-objects) * [Project Settings](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#project-settings) * [Fragments](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#fragments) * [Inventory Component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#inventory-component) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#bug-fixes) * [3.2.1 Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2#id-3.2.1-bug-fixes) --- # 2.3.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0.md) . Engine support: 5.3 * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0#quality-of-life) Quality of life ------------------------------------------------------------------------------------------------------------------------------------ * External widgets for both items and containers are now TObjectPtr, which means it is not mandatory to remove the widget from the array for it to be garbage collected. But this does mean the widget must be referenced somewhere in your game, such as being on the screen. Otherwise, it'll get garbage collected. * Added a "Inventory Framework" category to the content browser right click menu, allowing you to quickly create assets. * Most of the classes for the context menu have a blueprint class parent, which is generally not safe to reference in C++. Because of this, a "Inventory Framework" section has been added to Project Settings -> Plugins. This also means you can easily change what classes the content menu creates without touching C++. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0#inventory) Inventory ------------------------------------------------------------------------------------------------------------------------ * Added **GetTotalValueOfTag** function. * Added **GetNearbyItemsDirectional** function. * Added **GetAvailableEquipmentContainers** function. * Added **GetCompatibleEquipContainersForItem** function. * Added **CanItemBeDestroyed** function. * Added **HasAnyItems** function. * The item actor has been renamed to **A\_ItemActor**/**BP\_ItemActor** [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0#widgets) Widgets -------------------------------------------------------------------------------------------------------------------- * The **ContainerSettings** variable inside **W\_Container** has been renamed to **TemporaryContainerSettings** to reduce confusion around how to get the widgets true container settings. * **OwningItem** and **ParentTile** inside **W\_Tile** have been deprecated. Use **GetOwningItem** to retrieve the item widget. * The quick loot window will now show the root item. * Quick loot window will now automatically hide and show the expand option if the item can be expanded. * Context menu has been reworked into an item object. If no context menu object is found, then it'll default back to the old method which I won't be maintaining and an print string will pop up. * The InventoryHelper no longer automatically imports the items default containers. It will now import them when the item is opened instead of overriding the default containers by default. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0#bug-fixes) Bug fixes ------------------------------------------------------------------------------------------------------------------------ * Highlight widget could go out of bounds. * **TryAddNewItem** was not calling the equip dispatcher if it added an item to an equipment container. * The drop option in the context menu would never show up for equippable items. * DriverStarted delegate was assigned to the wrong delegate. * Vendors would delete any currency items that didn't have an acceptable currency. [Previous2.4.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0) [Next2.2.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0) * [Quality of life](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0#quality-of-life) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0#inventory) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0#widgets) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0#bug-fixes) --- # 2.6.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0.md) . Engine support: 5.3 This update focuses on code quality, deprecating unused properties and general performance. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#inventory) Inventory ------------------------------------------------------------------------------------------------------------------------ * Data-Only container style has been added. This container style is highly optimized by not handling collision, dimensions, capacity or anything of the sort. Allowing you to handle the styling of containers purely through widgets, or create a optimized space for hosting item data that the player shouldn't see, such as a hidden wallet. * Example widget has been added (**WBP\_DemoDataContainer** and **WBP\_DemoTileDataContainer**) * Added more helper functions: * **IsSpacialContainer** * **IsSpacialStyle** * **DoesContainerSupportTileMap** * FS\_InventoryItem -> **Item** has been renamed to FS\_InventoryItem -> **ItemAsset** * Added **GetLocalInventoryComponent** function to help those who want the inventory component to live on something other than the player pawn. * **GeneratedItemIcons** has been moved to the C++ component. * **OldItemData** has been removed from ItemEquipped delegate. * Added "Type" option for sorting items. * Containers **TileTags** can now be modified during runtime and replicate. [**Documentation**](https://inventoryframework.github.io/workinginthesystem/tiletags/) added. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#widgets) Widgets -------------------------------------------------------------------------------------------------------------------- * **W\_Tile** -> **ParentTile** has been removed. * **W\_Tile** -> **OwningItem** has been removed. * These two were forcing very heavy math and ForLoops, just to cache tiles that seemingly no one was using. As the codebase has improved, there are better ways of retrieving these values without caching them. * Deprecated **W\_Container** -> **Items** * Added **GetAllItemWidgets** to replace deprecated variable. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#crafting) Crafting ---------------------------------------------------------------------------------------------------------------------- * Added **GetRecipesRequiringItem** async function. * Added **GetRecipesForItem** async function. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#bugs) Bugs -------------------------------------------------------------------------------------------------------------- * **UniqueID** was not being assigned in some scenarios in **MoveItem**. * **InteractingWith** was visible in the details panel for the inventory component. * The item count while inside the **InventoryHelper** would not display correctly when both values were set to the same amount. * the cpp file for **A\_ItemActor** was not named correctly. * The InventoryHelper would treat the highlight in list containers as if it was a grid container, making moving items around difficult. * Items moved from a equipment container to a grid container would not have collision. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#color-sheet) Color Sheet: ----------------------------------------------------------------------------------------------------------------------------- **functions** - **variable** - **category** - **class** [Previous2.7.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1) [Next2.5.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#inventory) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#widgets) * [Crafting](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#crafting) * [Bugs](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#bugs) * [Color Sheet:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0#color-sheet) --- # 3.1 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1.md) . Engine support: 5.5 This update focuses on quality-of-life, debugging and IFP's presentation. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1#quality-of-life) Quality of life ---------------------------------------------------------------------------------------------------------------------------------- * All major classes related to IFP now have custom slate icons ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FTAG86hTNEUeHEjBxx4a9%252Fimage.png%3Falt%3Dmedia%26token%3D5ab22fca-f69d-435d-a6ec-6f9b1dc16410&width=768&dpr=3&quality=100&sign=1c8f8e4f&sv=2) * A one-time welcome popup now appears on engine startup to help direct new users to the documentation ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252F9cBhpUdROsNGJpurcWWH%252Fimage.png%3Falt%3Dmedia%26token%3D8cc1851f-8c1e-41aa-a2cb-e0454d0a6df8&width=768&dpr=3&quality=100&sign=c8453d78&sv=2) * Custom IFP log category has been added. To help with logging, most of IFP's **PrintString**'s has been replaced with a new function; **LogIFPMessage** ![](https://varian.gitbook.io/varian-docs/~gitbook/image?url=https%3A%2F%2F3072220171-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FD9UVtAB4Tl9vRkQgcS0X%252Fuploads%252FfHyRvFgyfDZN2Asm5T26%252Fimage.png%3Falt%3Dmedia%26token%3Dd05322f0-38c5-49f9-8642-b526dc80765c&width=768&dpr=3&quality=100&sign=4f7d2bdf&sv=2) * The **ItemFailedSpawn** delegate now gives a reason why it failed. It also logs the reason. * **LootItem** now lists failure reason and logs the reason. * When the item widget can not evaluate to any icon, it will print an error and assign a "Bad Blueprint" error texture to the widget to indicate something is wrong. * When saving an asset and it can't evaluate an icon, it will also alert you through the output log. * All properties inside the item asset are now `BlueprintReadWrite`. This is to help editor tools automate the creation of item assets. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1#inventory) Inventory ---------------------------------------------------------------------------------------------------------------------- * **LoadItemAssets** now has a callback for when all items have been loaded. * **UniqueID** can now be used in TMaps/TSets * You can now override the max stack on items through the new `MaxStackOverride`tag value. * Some arrays, such as the item components, external objects will now remove nullpointers and shrink themselves during garbage collection. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1#crafting) Crafting -------------------------------------------------------------------------------------------------------------------- * Timed crafts no longer use a timer, they use the tick event and keep track of the game time to decide when the craft should finish. * This is to allow crafts to occur while the game is paused. * Added **RD\_TimeToCraftBase**, which has a overridable function for getting the time it takes to craft a recipe. This provides more flexibility, for example creating a timed craft recipe data that returns a different value depending on the characters crafting skills. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1#bug-fixes) Bug fixes ---------------------------------------------------------------------------------------------------------------------- * **StartComponent** could in some cases not alert the client. * Item icons could shrink in some cases when equipping * **GetItemComponent** would in some cases add an item to the network queue, but not remove it. * Preview actors were causing external objects to receive irrelevant updates. * **MassReduceCount** could fail with non-stackable items. [Previous3.2.2](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2) [Next3.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0) Last updated 1 year ago * [Quality of life](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1#quality-of-life) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1#inventory) * [Crafting](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1#crafting) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1#bug-fixes) --- # 2.2.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0.md) . Engine support: 5.3 * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0#inventory) Inventory ------------------------------------------------------------------------------------------------------------------------ * Added tag values to component. * Security around **TryAddNewItem** has been loosened slightly to allow server RPC's to call the function for player controlled actors. Where as before the caller of the function had to be owned by the server. * The multithreaded **SortAndMoveItems** has been deprecated while a rework is explored. * **SplitItem** has been reworked slightly to fix some replication and collision issues. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0#example-project) Example Project ------------------------------------------------------------------------------------------------------------------------------------ * Added an example of how to have equipped items attachment widget automatically get added to inventory screen. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0#bug-fixes) Bug fixes ------------------------------------------------------------------------------------------------------------------------ * An items default tags weren't being applied in the correct order inside **StartComponent** if the item didn't have the tag inside the struct, causing **CheckCompatibility** to always fail. * **CheckCompatibility** was not taking into account if the destination container belonged to an item it was containing, allowing two items to contain each other. * **O\_TagValueCalculation** was not in the correct folder. * Custom shaped items where the top left index was hidden (Such as the gear item in the example project) would fail removing its own collision. * **Internal\_TryAddNewItem** had incorrect object pointers, leading to some scenarios crashing the game. * ItemUnequipped would pass invalid item location, leading to difficulties managing and wiping the items data. * **CheckAllRotationsForSpace** would always start at rotation 0, which could cause issues for save files loading correctly. * **MoveItem** was not updating the item data it was using during its logic. So if the item count was updated while dragging an item, the function would undo the count update once it was dropped. * **Internal\_TryAddNewItem** was not adding default tags and tag values to the created item. [Previous2.3.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0) [Next2.1.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0#inventory) * [Example Project](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0#example-project) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0#bug-fixes) --- # 2.9.0 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0.md) . Engine support: 5.4 [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#deprecated) Deprecated -------------------------------------------------------------------------------------------------------------------------- * Both **GetWidgetForItem** and **GetWidgetForContainer** have been deprecated and replaced with functions with the same name, but are found in the function library. * This used to have several functions for retrieving the widgets, because in some cases they were more optimal. But now with the ID map system, there is no need to try and optimize this anymore. * The **CompatibilitySettings** has been updated to use item tag types as the **EItemType** enum has been deprecated * Since the **EItemType** enum has been deprecated, you should use the tag item type version instead. * The attachment widget variable in the item struct has been deprecated, is now a part of the external objects system. Use the **GetItemsAttachmentWidget** function instead. * Override settings Price and SpawnChance have been deprecated. Spawn chance has bee replaced with a tag value while overriding the price is no longer supported. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#documentation) Documentation -------------------------------------------------------------------------------------------------------------------------------- * Equipment documentation updated. * `Working in the System` -> `Creating New Items` has been removed, the contents have been moved to `Classes and Settings` -> `DA_CoreItem` * A loot table system has been added, documentation can be found [**here**](https://inventoryframework.github.io/loottables/) [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#inventory) Inventory ------------------------------------------------------------------------------------------------------------------------ * Container struct title is now much more readable. Can be configured through config settings. * A new `SkipValidation` system for **StartComponent** has been added for both items and containers. This can drastically improve performance (in some cases 40x improvements) when used correctly. `AC_Inventory` documentation has been updated. This system is primarily meant for save files. * **StartComponent** has been heavily reworked to provide better support for the new loot table system. * Item Drivers are now included in the **GetObjectsForItemBroadcast** function and now inherit the **I\_ExternalObjects** interface by default. * The MoveItem server RPC is now almost 4 times cheaper. * **GetComponentByTag** has been moved to C++. Added new helper function for getting the visual for an item **GetItemsVisual** * The Unequip event has been reworked slightly so it is possible to modify an item when it is unequipped, for example the item tags. * Added **GetObjectsForItemBroadcastWithInterface** and **GetObjectsForItemBroadcastWithInterface** * Added **MassSplitItem** * The **Rotation**, **RandomMinMaxCount** and **OverrideSettings** are now hidden in the item settings depending on settings that would make them irrelevant, such as the container not supporting rotation and item type not being stackable. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#items) Items ---------------------------------------------------------------------------------------------------------------- * Some of the item asset functions have been changed to virtual. People who have made children item assets with default containers will now want to override these functions. * When moving an item to a new container, the attachment widget is no longer automatically removed off the screen. * Added non-array version of GetObjectByTag/ByClassForItem [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#equipment) Equipment ------------------------------------------------------------------------------------------------------------------------ * Added a **UpdateItemsEquipStatus**, which allows you to manually declare if an item is equipped. This way you do not have to have an item be in an equipment container to be considered as equipped. * This can accept custom trigger filters to help evaluate what equipment settings to use. * Whenever an item is equipped, a tag is automatically applied, called **EquipTag**. This can be set in the class defaults for the inventory component * Equipment driver can now automatically assign leader poses for skeletal equipment. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#editor) Editor ------------------------------------------------------------------------------------------------------------------ * When hovering over an item asset icon, the in-game tooltip will now show. The in-built tooltip has been reworked to just accept item data, instead of the item widget to allow editor tools like this to use it without creating an item widget. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#bug-fixes) Bug fixes: ------------------------------------------------------------------------------------------------------------------------- * The Item actor could cause a crash if the owner did not implement the **I\_Inventory** interface. * Tile map for other actors was not being initialized correctly. * Swapping item locations could break collision in some cases. * The quick loot window could create 2 instances of the same item in some cases. * Custom shaped widgets would break without a padding and radius object in the item asset. * External objects on items would have client-only objects, such as widgets, removed when an item was moved during a multiplayer session. * Dropped item actors would have some data, such as item count, reset or wiped. * It was possible to split an item in a location that would overlap the original item. [Previous2.10.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1) [Next2.8.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1) * [Deprecated](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#deprecated) * [Documentation](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#documentation) * [Inventory](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#inventory) * [Items](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#items) * [Equipment](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#equipment) * [Editor](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#editor) * [Bug fixes:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0#bug-fixes) --- # 2.11 | Inventory Framework | Varian's Documentation For the complete documentation index, see [llms.txt](https://varian.gitbook.io/varian-docs/llms.txt) . This page is also available as [Markdown](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11.md) . Engine support: 5.4 !!! Warning Lots of classes have been renamed, moved and/or deprecated. I HIGHLY recommend backing up your project or setting up your source control first just in case. Some items may have some objects in the `ObjectsAndDrivers` array (now called `TraitsAndComponents`) be reset to null due to classes being renamed. Any container that was assigned as `List` will most likely break as the enum has been renamed to `Traditional` !!! This version also comes with a new example project and this version will not be tested with the old. Documentation can be found [**here**](https://inventoryframework.github.io/introduction/firststeps/exampleproject/) [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#renames) Renames ------------------------------------------------------------------------------------------------------------------- * Item Objects -> ItemTrait, new prefix is IT and classes have been moved into their own `Traits` folder. * Item Drivers -> ItemComponent, new prefix is IC * Item Struct Object -> ItemInstance, new prefix is II * The container style `List` is now `Traditional`. Documentation will reflect these renames once 2.11 is officially published on the marketplace. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#traits-and-components) Traits and Components ----------------------------------------------------------------------------------------------------------------------------------------------- * The blueprint parents (**BP\_O\_ItemObject**/**BP\_AC\_ItemDriver**) are getting removed in the next update. Please reparent your classes to `ItemTrait`/`ItemComponent`. I can not label them as "Deprecated" because it would also label all children as deprecated. You can use the reference viewer to help find all classes referencing them. * The `IT_ContextMenu` trait has been deprecated. * Components are now soft referenced. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#item-asset) Item Asset ------------------------------------------------------------------------------------------------------------------------- * **ItemInstance** is now soft referenced and no longer instance editable. It made no sense to have it be instance editable as you should just use the class defaults * Removed the **EItemType** enum [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#inventory-component) Inventory Component ------------------------------------------------------------------------------------------------------------------------------------------- * When selecting an asset inside your container settings items array, the dropdown will now automatically filter all item assets that fit your **CheckCompatibility** function. Read the **ItemAsset** code comment for more information. * When selecting an item instance, it will now prevent mixing `ItemInstance` classes and prevent "wild" `ItemInstance`'s. More information can be read about in the `DA_CoreItem` documentation * Added **GetItemsByTagQuery** and **GetContainersByTagQuery** Both of these settings can be disabled through the IFP project settings. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#widgets) Widgets ------------------------------------------------------------------------------------------------------------------- * Containers can now pass a custom padding to tiles and item widgets. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#reworks) Reworks ------------------------------------------------------------------------------------------------------------------- * **BP\_Interactable** is now deprecated and all logic has been moved to **BP\_AC\_Interactable**, allowing any actor to be interactable without worrying about hierarchy. You will now want to reparent your interactables to either your own parent or `AActor` and add the **BP\_AC\_Interactable** actor component. * The **UpdatePreview** is now called on the owner, as usual, but is now also called on the inventory widget if the owner has an inventory component. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#bug-fixes) Bug fixes ----------------------------------------------------------------------------------------------------------------------- * Items would keep their equipped tag when moved out of an equipment container. * Splitting an item via **MoveItem** could break if the destination split was into another container. * The texture for the SocketButton texture and ItemEditor collapse button was in the example project and not the plugin. * Cursor would snap if the user would close an attachment with, then release the mouse while hovering over the player preview. * ItemAbilityTrait did not allow for multiple copies. * Some combinations of container settings and item widget could result in the item icon stretching. * When trading with a vendor, the currency would be given to the player first, then the item would be moved to the vendors inventory. This would lead to currency not going into the tiles that the item used to occupy, which could lead to the player not receiving the currency if their inventory was full, but would have space after the trade. * **TryApplyCooldown** was not calling **CheckCooldown** correctly. [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#id-2.11.1-5.5-only) 2.11.1 (5.5 only) ---------------------------------------------------------------------------------------------------------------------------------------- * The `Use` button would appear on vendor items * **GetTraitByClassForItem** if used with AllowChildren, would then ONLY accept children of the specified class. Simple fix, just check if the two classes are the same here * New example project could not split items because the new project used UI input mode only and the drag widget relied on the player controller receiving input. * Splitting an item, then dropping it, would result in the default item asset count being used. * **AdjustContainerSize** was not adjusting the tile coordinates correctly, leading to items and tiles going into wrong spots. * **AdjustContainerSize** would kick clients if the container was shrunk and an item had to be dropped. * * * [](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#color-sheet) Color Sheet: ---------------------------------------------------------------------------------------------------------------------------- **functions** - **variable** - **category** - **class** [Previous3.0](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0) [Next2.10.1](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1) * [Renames](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#renames) * [Traits and Components](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#traits-and-components) * [Item Asset](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#item-asset) * [Inventory Component](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#inventory-component) * [Widgets](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#widgets) * [Reworks](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#reworks) * [Bug fixes](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#bug-fixes) * [2.11.1 (5.5 only)](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#id-2.11.1-5.5-only) * [Color Sheet:](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11#color-sheet) --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/tagsmetadata/tags-metadata.md). # Tags Metadata A simple config system which stores metadata for tags inside \`collections\`. \`O\_TagMetadataCollection\`: This is the class that hosts a collection of metadata Example: ![](https://varian.gitbook.io/files/YhxhTedGmUAKBOK4b8kx) To have the system pick up your collection, go into \`Project Settings\` -> \`Plugins\` -> \`TagMetadata Settings\` and add your collection to the array. ![](https://varian.gitbook.io/files/ifR1Rt8t0cMvD2PEwOOm) \`O\_TagMetadata\`: The object that is added to the tags Metadata array to grant the tag whatever data you want to add. Example: ![](https://varian.gitbook.io/files/dbYRSU1jRaF30rqCyaZj) The system comes with three functions to retrieve the metadata: ![](https://varian.gitbook.io/files/Nlob668oH9JDVH1CA0YR) Example to retrieve the metadata: ![](https://varian.gitbook.io/files/wLc3DkflNgXfJqtxvA7T) \## Notes \* All of the collections are hard referenced by the config, meaning they are loaded at all times. Be very mindful of what assets you are referencing and always use a soft reference. \* This system is meant for fixed variables, modifying any variables on the metadata objects during runtime is not recommended. ## Base Classes \* \`O\_TagMetadata\` - The metadata object that will host your custom data. \* \`O\_TagMetadataCollection\` - The collection that hosts the metadata objects and associates them with a tag. ## Change log: ### 1.2 \* Collections are now soft referenced. Note, the functions will instantly load a collection if it isn't loaded. So use async load first. for optimal streaming. ### 1.1 \* Collections now prevent identical tags. \* Added editor utility widget. \* Added \`EditorAssistant\` support --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/tagsmetadata/tags-metadata.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/tag-facts/tag-facts.md). # Tag Facts \`TagFacts\` is a simple subsystem storing a fact database. This database is a simple TSet of a gameplay tag and an integer. {% hint style="info" %} \`TagFacts\` is a free plugin available on my \[\*\*ModularityPractice github repo\*\*\](https://github.com/Variann/ModularityPractice) {% endhint %} Fact systems is extremely common in game studios as it provides an extremely simple interface for handling facts and achievements. This can be used to track what quests have been completed, how many times a player has talked to an NPC or any other "fact" you'd like to keep track of. There are only a handful of functions you'll end up using majority of the time. The highlights are: \* IncrementFact \* DoesFactExist \* GetFactValue The other functions are very situational. But when it comes to fact databases, the above functions are the most commonly used. ![](https://varian.gitbook.io/files/PfShcE2Nv8kvJb1eoKUF) It also comes with console commands. \`SetFact\` will allow you to set the value of a tag during runtime, but it's recommended to use the \[Integrations\](/varian-docs/tag-facts/integrations.md) debugger instead. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/tag-facts/tag-facts.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/tag-facts/integrations.md). # Integrations ## Cog \`TagFacts\` comes with a \`Cog\` debugger out of the box. This debugger allows you to increment and decrement facts at runtime. ![](https://varian.gitbook.io/files/pGABDce6LwKHXBc7qGMC) ![](https://varian.gitbook.io/files/JXRhInDQv5SKKcNGy5Oz) \*\*\* ## Hermes The fact subsystem will automatically broadcast a \`FFactMessage\` message on the same channel as the fact when it's added, increment, decrement or removed. ![](https://varian.gitbook.io/files/Bt5dr817qtctNb7Dl7QB) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/tag-facts/integrations.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/imgui-cog-setup/imgui-cog-setup.md). # ImGui (Cog) setup Most of my plugins come with debugging tools built with ImGui. The most popular ImGui solution seems to be \[Cog\](https://github.com/arnaud-jamin/Cog), which I believe is the most mature solution (as of writing). That's why I have standardized all my ImGui debugging tools with this plugin. {% hint style="info" %} Cog is NOT required to be installed to install any of my plugins. My plugins use \[preprocessor macro's to detect if Cog is installed\](/varian-docs/imgui-cog-setup/cogs-presence-detection.md). If it is, then enable Cog related code. If it isn't, disable it and your IDE and compiler will ignore it. {% endhint %} This documentation will cover how to use it and how my code is automatically enabled or disabled depending on this plugins presence. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/imgui-cog-setup/imgui-cog-setup.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/imgui-cog-setup/cogs-presence-detection.md). # Cog's presence detection We will use my \[ObjectTags \](/varian-docs/object-tags/object-tags.md)plugin as an example. Inside of the \`build.cs\` file, you'll find this code: ![](https://varian.gitbook.io/files/LPzxjnDMIVWwHZ3eaROL) This code will enable or disable the \`COG\_INSTALLED\` preprocessor macro depending of the \`Cog\` plugin can be found inside the \`Plugins\` folder and add it as a dependency if it's found. This setup enables us to write Cog dependend code, which is disabled and ignored by the IDE and compiler if the Cog plugin is disabled. ![](https://varian.gitbook.io/files/pBaDQKqqBASgTUAJTTn2) In the code example above, if Cog is missing, the code will automatically be disabled and not recognized by the IDE. Thus, not causing any errors and allowing you to continue using the plugin. {% hint style="warning" %} It's important you do \`COG\_INSTALLED\` first. The compiler is smart enough that if it sees \`COG\_INSTALLED\` as false, it won't bother to check \`ENABLE\_COG\`, which in the case of Cog not being installed, would result in an error. But since \`COG\_INSTALLED\` returns false before \`ENABLE\_COG\`, the compiler immediately strips it out and doesn't bother checking it. If the checks are reversed, you'll get an error saying \`ENABLE\_COG\` is undefined if Cog is ever uninstalled. {% endhint %} In some cases, you might have to wrap \`#include\`'s with the \`#if COG\_INSTALLED\` preprocessor macro, then use \`#if ENABLE\_COG\`. ![](https://varian.gitbook.io/files/CBH3PoqG2RPT332E8vsE) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/imgui-cog-setup/cogs-presence-detection.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/imgui-cog-setup/enabling-the-imgui-debuggers.md). # Enabling the ImGui debuggers Depending on how you manager your windows or if you're using a global window manager, you'll need to call \`AddWindow\` for the plugins Cog window class. ![](https://varian.gitbook.io/files/11d1difMhAnxEo76EzNU) All debuggers can be found in a \`Cog\` folder inside every plugin/module. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/imgui-cog-setup/enabling-the-imgui-debuggers.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/object-tags/cog.md). # Cog \`ObjectTags\` provides a \`Cog\` debugger out of the box that supports its \`Selection\` system. It allows you to make modifications to an objects tags value and its duration during runtime. ![](https://varian.gitbook.io/files/tribfS4PTX8gj55YhM0V) ![](https://varian.gitbook.io/files/llUDPfc6Kh7gzDyMD4md) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/object-tags/cog.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/object-tags/object-tags.md). # Object Tags A simple subsystem that allows you to add a tag to any object. This includes actors, widgets, everything that derives from \`UObject\` can have a tag! You can add/remove tags through the regular \`AddTagsToObject\` or \`RemoveTagsFromObject\`function. ![](https://varian.gitbook.io/files/cI4orqaF3sHwgOFrzR4g) You can also use \`TagRelationship\`'s to create tags that are incompatible with each other. Such as a \`Alive\` tag automatically being removed if a \`Dead\` tag is applied. ![image](https://github.com/Variann/ModularityPractice/assets/6917153/17a1f573-b64e-4623-86bb-db82cfd8578d) \* The system also comes with a \`Listener\` system, which allows other objects to trigger gameplay logic when another objects tags are updated. \* There is a \`TagHistory\` system meant for development and aid debugging to help identify who added/removed tags for itself or another object. ## Base Classes \* O\\\_TagRelationship - Relationship class to associate a relationship between a tag and other tags. ## GAS integration The plugin already automatically adds any tags you add as a LooseGameplayTag to the target if it is an actor and has a Ability component, but not the other way around. This way, whenever you try to activate an ability and it has a \`BlockingTag\` or \`RequiredTags\`, then it'll automatically have the tag you added to the actor through the subsystem. To have the subsystem pick up any tags that GAS applies, you will want to make your own \`ASC\` component and override the \`OnTagUpdated\` function and implement this logic: !\[image\](https://github.com/Variann/ModularityPractice/assets/6917153/ebded181-7560-4e99-9941-57fb73c57d51) !\[image\](https://github.com/Variann/ModularityPractice/assets/6917153/b4251317-c7df-4b67-b2f1-2f2e87442dc7) This setup will ensure that abilities, effects and any other components of \`GAS\` will update the \`ObjectTags\` subsystem. Though this won't handle \`TagRelationship\`'s, you'll have to integrate that yourself or manage the tags in a way to not include tags that might be in a complicated relationship. ## Performance Virtually free. Inclusive call average costs: \* \`GetObjectTags\` - 12k calls, average time: 1.6 microseconds \* \`AddTagToObject\` - 9k calls, average time: 1.7 microseconds \* \`RemoveTagsFromObject\` - 9k calls, average time: 0.5 microseconds ## Debugging ### Console commands \* \`AddTag\` and \`AddTagToPlayer\` : Adds a tag to the actor in front of the camera or the player. This accepts 2 optional floats. A value to assign to the tag, and a duration. \* \`RemoveTag\` and \`RemoveTagFromPlayer\` : Remove a tag from the actor in front of the camera or the player. \* \`ToggleViewActorTags\` : Toggle drawing text over all actors in the level with their tags. ### Cog This section implies that you have a basic \`Cog\` plugin setup. \* The \`ObjectTags\` window debugger class is called \`FCogObjectTagsWindow\`. ![](https://varian.gitbook.io/files/xZe8lwdWuG4EBUH2TTtG) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/object-tags/object-tags.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/object-tags/changelog.md). # Changelog ### 1.4 \* Added Cog debugger \* Added categories to all properties \* Added popup modal when starting the engine to guide users to the documentation ### 1.3 \* Added console commands to add/remove tags \* On-Screen debugger overlay to display the tags of an actor over them \* State tree tasks and conditions \* Vislogger support \* Actor component to add default tags to placed actors in a level ### 1.2 \* Tags can now be applied temporarily with a set timer. \* Tags can now have values associated with them. \* Subsystem is no longer level bound, meaning it can keep track of tags for objects that aren't destroyed when a new level is loaded, such as the game instance. \* Added helper functions for evaluating tag relationships \* Added ImGui debugger ### 1.1 \* \`ObjectTags\` is now a TMap instead of a TArray. Significantly improving performance in some scenarios. \* Improved \`ExternalTags\` support. \* Better \`GAS\` implementation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/object-tags/changelog.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs.md). # Task Graphs \`TaskGraph\`'s is a simple concept where a portion of the game is wrapped up into one or several blueprints. For example; the tutorial could be wrapped into a blueprint, where numerous events are tracked through tasks and gameplay events. Some task graphs can become large as they start referencing numerous tasks and potentially assets. This is why it's heavily encouraged to only soft reference task graphs and use the \`AsyncActivateTaskGraph\`node. By default, you can only create task graphs through this async function to prevent hard reference mistakes. ## Examples \* When an NPC is interacted with, who has branching dialogue, that dialogue can now be hosted and managed inside of a task graph. \* The tutorial section might have several areas to teach the player numerous aspects of the game. One task graph could manage the doors, listen for gameplay events. \* Task graph's support recursion. So a tutorial task graph could be divided into further task graphs, for example a boss fight at the end of the tutorials Task graph can be placed into a sub Task graph. \* Quest chains can be managed nearly entirely within a task graph, creating a space to manage lengthy quest chains. \* When a specific NPC is killed, you could start a task graph that now tracks when a player does another specific event, such as walking past an NPC that is related to the one you killed ## Modular Game Features \`TaskGraph\`'s can be activated through modular game features. Allowing DLC's to create their own \`TaskGraph\`'s. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/task-graphs.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/blueprint-tasks-extension.md). # Blueprint Tasks Extension \`BTE\`(Blueprint Tasks Extension) is a plugin designed to add more nodes and some basic systems to be used alongside \`Blueprint Tasks\`. This plugin is an extension of \[Blueprint Task Forge\](https://github.com/CommitAndChill/BlueprintTaskForge), which is required for this plugin to work. This plugin is free and available for anyone to use on \[Github\](https://github.com/Variann/BlueprintTasksExtension) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/blueprint-tasks-extension.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/who-am-i.md). # Who am I? Hello, I'm Varian! I've been an indie developer for the last few years. Starting to learn programming completely from scratch to now being a successful seller on the marketplace. For reasons I won't go into here, I'm essentially retired and just work on my own games and code for fun. (That doesn't mean I am not available for work, just the chances of me saying yes to a job are low). This website acts as both my portfolio and as a source of documentation for all of my plugins. Either paid, free, in development, or private. I've been crafting a "golden path of development" for quite some time that suits my workflow.\\ What does that mean? I'm creating a workflow that suits me and allows me to make my games faster. This path started out through my most successful plugin, the \[Inventory Framework Plugin\](https://varian.gitbook.io/varian-docs/inventoryframework/), which lead to my public repo, \[ModularityPractice\](https://github.com/Variann/ModularityPractice). This path was then reinforced by \[Riot's development ecosystem\](https://youtu.be/9xxwQVdwcTQ?si=EUl2iFRfBSgeypto) talk. I am still figuring out how much time I want to invest into the UE marketplace and how much I want to focus on indie game development. But what you can always trust in is that I'll always be working on either one! --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/who-am-i.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests.md). # Quests ## Quest structure The structure of a quest can be viewed as a tree and are comprised of three parts. \* Quest Chain: A chain is only completed when all quests associated with the chain are completed \* Quest: A quest is only completed when all objectives stages it contains are complete. A quest can contain as many stages as it needs. \* Objective Stage: A objective stage is only completed when all objectives it contains are completed. The name of this example quest chain will be "A Helping Hand" \* First quest \`Cleaning The Farm\` \* Objective Stage 1 \* Collect 5 Apples \* Collect 3 Carrots \* Objective Stage 2 \* Return the apples and carrots to Farmer John \* Next quest is called \`Tractor Maintenance\` \* Objective Stage 1 \* Refuel the tractor \* Objective Stage 2 \* Get in the tractor \* Objective Stage 3 \* Drive to the farmland \* Next quest is called \`Plow the Farms\` \* Objective Stage 1 \* Plow the carrot farm \* Plow the apple farm \* Objective Stage 2 \* Talk to Farmer John for your payment. (Completes the "A Helping Hand" quest chain) This structure allows you to create similar architecture to quests you can find in many popular RPG's. A quest can have as many stages as you want, allowing you to create lengthy quests that might involve several scenes. ## Branching quests There are no in-built mechanisms for brancing quests, but rather it's put into the hands of designers to dictate how quests branch out. I personally handle this through \[Task Graph's\](/varian-docs/blueprint-tasks-extension/task-graphs.md), and I am responsible for deciding where and how quests are accepted, completed and ultimately locked out from the player. For example, two dialogue choices are given to the player and each will accept a different quest. You might want to lock out the other quest that wasn't chosen, but there might be other parts of the game where that quest could be accepted, so you wouldn't want to lock it from the player. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/other-nodes.md). # Other nodes This page just covers the other nodes that aren't a part of a specific system and can be mostly viewed as quality-of-life improvements. ## Repeater \* Repeatedly triggers for an optional set amount of times with a specific delay in between. Useful for gun firing logic. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/other-nodes.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/object-recycler/warmup-pool.md). # Warmup Pool The warmup pool system allows you to slowly spawn objects until a quota is met. This limit can be set inside the config settings. ![](https://varian.gitbook.io/files/n0OX3HE08xGmyV1FCC1e) When an object is added to the pool and it exceeds this limit, objects will slowly start being removed from the pool depending on the frequency. The oldest object (index 0) in the pool will be removed, as its assumed that one hasn't been used the longest. {% hint style="danger" %} Depending on how much memory the object consumes and your memory budget, you might want to keep the soft cap low. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/object-recycler/warmup-pool.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/my-design-style.md). # My design style ## How are my plugins/systems designed? ### Over-arching goals \* Create a suit of tools, systems, plugins, workflows and more, that tries to be as design agnostic as possible. Slowly creating a large collection of code that can be re-used between projects, no matter their genre or requirements. This can be thought of as "creating an ecosystem/SDK" \* Minimize duplicate work as much as possible. \* Create a "golden path" of development. The clearer this path becomes, the faster development of each project becomes. ### System design Systems can be defined as a plugin, module, a small set of classes, or as an extension in another system like an equipment system in an inventory system. But most of the time, it's just considered as a plugin. \* I will NOT be supporting replication/multiplayer in any of my plugins other than Inventory Framework. I am finished with multiplayer projects. \* Rarely create parent actors or override important classes, such as the game instance. Utilize subsystems, actor components and such as much as possible. \* Plugins should try to be self-contained. If they require another plugin to work, that other plugin should be design-agnostic. \* Do not recreate a system from another plugin just to get around this. It's better to break this rule rather than create duplicate systems. For example, a broadcast system like \`GameplayMessageRouter\` should never have duplicates in other plugins. \* Unfortunately, this rule might be broken in plugins that are planned to be released to the marketplace because of the marketplace dependency rules. \* Try to enable as much Blueprint support as possible. \* Exceptions are made when Blueprint support might cripple or highly complicate a systems workflow. \* Enable cross-plugin integration through preprocessor macros. \* For example; \`TagFacts\` will broadcast a message through \[Hermes if the plugin is installed\](/varian-docs/tag-facts/integrations.md#hermes). ## Debugging standards {% hint style="warning" %} The debugging standards are slowly being enforced throughout my plugins. So these standards might not be found in my plugins \\\*yet\\\* {% endhint %} \* Try to provide a \`ImGui\` debugger through \`Cog\`. (\[\*\*Documentation\*\*\](https://varian.gitbook.io/varian-docs/imgui-cog-setup/)) \* This is mostly just done for systems that are difficult to debug through the \`Blueprint Debugger\` tool or if the engine has no other suitable alternative debugger. \* For functions with fail states where a simpe boolean doesn't cover all fail states, try to include a FString parameter that explains why it failed. \* Add log messages in a custom category or print to the screen if necessary. \* Most custom categories are just called \`Log\` with the name of the module appended to the end. In some rare circumstances, a custom log might be made for a specific system inside of a module. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/my-design-style.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/tools/spreadsheet-object.md). # Spreadsheet Object \`OmniToolbox\` provides a \`SpreadsheetObject\` which can be constructed and passed around as a pointer to manage a singular HTML spreadsheet, which can then later be imported into google sheets. To use the spreadsheet object, you call \`Initialize\` and declare your headers.\\ Headers are the columns at the very top and dictate how far a row can get. You then call \`AddRowByName\` and store the index. You then call \`GetColumnIndexByHeader\` and store the index To then modify a cell, you call \`EditCell\` and pass in the stored row and column index to modify the cell. The file is then saved inside \`ProjectFolder/Saved/Spreadsheets\` whenever \`Save\` is called. ## Why HTML? Every solution I could find to generate a CSV or XLSX file that supported coloring cells required external libraries. These libraries are so popular that I could not find any reliable source of information to create my own without plainly copying the existing libraries. This would be a ton of work for very little gain. Generating a table in HTML with colored cells is very simple and most excel programs can import HTML files, such as Google Sheets and Microsoft Excel. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/tools/spreadsheet-object.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/introduction.md). # Introduction \`Vanguard\` is a module inside of \`OmniToolbox\` that is designed to extend Unreal's automation tooling. It is still slightly under development, but it is driving the test environment for my next big plugin. So it is seeing nearly daily use. ## Why the separate name? Since \`Vanguard\` is focused on testing and automation, it's NOT designed for runtime code, but we still need to expose everything to blueprints and keep it inside \`OmniToolbox\`, not a separate plugin. In an effort to help developers understand when they are working with Omni's systems and when they are working with Vanguard (something that isn't supposed to be packaged), it makes sense to give this system it's own unique name - \`Vanguard\`. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/introduction.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/thumbnail-renderer.md). # Thumbnail Renderer > ## Credits > > Thanks to Erlite from the Unreal Engine discord for helping me with some of the thumbnail property code. There are three ways to override the thumbnail: 1. Use the \`ThumbnailOverrides\` map in the config settings. 2. Implement the \`I\_AssetDetails\` interface and override \`GetThumbnail\` 3. For blueprints, the system will look for any \`Texture2D\` variable with the name “\`ThumbnailOverride\`” (Advised to use soft reference). This is primarily used for Blueprint programmers. 4. Use the \`ThumbnailOverride\` meta property specifier on a \`UTexture2D\` property to use for the thumbnail. (Advised to use soft reference). ![](https://varian.gitbook.io/files/1C82TFnmjTFFo1sbeYaF) The priority for what is chosen is also in the same order as above. ![](https://varian.gitbook.io/files/ToOQyEng3SeHPsZ035sU) Example of a variable in a data asset using the metadata. ![](https://varian.gitbook.io/files/ZiUoP7Yyliy1oWirOMR2) Blueprint asset assigning its own thumbnail You can even reference .uasset files from C++ without having the variable be visible in the editor. ![](https://varian.gitbook.io/files/2I8Zhh7YPWRmLuNWaRao) ![](https://varian.gitbook.io/files/cA0ISc2qN91llCpyUs54) Bugs: \* After installing the plugin, the thumbnail might not load until the asset is opened or reloaded. You will want to make any changes to it so you get the little asterisk label and save the asset. \* Technically not a bug, but textures can be a very low LOD when first loaded. You will want to open the texture and set the \`TextureGroup\` to \`UI\`. \* In some scenarios after setting the texture to null, the thumbnail won't update. You will want to right click the asset -> \`Asset Actions\` -> Press \`Clear Thumbnail\` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/editor/thumbnail-renderer.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_inventoryitem.md). # W\\\_InventoryItem These are the widget representations of your item. The \*\*GetItemData\*\* function automatically gets the direct struct version of the item it is representing from the component the item belongs to. This is so we don’t store the same item information in two places and whenever the item is updated you don’t need to update the widget as well. This should allow for more designer friendly architecture, as you could make two children of this widget, one for example the normal inventory item widget the player has in their inventory and then another for vendors and you could have them store items in a list format and things would still work together. \*\*WBP\\\_InventoryItem\*\* -> \*\*GenerateItemIcon\*\* is where icon generation is handled. It’s pretty straight forward, copying the behavior to other children should be simple. It uses the \[\*\*BP\\\_PreviewActor\*\*\](/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp\_previewactor.md) to achieve this. The data asset editor window has a \*\*UI\*\* category which has various settings to adjust or optimize the generated icons. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_inventoryitem.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp\_previewactor.md). # BP\\\_PreviewActor This is an actor that “should” perfectly duplicate the appearance of any specific actor. It does this by getting all components of the \*\*owning actor\*\* and then duplicating it and reconstructing the hierarchy structure to match the hierarchy structure of the owning actor. This includes any attached actors. It currently supports \*\*SceneComponent\*\*, \*\*PrimitiveSceneComponent\*\*, \*\*ChildActorComponent\*\*, \*\*StaticMeshComponent\*\* and \*\*SkeletalMeshComponent\*\*. Notes regarding **ChildActorComponent**'s 1. There is currently no way to disable \*\*BeginPlay\*\*, where as with Actor's you can with a ExposedOnSpawn boolean at the beginning of your BeginPlay logic. If you have any logic connected to your \*\*BeginPlay\*\*, you will need to find a way to disable it for the preview if there's any logic you don't want the preview to run. 2. If possible, avoid \*\*ChildActorComponent\*\*'s. They are extremely prone to bugs and odd behaviour, and they don't seem to play well with networking. It should be easy to add compatibility for more components, you’ll have to add them yourself, but the currently supported components should support the vast majority of components that have any sort of visual importance. \\ You can optimize the construction or simply prevent this actor from duplicating a specific component by going into \*\*ComponentTags\*\* and adding “\*\*DONOTPREVIEW\*\*”. \\ Though remember, since the actor is trying to reconstruct the hierarchy setup inside your original actor, any components attached to components that you labeled as “\*\*DONOTPREVIEW\*\*” will break. This actor will render out a render target for you to use however you wish and this is how the item icon generation is handled. \*\*\* ## Camera management The \*\*BP\\\_PreviewActor\*\* will attempt to find the first component which has a socket called “PreviewCameraSocket” and attach the camera to that socket. If none is found, you’ll get an error message and the camera will stay attached to the PreviewActor’s root. Ideally, all your meshes should have this socket that you want to use this actor on. But to improve prototyping, I’ve added a few options to the item data asset: ![](https://varian.gitbook.io/files/uzc6G2x8b5myg5O4ZQGG) Once you're far enough into production or willing to keep all meshes up to date with the socket, you should remove these four settings. The actor supports auto-generated estimated camera distances, so you don’t have to debug every item to create a camera distance while in a prototyping phase. You can disable this by checking \*\*Use Custom Arm Length\*\*. \*\*\* ## Skeletal Meshes The default animations for skeletal meshes is retrieved via an interface function \*\*GetEquipmentData\*\*. This allows you to assign what animations the previewed skeletal mesh will play. For now it is only looping one animation, but an animation blueprint can be added to this struct if you wish. \*\*\* ## Optimizations It is also up to you to manage the render targets and when they should be released from the GPU. You can see an example in \*\*WBP\\\_InventoryItem\*\* -> \*\*TryReleaseGeneratedIcon\*\*. I’ve tried to automate the release and creation for the widgets that come with this plugin, but if you are making a new widget and are new to render scene components, you must call ReleaseRenderTarget2D for the texture. It is hard to create a perfectly automated system, so if you ever encounter an icon vanishing for an item, that means the render target was released improperly. During your prototyping phase, I recommend you just release and wipe the references when the player closes their inventory. Then when you’re in your optimization phase, you can try to optimize this. Do keep in mind that live captures can get very expensive, very quickly, since they are capturing a new image every frame. You can limit it by enabling \*\*CaptureEveryFrame\*\* and limiting the \*\*TickInterval\*\* inside of \*\*SceneCaptureComponent2D\*\*. I have these disabled by default, so if your actor isn’t animating, you need to enable CaptureEveryFrame, or if you're duplicating an item, you can go into its data asset and disable \*\*UseStaticCapture\*\*. Any actor being fed into the preview actor should avoid skeletal meshes as much as possible, as they are approximately 50 TIMES more expensive than most other components to clone. ![](https://varian.gitbook.io/files/0tbgZroLDJ2sNro6Ba5E) \*\*\* ## Leader Pose To bind two meshes together, you will have to setup their component tags in a specific way. The leader must contain some tag, in this example we'll use \`PlayerMesh\`. Skeletal Meshes that now want to assign that mesh as their leader pose will then want to add a tag containing the word: \`LeaderPose: PlayerMesh\`. \*\*\* ## Common issues Physics is typically the main culprit for the preview system breaking. If an item or components have physics on by default, they will instantly detach the moment they are initialized. Breaking the entire preview system. Physics will also cause issues with the equipment system, as that system relies on the attachment hierarchy being correct and detaching things due to physics will break it. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp\_previewactor.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3.md). # 0.3 ## Macros \* Added \`Omni\_PlacementPaletteCategory\`, which allows you to easily create a new category inside the \`Place Actors\` tool and the \`Place Actor\` dropdown near the level viewport's \`Selection Mode\` \* Added \`Omni\_AddActorToPlacementPaletteCategory\`, which adds an actor to a placement palette category \* Blueprint users can add a blueprint to the placement palette through the \`OmniToolbox\` project settings through \`Placement Palette Actors\` array. For now, the editor has to be restarted when adding to this array. ## Vanguard \* \`Vanguard\` is a new module extending Unreal's automation tooling and will be powering all testing environments for my future plugins. \* Documentation can be found \[here\](/varian-docs/omnitoolbox/vanguard/introduction.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects.md). # External Objects Both the item struct and container struct has an array of \*\*ExternalObjects\*\*. There are helper functions for both adding and removing widgets from this array. What this array allows you to do is have other widgets receive the same update events from the \*\*I\\\_ExternalObjects\*\* interface that the item widget and container widget receive without using delegates, which listen to ALL events, where as these events are item and container specific. This can be used for hotbars, ammo counters, quest trackers and more where a specific item needs to be monitored. The example project uses the tooltip widget as an external object, where it is listening to the override settings getting updated so it can update in real time alongside the item widget. For your external widgets to receive these updates, you'll want to go to your class settings (1) and implement the \*\*I\\\_ExternalObjects\*\* interface (2). You'll then see a \*\*IFP|External Objects\*\* category with all the update events. Some of these are limited to just items or containers and some are sent to both. ![](https://varian.gitbook.io/files/R1K9fhh5IBwpnPw5Q3mm) Utilizing external objects can replace delegate events from the component, but there are still moments where delegates are better, for example a quest tracker keeping track of how much of a specific item data asset you have in your inventory. {% hint style="info" %} If any actor component on the inventory components owner implements this interface, they will also receive these events. {% endhint %} ## Adding custom events The good news is, you don't even need to modify the \*\*I\\\_ExternalObjects\*\* interface class. Just simply make some interface, create your function and use the \*\*GetObjectsForItemBroadcast\*\* to get all the objects that want to listen to the event ![](https://varian.gitbook.io/files/6vshT1yttpWDDI8pLyRv) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems.md). # Systems - \[Ability System Integration\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration.md) - \[Crafting\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting.md) - \[External Objects\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/external-objects.md) - \[Fragments\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments.md) - \[Item Query\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query.md) - \[Item Sockets\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-sockets.md) - \[Loot Tables\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables.md) - \[Saving and loading\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading.md) - \[Tags and Tag Values\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values.md) - \[Templates for inventory and containers\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers.md) - \[Tile Tags\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags.md) - \[UI Navigation\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/object-recycler/cog.md). # Cog \`ObjectRecycler\` comes with a \`Cog\` debugger out of the box. ![](https://varian.gitbook.io/files/cSIl1PNIjfmPLMxviYaj) ![](https://varian.gitbook.io/files/RKqEgdCHDVxSmXDSoXYO) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/object-recycler/cog.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/object-recycler/object-recycler.md). # Object Recycler A system for recycling spawned objects to improve performance. This type of system is very popular among open world games, games with lots of objects, or games with very tight performance requirements. What does it do? \* Spawning objects is expensive. So why are we destroying objects when we can recycle them? Take for example a projectile: If the player shoots a projectile, it lands on a target, deals damage, spawns VFX, etc. But instead of destroying the projectile, we make it invisible, add it to a pool, then when the player shoots another projectile, we check if any projectiles in the pool are available for re-use. If so, then set a new world location, make it visible, reset any parameters and treat it as if you just spawned in a whole new actor, without paying the cost of spawning and constructing an actor. How fast is it at recycling an object? \* The system has been designed to scale extremely well. So 1 object in the pool or a thousand. In a test of over 3000+ calls where the pool slowly scaled up from 0-200 objects being recycled, the average recycling time was 3 microseconds. For context, in this test the actor that was being spawned only had 1 widget component for displaying damage numbers. On average, this actor was taking 136 microseconds to spawn from scratch. Recycling it was about 45 times more efficient. \* The above was just exclusive time. If we take inclusive time into account, recycling took about 10 microseconds and spawning from scratch took 266 microseconds. Not as efficient as exclusive time, but still 26.6 times faster, but since we are now talking about inclusive time, this scaling will drastically improve when the actor has more components and is more expensive to spawn. Recycling an actor is usually just resetting its location and some parameters. !\[\](https://github.com/Variann/ModularityPractice/assets/6917153/49c294bf-3ee5-416f-9b4d-ec7d6a477147) A hidden benefit this system adds is that it reduces hitches caused by the garbage collector. The garbage collector is one of the main causes of large hitches and low performance spikes in most games, especially UE games as the game starts removing hundreds of objects from memory (This should be improved in 5.4 with the asynchronous garbage collector). Since this system is re-using objects and not allowing them to be garbage collected, this hitch can be greatly reduced. ## How to use This is a subsystem, so no reparenting of any kind is needed. Just simply call these functions: ![](https://varian.gitbook.io/files/cHNCUoNKllaEkirZQ5AO) For classes to participate, they must implement the \`I\_ObjectRecycling\` interface, which includes these functions: ![](https://varian.gitbook.io/files/650g3Q9hbv5JlWva6cHB) \## Advice \* When you send an actor into the pool and decide to set its location to somewhere you might send other actors, it's highly suggested to disable collision on that actor. This is because all the actors you will send there will start colliding with each other. This will consume your FPS and Unreal Insights will only report back \`ExecuteForegroundTask\`, with no hints that it's actually collision events. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/object-recycler/object-recycler.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/input-nexus/cog.md). # Cog \`InputNexus\` provides a \`Cog\` debugger out of the box. ![](https://varian.gitbook.io/files/Spll9M7NiXzR4BB3LxpT) This debugger allows you to make certain modifications to all registered \`InputNexus\` components and their \`InputLinks\` in the level. Adding it to your window manager is very simple. I prefer to put the window into the \`Input\` category. ![](https://varian.gitbook.io/files/coJMSB7VrBkgccWPAZct) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/input-nexus/cog.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/input-nexus/welcome-to-input-nexus.md). # Welcome to Input Nexus \`InputNexus\` is a plugin that streamlines how Enhanced Input System is handled and where gameplay logic is stored, creating a more designer-friendly approach and reducing clutter in the player controller and pawns. \* \*\*Input Nexus Component:\*\* Hosts an array of Input Link's and is the home of input management. \* \*\*Input Link:\*\* Objects linked to an input action's event to run your gameplay code. \* \*\*Link Bundle:\*\* Quickly grant multiple Input Nexus component's the exact same Mapping Context, Input Action and Input Link setup. \* \*\*Input Buffering:\*\* Open buffer channels to delay Input Link's code tied to those channels until the channel is closed. The vast majority of gameplay logic around Enhanced Input System can be found in the player controller and pawn, which slowly leads to those classes becoming massively bloated. Because of this, the core of \`InputNexus\` can be found in the \`AC\_InputNexus\` actor component. This component hosts an array of input actions, and grants each input action an array of \`InputLink\`'s, then when that input action is activated, the nexus component sends appropriate events to each link associated with that input action. This can include movement, opening an inventory screen, activating GAS abilities, etc. This approach allows you to create reusable, easily manageable input gameplay logic that can be used across projects. ![](https://varian.gitbook.io/files/JVXfXFXjVcPuYXduzL7F) \## FAQ \* Should the regular \`InputAction\` nodes continue to be used? \* You can, but it is advised to use \`InputLinks\` whenever possible because we can control the order and input consumption. This system does not block the regular input action nodes from being used in any way. \* The helper library comes with a \`RegisterObjectWithInputComponent\` and \`UnregisterObjectWithInputComponent\` function, which enable and disable the traditional input action nodes in most classes. \* Is it possible to have multiple Nexus components at the same time? \* Yes! You can also enable/disable input events per Nexus component. Meaning you can disable one, then enable another Nexus component to completely swap out \`InputActions\` and \`InputLinks\`. \* For things like GAS, why wouldn't I use the in-built \`EIS\` support? \* Every single system in Unreal that tries to tie some event to input actions are separated. So it becomes extremely difficult to debug, organize, customize and control. Lyra has its own implementation, GAS has its own implementation. \`InputNexus\` is a centralized system that tries to allow itself to be connected to anything you want to enable \`EIS\` support for, such as a custom ability system. \* Does this support replication? \* No. But it doesn't mean it can't be implemented. As stated \[here\](/varian-docs/my-design-style.md#how-are-my-plugins-systems-designed), I am done with creating systems with replication support. It is fairly simple to add replication support, but I won't be adding it because it would mean that I would have to provide technical support for multiplayer issues. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/input-nexus/welcome-to-input-nexus.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/input-nexus/changelog.md). # Changelog ## Version 1.0.0 \* Release --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/input-nexus/changelog.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/omnitoolbox.md). # OmniToolbox \[Github link\](https://github.com/Varian-s-Unreal-Plugins/OmniToolbox) | \[Trello Board\](https://trello.com/b/M1LkF49R/omnitoolbox) | \[Discord\](https://discord.gg/bBfa9pwtEn) \`OmniToolbox\` is a free and open-source plugin designed to provide numerous function libraries, quality-of-life editor changes and provide a foundation to improve all of my plugins. There are many features that are very impactful, but are too small to warrant their own plugin. This toolbox is essentially my collection of those features. Highlights include: \* Quickly and easily add any asset into the content browser's context menu by simply adding a interface. \* Assets can easily control their own thumbnails through a universal thumbnail renderer. \* Many C++ functions exposed to Blueprint, such as async traces, gameplay tag utility functions. \* Useful tools and features too small to warrant their own plugin, such as \[Float Providers\](/varian-docs/omnitoolbox/runtime/float-providers.md). \* Useful macro's and utilities to simplify C++ code. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/omnitoolbox.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/hiding-properties.md). # Hiding properties In some scenarios, you might want to hide a property from the details panel for various reasons. I wanted this feature because I have a custom GAS ability component with custom ability sets and GAS abilities. I am using \`GAS Companion\`, which has its own ability set and default abilities. To reduce UI clutter and reduce chances of someone mixing up which one to use, I added a UCLASS meta property to hide properties by their names ![](https://varian.gitbook.io/files/gBpr7iAfO2Jv0Vu0KRU6) {% hint style="info" %} This does not work for classes that have a custom \`IDetailCustomization\`class. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/editor/hiding-properties.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/todo.md). # Todo ## Validators \* Common validators to help projects get going. For example: \* Enforcing naming schemes, such as materials must have a \`M\_\` prefix and material instances must have a \`MI\_\` prefix. \* This would be its own separate module and a config setting to enable, just in case developers already have their own validators or have a style guide that does not match these validators. \* \[Flassari - CommonValidators\](https://github.com/Flassari/CommonValidators) is a good source to start with ## Linked assets toolbar An example would be behavior tree's and blackboards. In IFP, linked assets would be very useful for the item asset. Having a button to quickly go between the item asset, item actor, item instance and such would be very useful. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/todo.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/macros.md). # Macros --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/editor/macros.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/macros.md). # Macros Some of these macros are only functional while in the editor, and some work on both.\\ Some of these macros are meant for .cpp files and placed in the global scope. The rest can be placed inside of regular code. \`\`\`cpp Omni\_InsightsTrace\_Str("My insights trace") \`\`\` \* Wrapper for \`TRACE\_CPUPROFILER\_EVENT\_SCOPE\_STR\` \`\`\`cpp Omni\_InsightsTrace() \`\`\` \* Wrapper for \`TRACE\_CPUPROFILER\_EVENT\_SCOPE(\_\_FUNCTION\_\_)\`. If the function this macro is inside of is called \`Bar\` and the class is named \`Foo\`, this will display as \`Foo::Bar\` inside Unreal Insights \`\`\`cpp Omni\_OnModuleStarted("AIF\_Mass") { UE\_LOG(LogTemp, Warning, TEXT("AIF\_Mass module has started")); } \`\`\` \* This macro will trigger the code beneath it whenever the specified module is started. You can find module names inside of a plugins \`.uplugin\` file. \* Place in .cpp file and in global scope. \* You can use the engine's \`UE\_MODULE\_NAME\` macro if you aren't waiting for a separate module to start. \`\`\`cpp Omni\_SetClassIcon( AgentIntelligenceFramework, /\*Plugin name\*/ AgentGameplayEffectConfig, /\*Class name (No U prefix)\*/ EffectIconSlate) /\*Name of SVG inside of plugins resource folder\*/ \`\`\` \* Automatically assigns an SVG (must be inside the plugins \`Resource\` folder) for a class as the class icon and class thumbnail. \* Place in .cpp file and in global scope. ![](https://varian.gitbook.io/files/qzJKUZQjRkWBSobWRogD) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/macros.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide.md). # Test Environment Guide Some of my plugins get their own test environments - including \`OmniToolbox\`. This page is covering the standardization measures taken for all of these environments to make sure they are all consistent. This page can also be used to help inspire your own test environments and their rules. ## Style guide \* Each test environment must be a game feature plugin and be named with either the full name of the plugin or project its testing or its shorthand term (Inventory Framework Plugin -> IFP), followed with \`\_TestingEnvironment\` \* Game feature plugins feature everything we need to limit asset referencing and helps ensure all test content is disabled or not cooked in final builds. \* Some tests might want to make temporary changes to the asset manager, or add components to actors for debugging the games normal gameplay maps in the middle of a session. Game Feature Plugins natively support this. \* With the \`\_TestingEnvironment\` suffix, it's possible to check in your shipping builds if any game features with that suffix exist. If so, then something went wrong with packaging. \* The environment can only have 1 map and it must be named with a \`M\_\` prefix, then named after the test environment plugin. For example, \`OmniToolbox\`'s map is named \`M\_OmniToolbox\_TestingEnvironment\` \* Making sure external maps are cooked for automation testing is painful and adding more test maps only forces automation tools to be updated. This rule makes sure that once the cook command has been setup, it doesn't have to be updated. \* Every map must have a camera actor with a tag \`DefaultCamera\` \* \`UTestAssistantComponent\` can automatically assign all tests with no observation point to use this actor as its observation point. \* Every test must be located in loaction 0,0,0 (unless the test is testing something regarding elevation). The test map must have a flat plane that does not prevent actors at this location to fail to spawn, but still allow actors to walk without falling. This plane must also have a grid material with standard measurements. \* With location set to 0 and the grid material makes it possible to identify if something in the scene is in the correct location through a screenshot or without opening a debugger. \* I highly recommend the grid material from the Game Animation Sample. \* Every test must have atleast one tag. \* This is to make the \`Automation RunTests\` console command easier to use. \* Every test goes into the \`Testers\` folder and then has its own folder. Even if the test is only 1 class. \* All assets inside these test environments must only reference assets inside of themselves or engine assets. Plugins found in the engine are not allowed to be referenced. \* Most engine assets used are the simple primitive shapes, such as the default engine cube. ## Setting up the Project Launcher There's 2 ways to open the project launcher; 1. In the editor, go into \`Tools\` -> \`Project Launcher\` 2. Open file explorer and go to \`YourEngineInstallation\\Engine\\Binaries\\Win64\` and open \`UnrealFrontend.exe\` I recommend the latter so the process is not tied to your editor, in case it crashes. It's also better to learn to not rely on the editor being open in case you ever build a home server or start using cloud services to automate your builds and tests. {% hint style="info" %} Unfortunately, Unreal's support for blueprint-based automation tests are very limiting. Tests can only be discovered by maps that have been opened throughout the session and it seems to struggle with swapping maps. Because of this, we have to create a launch profile for every test environment. {% endhint %} ### Creating a launch profile 1. Press the \`Create Launch Profile\` button 1. I tend to name my launch profiles for test environments like so: \`Name of plugin being tested - Test tags (Full suite if all tests are being ran) - Configuration (DebugGame/Development\`. ![](https://varian.gitbook.io/files/c7TUKgkHhWlGyBQCRYDi) 2\. Add this to the additional cook commands: \`\`\` -Map=M\_OmniToolbox\_TestingEnvironment -package \`\`\` \* This will make sure the test environment map is packaged. 3. This step is optional, depending on how you want to use this profile. You can add commands to be executed, such as console commands to enable or disable certain features. \`\`\` -ExecCmds=\\"open M\_OmniToolbox\_TestingEnvironment\\" \`\`\` \* Open the test environment map \`\`\` -ExecCmds=\\"OmniToolbox.Vanguard.GenerateSpreadsheets 1;\\" \`\`\` \* Enable spreadsheet generation \`\`\` -ExecCmds=\\"OmniToolbox.Vanguard.OverrideIsAutomationTesting 1;\\" \`\`\` \* When using Unreal Automation in the editor, there's a flag (\`GIsAutomationTesting\`) that is set to true. But when you start tests through a console command, this flag is not set to true. \`Vanguard\` relies on this flag, but due to an engine bug, we have to use our own flag when running through the project launcher. \`\`\` -ExecCmds=\\"Automation RunTests OmniToolbox;Quit\\" \`\`\` \* Execute all automation tests with the \`OmniToolbox\` tag, then once they are finished, close the session. \* \`Automation RunTests\` can also take specific names if you only want to run specific tests. It also accepts multiple tags \* You can remove \`Quit\` if you don't want the client to automatically shut down. \* Remember, this is a console command. So if you want to rerun a test during runtime, you can either use the \`Automation RunTests\` console command or open the \`Sessions Frontend\` -> \`Automation\` and run the tests through there. My profiles usually end up looking something like this: ![](https://varian.gitbook.io/files/DUW8AhRsEu3EvRA4N3hq) \* I added \`stat fps\` and \`stat unitgraph\` for this profile, since I usually monitor it. But ideally, you should not have to monitor these tests. {% hint style="info" %} When changing engine versions or reinstalling the engine, your profiles might get wiped. To backup your profiles, go to \`EngineInstallation/Programs/UnrealFrontend/Profiles\` and backup the files found in there. {% endhint %} ## Common issues \* \`Could not find file ProjectDirectory\\Binaries\\Win64\\ProjectNameEditor.target\` \* To fix this, launch your project with your IDE and rebuild your project with the \`Development\` configuration assigned. \* \`DoesPackageExist called on PackageName that will always return false. Reason: Input '/SomeFile' is not a child of an existing mount point.\` \* There seem to be many solutions to this posted online. For me, this was solved by disabling and enabling the game feature plugin \* \`Error\_FailedToDeleteStagingDirectory\` \* This usually occurs when another application is using a file inside the staging directory. This can happen when you have any of the spreadsheets or trace files open in a separate program. \* If you use a cloud service, like OneDrive, pCloud or something else, those can sometimes lock files inside the staging folder. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/test-environment-guide.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools.md). # Tools - \[Inventory Helper\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper.md) - \[Item Editor\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper.md). # Inventory Helper \[\*\*Video documentation\*\*\](https://youtu.be/5CsMMlH9w2Y) \*\*\* {% hint style="info" %} As of 5.4, there is an engine bug that is causing the widget that gives us a details panel to cause hundreds to thousands of invalidations of the widget. This is causing an annoying amount of lag. The tool still functions, but as this is an engine bug, there is little I can do to alleviate this. {% endhint %} You will very likely be spending a good amount of time using this utility widget, so I suggest bookmarking it or having some way of quickly accessing it while you work. Working with the raw container struct and the array of items is extremely cumbersome and not very efficient use of time. It also does not provide any sort of feedback of items that might be overlapping or have gone outside the bounds of the container. This is why I've developed the Inventory Helper. This is a editor utility widget which attempts to mimick the final result you'd see in game and providing a place for you to create your own in-editor tools without going into C++. It is \*\*HIGHLY\*\* advised to rarely, if ever, work with the raw container settings array. The only exception is class defaults. Use the inventory helper whenever you can. Because of how many features this helper has, it becomes a lot to write down, so I've made a video (Not yet released) going over how to use the inventory helper and cover many of its features. \*\*\* ### The void system What might confuse most is the "Void" widget and actor. Dragging and dropping an item onto the background will "pin" the item exactly where you dropped it. But the item data and its containers must be stored on an actor \*somewhere\* in the currently loaded level. The void actor is where that data is stored. This also has the benefit of acting as a proxy for moving an item from one actor to another. You can select one actor, move an item into the void area, then select another actor and move the item into one of its containers. Limitations \* It is NOT recommended to edit the \*\*Container Settings\*\* through the \*\*SelectedComponent\*\* widget. The reason being is that the \*\*OnPropertyChanged\*\* event does not return which index has been modified. Meaning it is not possible to resolve which container or which item was modified, which means that every container widget and item widget must be updated. Only modify the container settings inside this widget if you really have to. \* The normal highlight widget is not supported. An alternate method is used instead. \* Item splitting is not supported. \* Only basic item collision is supported, no combining or stacking. \* The Item Void actor is not meant to be interacted with outside the inventory helper. If you wish to modify the Item Void regularily, consider modifying the InventoryHelper and have the tool modify it for you. \* \[\*\*Generated item icons do not work\*\*\](https://trello.com/c/F1nJdIid/223-generated-item-icons-inside-the-item-library) . It is suggested to open your game, inspecting the item and saving the generated icon to disk, then setting it inside the data asset. \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/inventory-helper.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_attachment-parent.md). # W\\\_Attachment Parent The parent widget for widgets that are used to hold the containers an item owns. For example, a gun has a sight and a magazine slot and you want to represent those slots with a container. That container needs to be hosted by \*some\* widget. The base widget does not have any kind of layout so you are free to make any layout your project needs. Both the C++ parent and the blueprint child are abstract, so it won't appear in any drop-down menus. These are designed for the intention to have children made from them. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_attachment-parent.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q.md). # F.A.Q \*\*\* ### Q: Can the system be used for a more traditional inventory system where all items are 1x1? A: Of course! Containers have styles, and the \`Traditional\` style converts all items into 1x1. \*\*\* ### Q: Will stats/attributes or ability systems of any kind be added? A: No. I believe most people should be using the Gameplay Ability System framework as it is becoming the industry standard or something similar (I personally suggest \[\*\*GAS Companion\*\*\](https://www.unrealengine.com/marketplace/en-US/product/gas-companion) from the marketplace). A lot of people also already have a stat/attribute or ability system in place and I do not want to step on their toes. The \[tag system\](https://inventoryframework.github.io/workinginthesystem/tagsystem/) does allow you to create basic stats and attributes for items, but I generally recommend people use GAS or a more fleshed out system designed around that. \*\*\* ### Q: Will I be adding any art, meshes or animations to the asset? A: No, with the exception of some basic things like the Tile Icon and some other things, just enough so you don’t get any compile errors and can interact with the system before you implement your art. \*\*\* ### Q: Does the plugin feature an interaction system? A: This plugin does not provide a fleshed-out interaction system for you, but an interface system is integrated in the demo's as that's the foundation of every interaction system I've seen. This is done so your project does not build a dependancy on my interaction system if you ever decide this plugin does not fit your project. The interaction system is designed to be replaced, as most people already have an interaction system already in place. \*\*\* ### Q: Does the plugin work with CommonUI and Enhanced Input? A: Enhanced Input, of course! CommonUI, yes, but it's not native. CommonUI just reworks how input routing is handled and provides widgets for common UI cases. But due to not everyone liking CommonUI, I am not having IFP depend on CommonUI, so it is not implemented by default.\\ This does not mean IFP does not support gamepad navigation. Please refer to the \[documentation\](/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation.md) for more information \*\*\* ### Q: Will I be adding X feature/system? A: Only if it’s a highly requested feature, only then will I either implement it into the base asset itself or advise you how to make it yourself. You can track what is being worked on and what will be worked on in the future by going to the \[Trello board\](https://trello.com/b/pE2DJRlb/inventory-framework-plugin). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/f.a.q.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values.md). # Tags and Tag Values \[\*\*Gameplay tags\*\*\](https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScripting/Tags/) are extremely powerful and this system attempts to allow itself to expand to various needs using not just gameplay tags, but also a value associated with tags. There are two systems, a regular gameplay tag and the second being a tag value system. The component, containers and items can have both through the \`Tag and TagValues\` fragment. These tags can be updated, removed and added during runtime and are fully replicated. For example; The system does not by default have a durability system. But with the tag value system, you can add a tag Item.Stat.Durability and give it a value, and voila! You now have a durability system! (Of course you have to implement the background logic that would reduce or increase this value). The tag system is fairly simple, containers could use them as labels, for example Container.Type.Fridge and now any food items could have a tag value such as Item.Food.Quality which would slowly go down over time, but while in a container with a Container.Type.Fridge tag, it would decay much slower. There are helper functions for resolving the value of specific tags, finding items or containers with specific tags and more. \*\*\* The add, remove and set functions have the option to "IgnoreNetworkQueue", if this is check to true, the item will not be added or removed from the network queue. This can be useful for moments where you are fine with server and client data not being in sync for a short moment. If you check this to true, you should NOT rely on that tag for any data validation. \*\*\* ## Tag Value calculation The Setter functions have a class parameter, which allows you to inject your own calculations before the final value is set. This is a prime location for clamping certain values, such a durability value. You might have a CurrentDurability tag value and a MaxDurability tag value, then whenever you modify CurrentDurability, you can pass in a tag value calculation class that will handle the clamping for you. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tags-and-tag-values.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items.md). # Sorting Items There are a few ways to sort items, the primary way people will want to sort items is to also move items. Sorting an items array by itself is very simple, the item library editor tool shows an example of how to sort items alphabetically, but things become slighlty more complicated when you also want to move items inside of a container. ## Adding sorting options \*\*\* I've designed the function SortAndMoveItem to only require one change for any custom sorting you want to perform. 1. In Async\\\_InventoryFunctions.h there is an enum called \*\*ESortingType\*\*. You will want to add an option in there (I suggest adding your options to the end, the editor does not like it when you re-order or insert enum entries). 2. I suggest making your own IFP function library or making a IFP section in any of your existing function libraries. This is so if you ever update the plugin, any changes you make to the IFP function library won't be wiped. Then make a function that sorts an array of items. An example can be found in \*\*FL\\\_InventoryFramework.h\*\* -> SortItemStructsAlphabetically 3. Go into \*\*AC\\\_Inventory\*\* -> \*\*Internal\\\_SortAndMoveItems\*\* and you'll find a \*\*SortType\*\* switch statement. You'll want to add your new sort option enum in there and call the sort function you just made. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions.md). # Versions - \[3.4\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4.md) - \[3.3.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1.md) - \[3.2.2\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2.md) - \[3.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1.md) - \[3.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.0.md) - \[2.11\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11.md) - \[2.10.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1.md) - \[2.9.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0.md) - \[2.8.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.8.1.md) - \[2.7.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.7.1.md) - \[2.6.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0.md) - \[2.5.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1.md) - \[2.4.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0.md) - \[2.3.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0.md) - \[2.2.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0.md) - \[2.1.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.1.0.md) - \[2.0.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.0.1.md) - \[1.2.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.2.0.md) - \[1.1.1\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.1.1.md) - \[1.0.0\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.0.0.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0.md). # 2.2.0 Engine support: 5.3 \*\*\* ## Inventory \* Added tag values to component. \* Security around \*\*TryAddNewItem\*\* has been loosened slightly to allow server RPC's to call the function for player controlled actors. Where as before the caller of the function had to be owned by the server. \* The multithreaded \*\*SortAndMoveItems\*\* has been deprecated while a rework is explored. \* \*\*SplitItem\*\* has been reworked slightly to fix some replication and collision issues. \*\*\* ## Example Project \* Added an example of how to have equipped items attachment widget automatically get added to inventory screen. \*\*\* ## Bug fixes \* An items default tags weren't being applied in the correct order inside \*\*StartComponent\*\* if the item didn't have the tag inside the struct, causing \*\*CheckCompatibility\*\* to always fail. \* \*\*CheckCompatibility\*\* was not taking into account if the destination container belonged to an item it was containing, allowing two items to contain each other. \* \*\*O\\\_TagValueCalculation\*\* was not in the correct folder. \* Custom shaped items where the top left index was hidden (Such as the gear item in the example project) would fail removing its own collision. \* \*\*Internal\\\_TryAddNewItem\*\* had incorrect object pointers, leading to some scenarios crashing the game. \* ItemUnequipped would pass invalid item location, leading to difficulties managing and wiping the items data. \* \*\*CheckAllRotationsForSpace\*\* would always start at rotation 0, which could cause issues for save files loading correctly. \* \*\*MoveItem\*\* was not updating the item data it was using during its logic. So if the item count was updated while dragging an item, the function would undo the count update once it was dropped. \* \*\*Internal\\\_TryAddNewItem\*\* was not adding default tags and tag values to the created item. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.2.0.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0.md). # 2.3.0 Engine support: 5.3 \*\*\* ## Quality of life \* External widgets for both items and containers are now TObjectPtr, which means it is not mandatory to remove the widget from the array for it to be garbage collected. But this does mean the widget must be referenced somewhere in your game, such as being on the screen. Otherwise, it'll get garbage collected. \* Added a "Inventory Framework" category to the content browser right click menu, allowing you to quickly create assets. \* Most of the classes for the context menu have a blueprint class parent, which is generally not safe to reference in C++. Because of this, a "Inventory Framework" section has been added to Project Settings -> Plugins. This also means you can easily change what classes the content menu creates without touching C++. ## Inventory \* Added \*\*GetTotalValueOfTag\*\* function. \* Added \*\*GetNearbyItemsDirectional\*\* function. \* Added \*\*GetAvailableEquipmentContainers\*\* function. \* Added \*\*GetCompatibleEquipContainersForItem\*\* function. \* Added \*\*CanItemBeDestroyed\*\* function. \* Added \*\*HasAnyItems\*\* function. \* The item actor has been renamed to \*\*A\\\_ItemActor\*\*/\*\*BP\\\_ItemActor\*\* ## Widgets \* The \*\*ContainerSettings\*\* variable inside \*\*W\\\_Container\*\* has been renamed to \*\*TemporaryContainerSettings\*\* to reduce confusion around how to get the widgets true container settings. \* \*\*OwningItem\*\* and \*\*ParentTile\*\* inside \*\*W\\\_Tile\*\* have been deprecated. Use \*\*GetOwningItem\*\* to retrieve the item widget. \* The quick loot window will now show the root item. \* Quick loot window will now automatically hide and show the expand option if the item can be expanded. \* Context menu has been reworked into an item object. If no context menu object is found, then it'll default back to the old method which I won't be maintaining and an print string will pop up. \* The InventoryHelper no longer automatically imports the items default containers. It will now import them when the item is opened instead of overriding the default containers by default. ## Bug fixes \* Highlight widget could go out of bounds. \* \*\*TryAddNewItem\*\* was not calling the equip dispatcher if it added an item to an equipment container. \* The drop option in the context menu would never show up for equippable items. \* DriverStarted delegate was assigned to the wrong delegate. \* Vendors would delete any currency items that didn't have an acceptable currency. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.3.0.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11.md). # 2.11 Engine support: 5.4 !!! Warning Lots of classes have been renamed, moved and/or deprecated. I HIGHLY recommend backing up your project or setting up your source control first just in case. Some items may have some objects in the \`ObjectsAndDrivers\` array (now called \`TraitsAndComponents\`) be reset to null due to classes being renamed. Any container that was assigned as \`List\` will most likely break as the enum has been renamed to \`Traditional\` !!! This version also comes with a new example project and this version will not be tested with the old. Documentation can be found \[\*\*here\*\*\](https://inventoryframework.github.io/introduction/firststeps/exampleproject/) ## Renames \* Item Objects -> ItemTrait, new prefix is IT and classes have been moved into their own \`Traits\` folder. \* Item Drivers -> ItemComponent, new prefix is IC \* Item Struct Object -> ItemInstance, new prefix is II \* The container style \`List\` is now \`Traditional\`. Documentation will reflect these renames once 2.11 is officially published on the marketplace. ## Traits and Components \* The blueprint parents (\*\*BP\\\_O\\\_ItemObject\*\*/\*\*BP\\\_AC\\\_ItemDriver\*\*) are getting removed in the next update. Please reparent your classes to \`ItemTrait\`/\`ItemComponent\`. I can not label them as "Deprecated" because it would also label all children as deprecated. You can use the reference viewer to help find all classes referencing them. \* The \`IT\_ContextMenu\` trait has been deprecated. \* Components are now soft referenced. ## Item Asset \* \*\*ItemInstance\*\* is now soft referenced and no longer instance editable. It made no sense to have it be instance editable as you should just use the class defaults \* Removed the \*\*EItemType\*\* enum ## Inventory Component \* When selecting an asset inside your container settings items array, the dropdown will now automatically filter all item assets that fit your \*\*CheckCompatibility\*\* function. Read the \*\*ItemAsset\*\* code comment for more information. \* When selecting an item instance, it will now prevent mixing \`ItemInstance\` classes and prevent "wild" \`ItemInstance\`'s. More information can be read about in the \`DA\_CoreItem\` documentation \* Added \*\*GetItemsByTagQuery\*\* and \*\*GetContainersByTagQuery\*\* Both of these settings can be disabled through the IFP project settings. ## Widgets \* Containers can now pass a custom padding to tiles and item widgets. ## Reworks \* \*\*BP\\\_Interactable\*\* is now deprecated and all logic has been moved to \*\*BP\\\_AC\\\_Interactable\*\*, allowing any actor to be interactable without worrying about hierarchy. You will now want to reparent your interactables to either your own parent or \`AActor\` and add the \*\*BP\\\_AC\\\_Interactable\*\* actor component. \* The \*\*UpdatePreview\*\* is now called on the owner, as usual, but is now also called on the inventory widget if the owner has an inventory component. ## Bug fixes \* Items would keep their equipped tag when moved out of an equipment container. \* Splitting an item via \*\*MoveItem\*\* could break if the destination split was into another container. \* The texture for the SocketButton texture and ItemEditor collapse button was in the example project and not the plugin. \* Cursor would snap if the user would close an attachment with, then release the mouse while hovering over the player preview. \* ItemAbilityTrait did not allow for multiple copies. \* Some combinations of container settings and item widget could result in the item icon stretching. \* When trading with a vendor, the currency would be given to the player first, then the item would be moved to the vendors inventory. This would lead to currency not going into the tiles that the item used to occupy, which could lead to the player not receiving the currency if their inventory was full, but would have space after the trade. \* \*\*TryApplyCooldown\*\* was not calling \*\*CheckCooldown\*\* correctly. ## 2.11.1 (5.5 only) \* The \`Use\` button would appear on vendor items \* \*\*GetTraitByClassForItem\*\* if used with AllowChildren, would then ONLY accept children of the specified class. Simple fix, just check if the two classes are the same here \* New example project could not split items because the new project used UI input mode only and the drag widget relied on the player controller receiving input. \* Splitting an item, then dropping it, would result in the default item asset count being used. \* \*\*AdjustContainerSize\*\* was not adjusting the tile coordinates correctly, leading to items and tiles going into wrong spots. \* \*\*AdjustContainerSize\*\* would kick clients if the container was shrunk and an item had to be dropped. \*\*\* ## Color Sheet: \*\*functions\*\* - \*\*variable\*\* - \*\*category\*\* - \*\*class\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.11.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4.md). # 3.4 ## Inventory \* \*\*TryAddNewItem\*\* has been updated to better utilize recent updates reworks and new features and should be more consistent and in-line with new \`IFP\` features. It's also far more server-authoritative now, nearly all processing is done on the server, reducing game thread time on clients. \* Many deprecated properties have now been removed. Most notably deprecated data inside \*\*FS\\\_ContainerSettings\*\*, \*\*FS\\\_InventoryItem\*\* and \*\*DA\\\_CoreItem\*\* \* The \*\*Count\*\* parameter is now a slider. It checks the items max count to clamp the sliders max value, making it far easier for designers who didn't design the item understand what the max count is, without opening the item asset. ## Vendors The logic around vendors and currency exchange has been slightly rehauled and many old bugs and issues have been resolved. ## OmniToolbox support \* Many assets now have a "Documentation" button near the save or compile button that helps direct users to the documentation for that specific asset. \* Traits can add to this list ![](https://varian.gitbook.io/files/Dkr6OBLuZFXOZY6CUh2K) \## Tooltip \* There's now a C++ parent for the tooltip widget. \*\*WBP\\\_Tooltip\*\* has been reparented to \*\*W\\\_Tooltip\*\* \* Added a new console variable to enable and disable the tooltips debug mode. Documentation has been updated. ## Bug fixes \* SplitItem's return value for Item1RemainingCount was incorrect. In some cases, Item2RemainingCount could also be incorrect. \* \*\*CanSplitItem\*\* was not treating containers with no tile map the same way as other functions were \* Compile errors for Mac and certain Linux compilers around TInstancedStruct should now be resolved \* Fixed an issue where gamepad navigation had stopped working for 5.7 ## Color Sheet: \*\*functions\*\* - \*\*variable\*\* - \*\*category\*\* - \*\*class\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.4.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2.md). # 3.2.2 Engine support: 5.5 and 5.6 ## Inventory Extensions New system to simplify the creation of helper components, like the ones found in the example project. \* \[\*\*Documentation\*\* \](/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac\_inventory.md#inventory-extension-components)for the inventory component has been updated ## External Objects \* If any actor component on the inventory owner has the \*\*I\\\_ExternalObject\*\*'s interface, they will now receive these events. ## Project Settings \* \`IFP\`now includes 2 project settings; editor and runtime. \* Runtime project settings will be slowly getting expanded to allow for tweaking \`IFP\`'s default behavior without changing source code, and providing some QoL features that the editor version could not. \* Runtime project settings now allow you to remove specific fragments from the dropdown menu, allowing you to "disable" certain fragments for a project if the project has deemed a specific fragment should never be used. \* Certain rotations can now be disabled through the project settings. This allows projects to go back to traditional 0-90 degree's without making their own or modifying the drag widget. \* \*\*GetLocalInventoryComponent\*\* can now be altered from the runtime project settings to retrieve the inventory component from the player controller. ## Fragments Fragments dropdown menu's filtering is now more advanced. \* For item asset fragments, it will hide all fragments that return false through \*\*SupportsItemAsset\*\* \* Fragments can now opt out of the dropdown menu by overriding \*\*DoNotShowInDropdown\*\* and returning true. Useful for fragments that are only applied during runtime. \* The \*\*CompatibilitySettings\*\* fragment has been slightly reworked, enabling far more customization. \[\*\*Documentation\*\*\](/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings.md) has been added ## Inventory Component \* Every function is now categorised under "Inventory Component" to help organize all the functions into one dropdown. \* Improved support for the inventory component being used on the player controller. \* The \`ItemEquipped\`delegate will now trigger on clients when they receive their container data. \* The client RPC for \*\*MoveItem\*\* has been significantly reduced and scales far better. It now passes the \*\*UniqueID\*\* of the containers and the client is now responsible for resolving them on their end, rather than sending the full container settings struct through the RPC. \* Added two new functions; \*\*AddContainer\*\* and \*\*RemoveContainer\*\*. \* Added two new delegates for these functions; \`ContainerAdded\`and \`ContainerRemvoed\` ## Bug fixes \* Fragments from the item assets \*\*ItemStructFragments\*\* were not being appended to item structs. \* The item struct title was not being updated to match the overriden name, if one was assigned. \* \*\*GetItemsVisual\*\* was not functioning correctly \* Listeners were not being removed correctly \* Item instances declared in the item struct with \*\*ConstructOnRequest\*\* set to true will not receive the \*\*ItemID\*\* \* Adding a tag to a tile inside of a container that didn't have the tile tags fragment would cause a crash. \* The drag widget would be massive for a few frames on some computers. \* Rarity color sheet was not working on sub classes of the inventory component. ## 3.2.1 Bug fixes \* Changing an items shape through the shape editor would not properly call \*\*BakeShapes\*\*, leading to the shape not getting applied. \* \*\*BP\\\_Interactable\*\* had not been updated to use the new \*\*RemoveListener\*\* function. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.2.2.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0.md). # 2.4.0 Engine support: 5.3 \*\*\* ## Example Project \* The UI styling has been reworked. \* Added example for tracking tag values on equipped items, such as an armor stat. ## Widgets \* Custom shaped items can now have padding and rounded corners. An object has been added that stores all the information for each item to save on performance. \* Container widgets can now override their tiles default brush settings. \* Added a \*\*GenerateItemIcon\*\* macro (Only available to widgets) ## Crafting A crafting system has been added. It is important to note that the crafting system has been designed to be 100% removable and the inventory system has zero reliance on it. If you do not want a crafting system and want to reduce the size of your packaged game and/or don't want to deal with the bloat, the system has been contained within a separate folder. If you are updating your project and want to use the crafting system, you will want to go into your project settings -> Asset Manager and add a new index and set "Primary Asset Type" to "CraftingRecipes", set the asset base class to \*\*DA\\\_CoreCraftingRecipe\*\*, then go into Directories and add all locations where you might store your recipe's. \[\*\*Documentation for the crafting system\*\*\](https://inventoryframework.github.io/crafting/) \* Added crafting category to the content browser context menu ## Bugs \* An item actor would not destroy itself if it had to stack with another item when looted through the quick loot options. \* \*\*TryAddNewItem\*\* would not apply the correct rotation in some scenarios. \* The ItemAdded delegate would not have the most up to date version of the item struct. \* When dropping an item, you could get spammed with "UObject is data-only. No item driver available." \* \*\*GetItemDriver\*\* was using the wrong object class for its object paramater. \* the \*\*SellItem\*\* function helper was not setup correctly, leading to clients not being able to use it. \* Added a temporary solution to icon generation crashing the engine. If you are still crashing, you'll want to increase the delay inside \*\*WBP\\\_InspectDebug\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.4.0.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1.md). # 2.5.1 Engine support: 5.3 \*\*\* ## Inventory \* Sorting has been slightly reworked and is much more reliable. The Async function is no longer deprecated. \* Added \*\*GetItemRef\*\* macro for blueprints. \* Added \*\*GetItemsTags\*\* and \*\*GetItemsTagValues\*\* helper functions. \* Added \*\*IsItemEquipped\*\* helper function. \* The deprecated inventory component has been removed from \*\*BP\\\_ItemActor\*\*. \* \*\*MeetsCurrencyCheck\*\* now passes the buyer component, so designers can use external systems to use as currencies. ## Widgets \* Added the option to disable dragging on item widgets. \* Improved how container widget variable is set. ## Equipment \* When an item is equipped, two interface events will be called on either the player or the spawned blueprint, depending on the settings. The equipment documentation page has been updated to include a new "Events" section. ## Bugs \* Item widget would spam errors if a craft widget had to generate an item icon. \* Dragging an item widget with no hosting container widget could crash the engine. \* \*\*CheckCompatibility\*\* was not checking asset tags and tag values. \* Data base search was not checking asset tags and tag values. \* Looting a stackable item as a client could cause a crash. \* The Preview Actor was not resetting master pose reference on skeletal meshes. \* \*\*GetNearbyItemsDirectional\*\* was wrapping to the next line if the scan went to the border of a container. \* \*\*GetFirstAvailableTile\*\* could return invalid rotation enum \* Context menu was showing the Drop and Destroy option on items they did not have authority over. \* Listen Server could no longer interact with chests. \* ItemUnequipped delegate was firing off after the item had been removed from the inventory, leading to some functions not being usable after the delegate. \* Moving items around in some orders could cause the incorrect item data to be removed. \*\*\* ## Color Sheet: \*\*functions\*\* - \*\*Variable\*\* - \*\*category\*\* - \*\*class\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.5.1.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files.md). # Modifying Critical Files {% hint style="danger" %} Modifying critical files has its pro's and con's. Removing data is not recommended unless you are ready to fix any problems it might cause. Adding data should not be a problem, but there are some important things you must keep in mind. If your project is single-player only, adding data is a lot safer as there's no network bandwidth you need to manage and no replication you need to manage. {% endhint %} This page covers what is safe, dangerous or optimizations you can perform to critical files this system relies on. \*\*\* ## DA\\\_CoreItem This file is very safe to modify and is intended to be modified. Though it is recommended to make children for each type of item you will have (Weapons, consumables, armor, etc). Though there are several functions you might have to update if you remove any variables or functions. Remember to use soft references as often as possible. In the base plugin there are a lot of children of this class as examples. All of which are safe to remove if some don't fit your project, though I recommend giving them a quick look-over to explore what differences were made to them. \*\*\* ## FS\\\_InventoryItem This struct will eat up most of your network bandwidth, so adding anything to it can be dangerous. Anything being removed from this struct might require a decent amount of reworking some functions. \*\*\* ## FS\\\_ContainerSettings It is not recommended to remove anything unless you are certain you won't need it. Most of the data, other than the tile map, is extremely small. This struct does contain some small features, like TileTag's, not all projects need this feature, so something like that can be removed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/drag-and-drop.md). # Drag and drop \*\*\* A lot of the information \*\*PerformDrop\*\* function needs to do its calculations and logic should be stored in \*\*W\\\_Drag\*\*. This is because setting and resetting all that information for all the tiles to optimize memory is simply just so much hassle compared to just putting your stuff in the drag widget, which is always just 1 of so it’s always optimized for memory and no hassle in managing it. \*\*\* \`IFP\` takes a similar approach to the default drag and drop operation, but slightly modified to get around 2 hard coded practices in the engine: 1. Drag and drop visual has interpolation that can not be overriden. 2. Drag and Drop operations will only work while holding the drag button, then attempt to drop it the moment that key is released. Where as in some cases, like with gamepad navigation, you want to fully press and release the drag button, move the cursor to its destination, then press and release the button again to perform the drop operation. > It is not possible to completely abandon the engines drag and drop system, because the editor tools get a custom viewport that does not play well with the drag widget that comes with the plugin, so editor tools will not support the custom \`IFP\` solution. Inside the inventory components class defaults, there is a setting to toggle point 2 from the default behavior and to \`IFP\`'s custom implementation. If you want to change this behavior during runtime, you'd want to call \*\*GetLocalInventoryComponent\*\* -> \*\*UseDefaultDragBehavior\*\* To achieve this, item widgets have a \*\*StartItemDrag\*\* and \*\*StopItemDrag\*\* functions, which will handle either the custom implementation or default. Then a custom set of delegates will be called over the default \*\*OnDrop\*\* and \*\*OnDropCancelled\*\*. The widget that is now responsible for handling navigation and input handling is the container widget. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/drag-and-drop.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings.md). # Compatibility Settings The \*\*FCompatibilitySettingsFragmentBase\*\* is a simple struct which contains one overridable function; \*\*PassesCompatibilityCheck\*\*. When you execute \*\*CheckCompatibility\*\*, it will check all fragments inside the container that are children of \*\*FCompatibilitySettingsFragmentBase\*\* and if any return false, the item is not considered compatible with the container. ![](https://varian.gitbook.io/files/Is4qo2QPOEBwVlelg56M) \## Example The plugin comes with a fragment called \*\*FCompatibilitySettingsFragment\*\* and \*\*FTagQueryCompatibilitySettings\*\*, which can both be used as examples as to how to make your own compatibility settings fragment. They can be found inside \*\*CF\\\_CompatibilitySettings.h\*\* file. ![](https://varian.gitbook.io/files/QMlqLTN6FYfXdHrBlSjh) ![](https://varian.gitbook.io/files/stmPpKmzYP32vDXeeSFF) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags.md). # Tile Tags The tile tag fragment is a simple way of adding tags to specific tiles inside of a container. In the base plugin, this system doesn't do much of anything, only being used to hide specific tiles to create custom shaped containers. Tags can be added and removed with the \*\*AddTagsToTile\*\* and \*\*RemoveTagsFromTile\*\* during runtime or edited in the details panel while in the editor. Adding and removing tags will call two delegates: 1. \*\*AC\\\_Inventory\*\* -> TileTagsAdded 2. \*\*AC\\\_Inventory\*\* -> TileTagsRemoved Binding to these two delegates will let your code respond to any tag updates. An example can be found in \*\*WBP\\\_DemoTile\*\* -> \*\*Construct\*\* ## Networking Even though the \`TileTag\` system is automatically replicated and can be modified during runtime, it is not recommended to overuse it for multiplayer games. This system can start eating up a lot of bandwidth very quickly, but this of course depends on the scope of your game. ## Use case Like mentioned above, this is primarily used to create custom shaped containers by hiding specific tiles. But this has more use cases that some people have used it for: 1. Locking tiles and unlocking them based on some in game reward or event. 2. Empowering items that are in "empowered" tiles. 3. Items durability slowly improving while in a specific tile. Some have even used the size of an item as a trade-off. Larger items would take more space, leaving the player with less space to carry other items, but the larger items could then occupy more of these beneficial tiles and gain these positive perks. ## Optimizations If your container is large enough, you might want to enable \*\*OptimizeForGameThread\*\*. This will fill the array so it is 1:1 with the tile map, allowing you to instantly retrieve a tiles tags. Leaving this disabled means that the entire array has to be searched until the appropriate tags for the tile can be found. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/tile-tags.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors.md). # Setting up vendors \*\*\* To have a inventory component be set to vendor, you will want to go into the component settings and set \*\*InventoryType\*\* to \*\*Vendor\*\*. Right now, the system only considers items that are children of \*\*IDA\\\_Currency.h\*\* as viable currencies that can be exchanged for a vendor item. \\ Prices are calculated inside \*\*FL\\\_InventoryFramework.h\*\* -> \*\*GetItemPrice\*\*, and the function that evaluates if a player can afford an item is \*\*AC\\\_Inventory.h\*\* -> \*\*CanAffordItem\*\*. Remember, you can override an items price inside their override settings. The system by default has an array of currencies which players can use to buy items, but it does not by default provide a way of allowing the player to select which currency to use to buy or sell an item. It simply uses the first available currency it can find. It's up to you to implement that sort of logic. Most games tend to have vendors keep track of how much money the vendor has, then when you sell an item to the vendor they spend their own currency and grant it to the player. There are three vendors in the demo, each showing a different way of handling the vendor logic. If a logic error occurs, for example trying to give the player currency, but they do not have enough space in their inventory, you can call a delegate called \*\*CurrencyAdditionFailed\*\*. This is where you might want to implement some sort of mail system or queue system, as it feels pretty bad for players when they sell an item and they don't get their currency for it. The demo does not include any system for handling this problem. There are many ways of handling vendor behaviour. Nearly every game handles it slightly differently, which is why the framework does not try to handle any of this logic for you at a C++ level. Instead, there are three points in the system where you can inject your own custom logic and rules for handling vendor interactions. 1. The function \*\*AC\\\_Inventory.h\*\* -> \*\*CanAffordItem\*\* will call a interface function \*\*I\\\_Inventory.h\*\* -> \*\*MeetsCurrencyCheck\*\*, this simply asks the owner of the component what they value the item as. 2. You can make a child of \*\*BP\\\_AC\\\_Inventory\*\* and override the \*\*CanAffordItem\*\* function to implement your own custom logic. 3. The buyer and seller will receive a delegate on both the server and client either after or before the transaction, the notify is handled inside of \*\*WBP\\\_Tile\*\* -> \*\*PerformDrop\*\* -> MoveItem. The delegate is where you would perform any currency exchange, and since the vendor belongs to the server, it's allowed to call \*\*TryAddNewItem\*\* if you want to give either the vendor or player currency after the transaction. ## Using the crafting system as a vendor A fascinating trick some people have done is using the crafting system as a "vendor". Technically, this is more performant and could potentially be easier to manage. But the vendor will not have a grid of any sorts and will require you to setup most of the logic. This simply revolves around creating the illusion to the player that they are "buying" items, where in reality they are crafting them and using currency as the crafting ingredient. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers.md). # Templates for inventory and containers IFP features two different types of templates; 1. \*\*Inventory template\*\* - This is a data asset that simply hosts an array of \`ContainerSettings\`. A inventory component can assign a template data asset to use instead of its own \`ContainerSettings\` array 1. This is soft referenced by the inventory component. To async load it, you can call \*\*LoadItemAssets\*\* 2. \*\*Container template\*\* - This is a fragment that can be assigned to a container and it will point to a data asset which will be used instead of its own settings. ## When to use The primary use case of this system is for teams, or large number of actors who share similar inventories. For example, the player pawn is a critical class in nearly every project, so many team members might be fighting for write-access. By making the inventory component use a separate data asset as a template, the designer who's working on the inventory does not need to fight for write-access on the player pawn. This can also be used in combination with loot tables, for example creating a template for AI, and the templates containers use a loot table to determine what items should populate that template. For example, if the AI is a wolf, then populate its inventory with meat. If the AI is an orc, populate its inventory with weaponry. ## Serialization To prevent templates from replacing any containers you've saved, \*\*StartComponent\*\* will automatically reasign the \*\*InventoryTemplate\*\* variable to null. The \*\*InventoryTemplate\*\* variable has the \`SaveGame\` metaproperty assigned, so certain serialization solutions will automatically remember to reasign it to null. But if you aren't using a serialization solution that utilizes that metaproperty flag, you will want to manually remove the inventory template when loading a save \\\*\*\*\*before\*\*\*\\\* calling \*\*StartComponent\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions.md). # Creating custom functions Once you’re comfortable enough in the system to make your own functions and/or change the current functions, here are some things to keep in mind. You should always assume an item does not have a widget version of itself. If you need access to the widget of an item, you can use \*\*GetWidgetForItem\*\*. Remember to check if the widget is valid. Widgets also can’t be transported through a network, so if multiplayer is important to you, your server functions can’t rely on data from widgets. \*\*\* ## Best practices \* Do not rely on widgets being valid. Your code should as often as possible rely on data from the inventory component, rather than relying on using the widgets as a proxy. \* In most contexts, you should assume the data asset is loaded and just fetch the \`ItemAsset\` variable and assume it has been set. If it isn't, you are then trying to work with an inventory component that hasn't loaded all the items inside of it. \*\*\* ## Finding Items Finding an item is a very common scenario when you start making your own functions. The container's \*\*TileMap\*\* combined with an item's \*\*UniqueID\*\* is the most reliable way of finding items. The component includes a function to get an item at item at a specific index of a container called \*\*GetItemAtSpecificIndex\*\*. \* The \*\*UniqueID\*\* is the most reliable method of finding a very specific item, container or item component, other than a direct reference to the item, container or item component, but even then a direct reference might get outdated if the player moves the item or modifies it in some way. The \*\*UniqueID\*\* is only updated for containers and items if they are moved to a new component. You can update a outdated item struct by calling \*\*UpdateItemStruct\*\* \*\*\* ## Network optimizations It is recommended, where ever possible, to use the item or container \*\*UniqueID\*\* instead of the struct in your RPC calls, and then have your server use the \*\*UniqueID\*\* to figure out which struct to use. ![](https://varian.gitbook.io/files/Een0qBWelQYnLJTV5JXt) Here you can see 2 sets of RPC calls. One is \*\*ReduceItemCount\*\* (indicated in red), which is passing the item struct to the server and then to the client. The other is \*\*IncreaseItemCount\*\* (indicated in blue), which is passing the \*\*UniqueID\*\* to the server and the server is then using that \*\*UniqueID\*\* to resolve what item we are trying to modify. Switching to using the \*\*UniqueID\*\* method reduced the RPC size from around 75 bytes down to 13. ||| The only downside is that it is not possible to verify if the client has illegally modified it's data, and it's very difficult to verify that the data inside the item/container are synced. It is up to you whether that is a big enough problem to do this. Some anti-cheat methods already do a very good job at preventing clients from modifying the games data with external tools. If you need to validate the data, you can have the server function still accept the full item/container struct, validate the data, then only pass the \*\*UniqueID\*\* to the client. We covered that \[UniqueID's scale\](/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work.md#unique-id) extremely well on another page, but to give you an idea of how well it scales, here's an example ![](https://varian.gitbook.io/files/FuF7HiVUU1phdzzYxciJ) These are two functions using an array with 5 entries of \*\*FS\\\_UniqueID\*\*'s (Blue) and an array with 5 entries of \*\*FS\\\_InventoryItem\*\* (Red) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments.md). # Fragments Fragments are instance editable structs, which can be dynamically added, removed and modified on containers and items. This allows you to remove data from items and containers that wouldn't need said data in the base struct, giving you a chance of optimizing the memory footprint of your game and giving you a platform to add any data you want to both containers and items. This data has native serialization support, so it supports all save systems. {% hint style="warning" %} Unfortunately, instanced structs can only be made through C++ {% endhint %} \*\*\* ## Writing fragment code The plugin has several examples of handling fragment code. The biggest highlights are the template functions provided by the \*\*FL\\\_IFP\\\_FragmentHelpers\*\* library. ![](https://varian.gitbook.io/files/57GTxd6LpRuaewzGXrLA) For simple examples, I suggest looking at \*\*Internal\\\_AddTagToItem\*\* and \*\*StartComponent\*\* or the Add/Remove/Override functions inside the fragment manager. The majority of the time, you are just using the \*\*FindFragment\*\* template function to get a pointer to a fragment to modify it. Depending on how frequently the fragment is used and how advanced you want to get, you might want to create custom functions for modifying the fragment. The tag fragment being the prime example of this. If you don't want to do that or don't need custom functions, you can use the generic \*\*OverrideFragment\*\* functions ![](https://varian.gitbook.io/files/64mqH1yNAG9VwagAeGbu) \*\*\* ## Inheritance Fragments follow a specific inheritance setup to allow both containers and items to share certain fragments to reduce duplicate fragments that achieve the same thing. Both the container and item use \`FCoreFragment\`, but you should most of the time assume the struct is \`FContainerFragment\` or \`FItemFragment\`, depending on which struct you are working with. \\ The reason why they use \`FCoreFragment\` is to allow both to use fragments that apply to both structs, such as the tag fragment. > In a future update, I will be trying to customize the dropdown menu to exclude fragments based on certain settings. For example, excluding the Random Item Count fragment from the dropdown if the item doesn't support stacking. That customization plans on using the virtual functions found on \`FCoreFragment\` to handle that. \*\*\* ## Fragment Manager Due to instanced structs being so young in the engine, I did not feel comfortable putting all the logic around it in the main inventory component. That's why the \*\*AC\\\_FragmentManager\*\* was made, who will handle everything related to fragments. The \*\*AC\\\_FragmentManager\*\* is automatically added to the actor for you if it's missing. But if you want to subclass the fragment manager, you can manually add the component to your actor and it'll be used. Alternatively, you can assign a fragment manager class inside the inventory component class defaults. The inventory component has a \*\*GetFragmentManager\*\* function, which hosts all non-static functions related to fragments. \*\*\* ## Structure and naming convention Since fragments are only accessible to C++, this is my workflow for enabling as much C++ and Blueprint support: 1. Parent your fragment to \`FCoreFragment\` if you want it to be shared between both containers and items. Otherwise, you specify which parent you want. 2. Every time you make a fragment, you make a new class and put a function library inside of it to give helper functions to Blueprint programmers. This class's prefix should be \`IF\_\` (Item fragment) or \`CF\_\` (Container Fragment). If it's a global fragment, like the tag fragment, it's just \`F\_\` 3. Always create getter functions. If you are working in single player, I'd recommend making setter functions to simplify your work flow. 4. I will not be supporting multiple instances of the same fragment within the same array. Rather, you should have a fragment contain an array of whatever data you want to have multiple copies of. \*\*\* ## Key functions to override \* \*\*IsCompatibleWithContainer\*\* - Determines if the fragment is compatible with the container it's being placed in. \* \*\*IsCompatibleWithItem\*\* - Determines if the fragment is compatible with the item it's being placed in. \* \*\*SupportsItemAsset\*\* - Is the fragment allowed in the item asset? Keep in mind, all code utilizing this fragment should not assume the fragment can be in either the item struct or item asset and should not have its data modified while in the item asset. \* \*\*ShouldRemoveFragment\*\* - Whenever a fragment is modified, this function will check if the fragment should be removed. For example, if the fragment has no data inside of it or is no longer being used. \* \*\*MergeWithFragment\*\* - Handles how two fragments are merged. \* \*\*GetNetworkingMethod\*\* - How should the fragment be replicated? \*\*\* ## Networking Fragments use the same networking method as the rest of the inventory. They do not use traditional replication, but rather has RPC's forward all modifications to relevant clients. The fragment manager has six functions for adding, removing and overriding fragments for both containers and items. \*\*\* ## Fragments or data-only traits Fragments are pure data structs that can be added to the container, item struct and/or item asset, where as traits are data-objects limited to just the item asset. The main difference is the simplicity of creating traits and working with them. Fragments are more complicated and Blueprint support is limited, where as traits have full blueprint support and are simpler to work with. Traits main limitation is not changing their variables during runtime, since every item sharing one item asset will have that change reflected for all of them. But that also means that their memory usage is highly efficient. Remember, a unique trait instance is not created per item struct, it's created per item asset. Meanwhile fragments are created per item struct, allowing them to be changed during runtime. (This is assuming the fragment in question is not a fragment in the ItemAssetFragments array, as that array also shares the same limitation of not being mutable during runtime but also being memory efficient.) I generally use traits for everything that are only related to the item asset and is static data that does not change during runtime. \*\*\* ## Performance Constructing a fragment is virtually free. So it just comes down to what you do with the fragment that can cause performance issues, for example; hard referencing assets. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/fragments.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets.md). # Creating custom widgets \*\*\* ## Containers, Tiles and Items These three widgets are the ones you'll most likely end up working with the most. To improve the hierarchy, I've tried to not add any components that aren't necessary. Those that are essential for the widgets to function, I've added Getter functions that request the essential widget. This way you're design hierarchy can be in whatever design you want and still use the parent widgets. But this does mean you need to override those functions and passs the widget through as a variable. All three are abstract, so you must either use the widgets in the demo folder or make your own children. {% hint style="info" %} Technically, these requirements can be ignored, depending on what features you need and don't need, but you might get some errors. For example; size boxes aren't really required as you can set the sizing on the image, but it requires a bit more work to setup correctly. {% endhint %} ### Containers \* Border is needed for scrolling support and sizing (\*\*GetBorder\*\*) \* ContainerOverlay holds the item widgets (\*\*GetOverlay\*\*) \* Grid panel holds the tiles (\*\*GetGridPanel\*\*) \* (Not mandatory, but is recommended) - Scroll box is needed for scrolling (\*\*GetScrollBox\*\*) ### Tiles \* There are no requirements in the tiles hierarchy. You don't even need an image! To control the sizing of the widget, a function called \*\*SetWidgetSize\*\* should be overriden and handle the sizing logic from there. ### Inventory Item \* size box to control the size (\*\*GetSizeBox\*\*) \* Image for the item icon (\*\*GetImage\*\*) \* (Not mandatory, but is recommended) - Loading Throbber for indicating the item is loading (\*\*GetLoadingThrobber\*\*) This widget is updated through the \*\*I\\\_ExternalObjects\*\* interface. You can see an example of how these updates are used inside \*\*WBP\\\_DemoInventoryItem\*\*. The hierarchy inside your custom widget can be structured in whatever way you want, but they must contain the above mentioned widgets inside the hierarchy. Nearly every function inside these widgets are designed to be overriden for maximum customization. It is advised to read the \[ExternalObjects\](/varian-docs/inventoryframework/inventory-framework/systems/external-objects.md) page to understand the \*\*I\\\_ExternalObjects\*\* interface. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables.md). # Loot Tables \*\*\* There are tons of ways to handle loot tables, but ultimately all they do is add and/or remove items from an array. The abstract design of this system does try to provide you with an interface that allows you to create any type of loot table system, but that does mean that the loot table is slightly more complicated than some other loot table systems. Here are the design parameters that the loot table system follows: \* Handled through a actor component and instanced objects. This means you can create custom loot table systems and even mix multiple types of loot tables. \* Usable on any actor with a inventory component, including item actors, interactables, player character, etc. This includes allowing item data assets to declare default loot tables. \* Items added through loot tables should also have their loot tables imported, meaning recursive loot tables. \* \`Modular Game Feature\` (\`MGF\`) support. This means that loot tables should be extendable through content updates/DLC/expansions. The loot table system comprises of 2 parts; A component (loot table) and an array of instanced objects (loot pools) that live inside the component. {% hint style="danger" %} Game features are still labeled as "Beta", so do expect some bugs around \`MGF\`'s. But they have been battle tested extensively through Fortnite, last time I heard they had over 200+ \`MGF\`'s. This system does not rely on \`MGF\`'s, it's simply meant to be utilized by them. {% endhint %} \*\*\* ## Loot table component The loot table component is the heart of the loot table system. When the inventory component calls \*\*StartComponent\*\*, it will first try and find any loot table components and run \*\*PreInventoryInitialized\*\* and forward that to the \`Loot Pool Object\`'s. Most functions will not work as expected, because this is before anything is initialized. You are just expected to manually modify the \*\*ContainerSetting\*\*'s array as if you were modifying it yourself by hand. Most changes will be done here. Once \*\*StartComponent\*\* is finished, it'll call \*\*PostInventoryInitialized\*\*. All functions will now work just as normal, but you are expected to add most items during the pre-initialization phase. \* You can have as many loot table components on an actor as you want. This is primarily used for better \`MGF\` support. \* Loot table components are sorted by their \*\*Priority\*\*. Higher priority components are ran first. This is to allow future components added through \`MGF\`'s to increase the chances of new content being prioritized. But keep in mind, this gives some loot tables a slight bias over others. \* Loot table components are automatically destroyed on clients. They are only utilized by the server. \* The \*\*PostInventoryInitialized\*\* function does open up the possibility of doing async loot tables or spacing out loot additions. This should really only be considered if you are doing hundreds of items. It is of course up to you to handle when you start this async operation and implementing it. \*\*\* ## Loot Pool object These objects are what actually try to modify the inventory components \*\*ContainerSetting\*\*'s, store any data and run any meaningful functions. These are stored in the loot table components \*\*LootPools\*\* array. By default, this has nearly nothing inside of it. The plugin comes with 2 examples, a simple loot pool and a advanced loot pool. \* Simple example: Contains an array of items, each has a percentage to spawn and the order is then randomized. \* Advanced example: This loot pool object has the ability to be globally modified during runtime through \`MGF\`'s. This system utilizes a world subsystem that only exists on the server and \`MGF\`'s can dynamically add and remove items from the subsystem. The subsystem has a map of tags and this object fetches the items to use through this tag. This means that these advanced loot pools can be expanded on in future updates very easily, without referencing any assets and allowing the loot to have the same probability as other items in the pool, where as the simple example will always have some bias as one loot pool has to be executed before the new ones added through \`MGF\`'s are executed. Remember, \`MGF\`'s are one-way referencable only, in your base game, you shouldn't reference content inside of \`MGF\`'s. \* This system also has the ability to dynamically add/remove items from loot pools during runtime, so you could for example have a chest that has more items inside of it, depending on if the player has defeated a specific boss. \*\*\* ## Modular Game Features Some games using IFP might get content updates, DLC, expansions, something that adds content to the game, such as items. Loot tables is the primary way that most games handle additional content post-release. \* It's not recommended to put item assets into MGF's because it highly complicates how the inventory of all actors is managed. What if the player is wielding a weapon added through a MGF and the MGF gets disabled? Do you delete the item? When it's enabled again, how would you restore it? If you do decide to add item assets through MGF's, then you are responsible for managing inventories if it's ever disabled. The only exception to this is if you are permanently enabling this MGF, like an expansion. Then this scenario won't ever happen. \* By default, there are 2 ways to add new content to loot tables. One is to add another loot table component to actors. This follows the same procedure as the standard \`Add Components\` action MGF's come with. The other is used by the advanced example loot pool object and that is registering more items to the subsystem. If you don't like either option, then you can always implement more methods by creating new loot table objects. \*\*\* ## Overriding the loot table system If you want to completely override, customize or even implement your own entire custom loot table system, that is also quite easy to do. Just simply override the \*\*ProcessLootTablesPreInitialized\*\* and \*\*ProcessLootTablesPostInitialized\*\* functions in your inventory component. \*\*\* ## Pre-loading assets Loot pools have the ability to start loading any assets before the loot table is processed by calling \*\*PreLoadAssets\*\*. It is recommended to roll your spawn chances here, then only load the assets that succeeded their spawn chance and populate a second array with these items. This way you don't uneccessary load any assets that would have failed their spawn chance. \* By default, there is nothing calling this function. It is up to you to decide when and how this is called. \*\*\* ## Item Asset Loot Tables To have item assets have loot tables, you must override the \*\*GetLootTables\*\* function and pass in an array of loot tables. An example can be found in the \`DA\_Equippable\` and \`DA\_Weapon\` item assets that come with the plugin. When \*\*StartComponent\*\* is called, it'll check any item that has the \`IFP.Initialization.IncludeLootTables\` tag and then create loot table components with the same settings as the ones declared in the item asset and attach them to the same actor that the inventory component belongs to. This tag is then removed afterwards. Loot tables can get the item they were created from and its containers through the \*\*GetParentItem\*\* and \*\*GetParentItemsContainers\*\* functions. Loot pools have a \*\*GetLootTable\*\* function, so loot pools also have access to this data through this function. \*\*\* ## Data Registry \`MGF\`'s reference a "data registry" which seem to have been introduced around 4.26, but at the time of writing, there is very little documentation and examples of how it works or how best to utilize it, but the lead engine programmer at Epic did discuss it in \[this video\](https://www.youtube.com/live/7F28p564kuY?si=xX839PLPJHtXyZjN\\&t=5027) and he even refences a loot table system. I won't be using data registries in the example project for now, because some of the functions around it are still labelled as experimental and due to the lack of documentation or any sources of how to best utilize it. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/loot-tables.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation.md). # UI Navigation UI Navigation refers to an input such as a controller joystick, gamepad or arrow keys to attempt to navigate tiles and items inside of a container. This is handled through \`EnhancedInput\` and the \`Container\` widget. > This documentation covers just container and item navigation. Things like context menu's and so forth fall under common navigation, which has a mariad of ways to handle and there are plenty of resources on how to handle common UI nagivation. To handle navigation between multiple containers, either fill out the \`Navigation\` settings in the container widget instance or handle it through the \`NavigatedOutOfBounds\` delegate which will let you know which direction the user last tried to navigate. For example, if they tried to go down, but no valid tile was found, this delegate will go off and say they tried to navigate downwards. You could now grant focus to the container below the container that currently has focus. ![](https://varian.gitbook.io/files/PWQZ59jkvXs1yRXBASIn) \> Input action and mapping context references are automatically assigned to the ones that come with \`IFP\`. The navigation system fetches the class defaults to know what action and context to use. To customize them, go into \`BP\_AC\_Inventory\` and change the settings inside of the \`Settings -> Input Settings\` category. {% hint style="danger" %} Important As of 5.4, there is a bug with all the properties in the \`Navigation\` category. Whenever you assign new values, you must recompile and resave the asset yourself. The bug is that the asset is not being marked as dirty and in need of recompilation. {% endhint %} \*\*\* ## "Virtual" cursor To simplify a lot of the logic, the container widget will take control of the cursor to act as a "virtual" cursor (Handled in \*\*NativePaint\*\*). \`CommonUI\` does the same, although they seem to have a "synthetic" cursor. As of writing, I am not able to find any sources, other than reverse engineering \`CommonUI\`, on how to make your own virtual cursor. The container will return control to the cursor if any movement is detected (\*\*OnMouseMove\*\*) \*\*\* ## Dynamic navigation In some cases, containers are added to the screen during runtime, like opening a chest. In this case, the navigation panel above won't work. To override the above settings, you can assign override containers for each direction (for example, NavigateRightContainerOverride variable will override the right input navigation). Here is an example of how that would work: ![](https://varian.gitbook.io/files/RVDKCiI4sF2PqDrVlp3K) \*\*\* ## Customizing Navigation If you wish to completely override the navigation system for \`IFP\` or customize it, there's a small list of functions you can override. Container widget functions: \* \*\*OnKeyDown\*\* (All logic starts here) \* \*\*GetNextItemToNavigateTo\*\* \* \*\*GetNextContainerToNavigateTo\*\* \* \*\*NavigationFocusUpdated\*\* \* \*\*ItemNavigationFocusUpdated\*\* \* \*\*SetCurrentNavigatedItem\*\* Item widget: \* \*\*ItemHighlightUpdated\*\* \* \*\*StartDragItem\*\* \* \*\*StopDragItem\*\* \* \*\*CancelDragItem\*\* \*\*\* ## Scroll Boxes By default, containers will keep the currently navigated tile in view within the scrollbox inside that container. But if you navigate to a new container inside your inventory UI that is not in view, you need to handle that, since that is outside of the containers code. Here is a basic example from the example projects inventory UI widget: ![](https://varian.gitbook.io/files/idsK7awXqgASgGkUplEl) \*\*\* ## CommonUI \`CommonUI\` is not utilized by the plugin due a few reasons, but the primary reason is the lack of easy customizing the navigation around containers. For example, snapping to nearby items rather than navigating tile by tile. The true questions around \`CommonUI\` that have to be asked is: What does it provide to \`IFP\` that justifies \`IFP\` having a dependency on it? Truly, \`CommonUI\` just provides 2 things: Reworked navigation and new widgets that handle common things. The reworked navigation is great, but lacks customization. The widgets provided by \`CommonUI\` are not beneficial to \`IFP\`. Maybe the example project, but not the base plugin. \`IFP\` can be utilized by \`CommonUI\`. Many people have designed their inventory screen made out of \`CommonUI\` panel widgets. But as of writing, \`CommonUI\` is too complex for beginners, lacks debugging tools and doesn't provide enough to \`IFP\` to justify being dependend on it. Many people do not want or like \`CommonUI\` and I dont want to force people to use it. ### CommonUI integration > This section is a work-in-progress. I personally do not use \`CommonUI\` and very few people seem to be using \`CommonUI\` so some details and steps might be missing. \* As pointed above, the only thing \`CommonUI\` provides to \`IFP\` is the reworked navigation. But their navigation only searches for \`CommonActivatableWidget\`'s. Depending on how you want to control your navigation, you might want to reparent \*\*W\\\_Container\*\*, \*\*W\\\_Tile\*\*, or \*\*W\\\_InventoryItem\*\* to \*\*UCommonActivatableWidget\*\* so \`CommonUI\`'s navigation can detect those widgets. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ui-navigation.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/input-nexus/nexus-component.md). # Nexus Component This component is the host of all \`InputLink\`'s and manages them. It's also responsible for link bundles, mapping contexts and buffering inputs. ## Buffering inputs To open and close an input buffer channel, simply call \`OpenInputBufferChannel\` and \`CloseInputBufferChannel\`. Go \[here\](/varian-docs/input-nexus/input-link/input-buffer.md) to read more about how input buffers work. \* You can check if a channel is open through the \`IsBufferChannelOpen\` function. ## Managing inputs \* To completely disable or enable a \`NexusComponent\`, call \`ToggleInputEvents\`. You can also call the native \`Activate\` or \`Deactivate\` functions, which will toggle the input events appropriately. \* To disable or enable an input action, call \`ToggleInputEventsForInputAction\`. \* Multiple \`NexusComponent\`'s are supported on an actor, but it's up to you to retrieve the one you want. You might want to create a list of what type of input logic the pawn will use and what kind of input logic the controller will use.\\ For example: \* Controller: Handles UI logic, such as the escape button summoning the escape screen. \* Pawn: Handles movement and interaction. In the case that the player possesses a vehicle pawn, this will automatically disable the other pawns movement and interaction events. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/input-nexus/nexus-component.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items.md). # Equipping and unequipping items {% hint style="warning" %} This documentation covers the default equipment system. In some cases, you might want to implement your own or use a hybrid solution, which is covered more at the bottom of the page. {% endhint %} \[Deep dive video\](https://youtu.be/Tb7FwW3ri6k) \*\*\* A big problem I try to solve with this system is that I did not want to assume anything about how your actors' meshes are set up, how your equipment setup looked like and I did not want to make a base player or actor blueprint. There are two main reasons behind this decision: First is this allows you complete control over what items are attached to (for example if you have a horse and want to give it armor, but the component is only setup on the player) and secondly is that people might already have a player blueprint hierarchy setup and I did not want to mess with that and some people might not want to use my hierarchy setup. The logic that runs the equipping and unequipping logic is stored in a object and item component called \*\*IT\\\_Equipment\*\* and \*\*IC\\\_Equipment\*\* (if you are unfamiliar with the \[item component system\](/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components.md), I suggest getting familiar with it first) and they use a struct called \*\*EquipmentData\*\*, this struct attempts to solve most issues when it comes to having multiple skeletons, meshes or complex equipment logic, such as having a gun attached to a backpack which is attached to the player character and that gun has a sight attached to it or FPS shooter setups where you have a local arms skeleton and then a full body skeleton. This struct also attempts to keep the system away from hard coding any types of “main weapon” and “secondary weapon” or anything of the sort. I’ve found those types of setups often become cumbersome when a designer wants to add or remove these types of things. Keeping the equipping system inside of a item component provides a modular way for you to allow any item you want to be equippable, or trigger special animations when its added to an items container. It also allows you to easily implement your own system if you want without rewriting C++ code or affecting how the inventory system works at a fundamental level. During my research, I found an astonishing amount of different workflows and processes. It was very daunting to try and solve all of them in one go, and maybe my system isn’t perfect, but it tries to solve as many as possible at once, while still being flexible and adjustable. I recommend reading the comments in the \*\*EquipmentData\*\* struct (Found in \*\*IFP\\\_CoreData.h\*\*) and going through \*\*IC\\\_Equipment\*\* (which is an item component found in the plugins folder Core -> ActorParents -> TraitsAndComponents -> Equipment.) and look at the logic in there to get a better understanding of how the system is using this struct. I would explain it here, but it’s so long and extensive that explaining it in just text and pictures would take too long. \\ This component attempts to copy the system that is used in GAS with its \*\*PlayMontageAndWait\*\* function, which creates an object that handles the animation, but I wanted to keep mine inside of Blueprints. \*\*\* ### Optimizations For weapons and equippables, I've implemented three methods of creating your equipment mesh (Item reperesentation): 1. Blueprint, this allows you to simply use any blueprint you've made as the item representation. 2. Skeletal mesh 3. Static mesh Blueprint's are about 11 times more expensive to spawn than meshes, but are the most customizable. I recommend staying away from using Blueprint's as your item representation whenever possible. For multiplayer, meshes are encouraged even more as they are very cheap to replicate. ![](https://varian.gitbook.io/files/1seM7r4NC3Xw0HPYyu4l) Blueprint ![](https://varian.gitbook.io/files/Xh8qONPtZ3PlsoDPOvM1) Static Mesh Blueprints took 1.5ms, while static mesh only took 0.131ms For skeletal and static meshes, you gain access to most settings you would have in the details panel while editing them in a blueprint regarding Skeletal and Static Meshes The default material section is not available (I assume this is an engine bug?). If you wish to change the default materials, go into Rendering -> Override Materials Notes for optimal multiplayer experience The way Unreal handles replication for attached actors is not the most elegant. When another player becomes relevant for another client, not all attached actors will get replicated within the same frame, and they might not even replicate in the order that you want them to. Leading to odd snapping or pop-in. This could be awkward if you have naked characters and then the clothing around them are blueprints. This is another reason why it's suggested to stay away from blueprints for multiplayer, as with meshes, since they get attached to the actor itself, when it comes time to replicate it theres no snapping or pop-in. All components on an actor are replicated within the same frame. There is always a chance a packet will be dropped, which is again why you should refrain from blueprints as the engine does a very good job ensuring every mesh component is replicated. For every blueprint, you're adding another actor, and another equipment manager component, and more RPC's and more RepNotify's and each of those have a chance to get dropped. These optimizations of course only matter depending on the scope of your game. This more or less serves as an idea of what to focus on during the optimization phase of your game and what you might have to look for. \*\*\* ### Manually labelling items as equipped/unequipped By default, IFP will label an item as equipped or unequipped when an item is added or removed from an equipment container. But in some cases, you want to manually handle this, for example labelling an item that is in a normal grid as equipped. This can be handled through the \*\*UpdateItemsEquipStatus\*\* function. This can accept custom trigger filters to allow for you to filter out what equipment settings to use in the in-built equipment system or to use in your own custom equipment system. \* Whenever an item is equipped, a tag is automatically applied, called \*\*EquipTag\*\*. This can be set in the class defaults for the inventory component. This function is never used in base \`IFP\`, so it is expected for you to handle when and how it is called to equip and unequip an item. \*\*\* ### Events There are two events that can activate when equipping and unequipping an item occurs. 1. The first is the component's \*\*ItemEquipped\*\* and \*\*ItemUnequipped\*\* delegate. This is only called when an item is added or removed from a slot. This is only called on the actor that the inventory component the slot belongs to, so equipping a weapon as a player will have the delegate call on the player, not the weapon. 2. Two interface functions also called \*\*ItemEquipped\*\* and \*\*ItemUnequipped\*\* from \*\*I\\\_Inventory\*\* are called whenever the equipment system spawns or updates the status of an item. For example, equipping a gun so it spawns, then holstering it and unholstering it. \* If your settings have the item set as a blueprint, these events are called on the spawned blueprint. For example, equipping a weapon as the player will have the interface functions called on the weapon, not the player. The inverse of point 1. \* If your settings have the item set as a static mesh or skeletal mesh, the interface functions are called on the player. \*\*\* ### Notes on general equipment system design \* Equipping and unequipping items can get messy, most importantly it can get messy when players start spamming the system with animations, either by quickly equipping and unequipping an item really quickly or equipping multiple items, all trying to activate montages which will interrupt each other. In the demo, items do not play an animation when equipped or unequipped. But they do play an animation when you holster or unholster an item. If you're in multiplayer, the item will also be added to the network queue to prevent clients from spamming the server with RPC's. By default, there is no failsafe if an animation is interrupted as that is something most designers want to implement their own system into. Some designers might want players to be able to cancel animations or cancel the equip if it was interrupted. It is up to you to implement any sort of failsafe if players are finding ways to manipulate this animation cancelling in ways you don't like. \* If you're going to have items visible on your character, it is recommended to have at least one setup for every item that instantly attaches the item to the desired location and mesh. This is so when you load a save, you won't get several animations playing at the same time and overlapping each other. \*\*\* ### Why are all my components getting renamed? The system automatically tries to keep all components attached to an actor with unique names - including attached actors. This is for 2 reasons: 1. Because of how the preview system works. The preview system attempts to reconstruct the actor it's previewing without fully cloning it. There are ways of perfectly cloning an actor, but those are very expensive and come with their own set of problems. The preview system only looks at the visible components on the actor, including attached actors, and reconstructs it. But problems occur if two components have the same name from 2 different attached actors. When the preview system reconstructs the actor, it finds out what component it was attached to, but it needs to know which component that is on itself, it can't use the object reference. This means that if two components have the same name, it'll mess up which component it should attach to. The simple fix to this is to make sure all components have a unique name. The engine already handles this if you attach a component to an actor and that actor has a component with the same name, but it does not do this for attached actors. 2. The engine does not have failsafes when two components on the same actor have the same name and will crash. But to simplify debugging, only a underscore and a random number is added to the end of it. The rest of the name is untouched. \*\*\* ### Where are the items being created? A separate actor component called \*\*BP\\\_AC\\\_EquipmentManager\*\* is created and attached to the owning actor to handle the creation of items. This is handled this way because of replication. Before the system was replicated, this component didn't even exist and the system worked just like it does now. This component is responsible for ensuring items are replicated in the correct order and attaching things in the correct order, in case an item got replicated before the item it is attached to is replicated. \*\*\* ### Common issues Physics is typically the main culprit for the equipment system breaking. If an item or components have physics on by default, they will instantly detach the moment they are initialized. Breaking the entire equipment system. Physics will also cause issues with generated item icons, as that system relies on the attachment hierarchy being correct and detaching things due to physics will break it. \*\*\* ### Custom equipment system It's fairly simple to completely replace the equipment system or use a hybrid solution. To understand the beginning of the chain, the equipment system begins on the actor's Inventory -> ItemEquipped delegate event. This is where you'd inject any modifications to the base behavior of the equipment system. In some cases, it's simpler to just swap out a mesh with a new one. For example, the player might have a default jacket if no other jacket is equipped. In this case, it's much simpler to just use a custom equipment object which holds that other mesh and swap the default jacket mesh with the new one. It all comes down to the complexity of your game. The default equipment system tries to cover \*\*a lot\*\* of different and complex scenarios, thus it has become big and can be overcomplicated depending on the simplicity of your project. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings.md). # Classes and Settings - \[A\\\_ItemActor\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a\_itemactor.md) - \[AC\\\_Inventory\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac\_inventory.md) - \[BP\\\_PreviewActor\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/bp\_previewactor.md) - \[DA\\\_CoreItem\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da\_coreitem.md) - \[Traits and Components\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components.md) - \[W\\\_Attachment Parent\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_attachment-parent.md) - \[W\\\_Container\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_container.md) - \[W\\\_Drag\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_drag.md) - \[W\\\_Highlight\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_highlight.md) - \[W\\\_InventoryItem\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_inventoryitem.md) - \[W\\\_Tile\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_tile.md) - \[WBP\\\_ContextMenu\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp\_contextmenu.md) - \[WBP\\\_Tooltip\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp\_tooltip.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_highlight.md). # W\\\_Highlight This widget is the primary method used for handling the highlight for moving items. An alternative method is used inside the InventoryHelper tool. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_highlight.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp\_contextmenu.md). # WBP\\\_ContextMenu This widget is a good example of a widget that is completely separated from the system, but just uses the item data to interact with the inventory system. You can manage the rules for each button and when they should be visible. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp\_contextmenu.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0.md). # 2.9.0 Engine support: 5.4 ## Deprecated \* Both \*\*GetWidgetForItem\*\* and \*\*GetWidgetForContainer\*\* have been deprecated and replaced with functions with the same name, but are found in the function library. \* This used to have several functions for retrieving the widgets, because in some cases they were more optimal. But now with the ID map system, there is no need to try and optimize this anymore. \* The \*\*CompatibilitySettings\*\* has been updated to use item tag types as the \*\*EItemType\*\* enum has been deprecated \* Since the \*\*EItemType\*\* enum has been deprecated, you should use the tag item type version instead. \* The attachment widget variable in the item struct has been deprecated, is now a part of the external objects system. Use the \*\*GetItemsAttachmentWidget\*\* function instead. \* Override settings Price and SpawnChance have been deprecated. Spawn chance has bee replaced with a tag value while overriding the price is no longer supported. ## Documentation \* Equipment documentation updated. \* \`Working in the System\` -> \`Creating New Items\` has been removed, the contents have been moved to \`Classes and Settings\` -> \`DA\_CoreItem\` \* A loot table system has been added, documentation can be found \[\*\*here\*\*\](https://inventoryframework.github.io/loottables/) ## Inventory \* Container struct title is now much more readable. Can be configured through config settings. \* A new \`SkipValidation\` system for \*\*StartComponent\*\* has been added for both items and containers. This can drastically improve performance (in some cases 40x improvements) when used correctly. \`AC\_Inventory\` documentation has been updated. This system is primarily meant for save files. \* \*\*StartComponent\*\* has been heavily reworked to provide better support for the new loot table system. \* Item Drivers are now included in the \*\*GetObjectsForItemBroadcast\*\* function and now inherit the \*\*I\\\_ExternalObjects\*\* interface by default. \* The MoveItem server RPC is now almost 4 times cheaper. \* \*\*GetComponentByTag\*\* has been moved to C++. Added new helper function for getting the visual for an item \*\*GetItemsVisual\*\* \* The Unequip event has been reworked slightly so it is possible to modify an item when it is unequipped, for example the item tags. \* Added \*\*GetObjectsForItemBroadcastWithInterface\*\* and \*\*GetObjectsForItemBroadcastWithInterface\*\* \* Added \*\*MassSplitItem\*\* \* The \*\*Rotation\*\*, \*\*RandomMinMaxCount\*\* and \*\*OverrideSettings\*\* are now hidden in the item settings depending on settings that would make them irrelevant, such as the container not supporting rotation and item type not being stackable. ## Items \* Some of the item asset functions have been changed to virtual. People who have made children item assets with default containers will now want to override these functions. \* When moving an item to a new container, the attachment widget is no longer automatically removed off the screen. \* Added non-array version of GetObjectByTag/ByClassForItem ## Equipment \* Added a \*\*UpdateItemsEquipStatus\*\*, which allows you to manually declare if an item is equipped. This way you do not have to have an item be in an equipment container to be considered as equipped. \* This can accept custom trigger filters to help evaluate what equipment settings to use. \* Whenever an item is equipped, a tag is automatically applied, called \*\*EquipTag\*\*. This can be set in the class defaults for the inventory component \* Equipment driver can now automatically assign leader poses for skeletal equipment. ## Editor \* When hovering over an item asset icon, the in-game tooltip will now show. The in-built tooltip has been reworked to just accept item data, instead of the item widget to allow editor tools like this to use it without creating an item widget. ## Bug fixes: \* The Item actor could cause a crash if the owner did not implement the \*\*I\\\_Inventory\*\* interface. \* Tile map for other actors was not being initialized correctly. \* Swapping item locations could break collision in some cases. \* The quick loot window could create 2 instances of the same item in some cases. \* Custom shaped widgets would break without a padding and radius object in the item asset. \* External objects on items would have client-only objects, such as widgets, removed when an item was moved during a multiplayer session. \* Dropped item actors would have some data, such as item count, reset or wiped. \* It was possible to split an item in a location that would overlap the original item. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.9.0.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs.md). # Bugs This list is only relevant to the latest version of the plugin. ### Known Bugs \* Instanced structs in some cases can't be modified inside of editor tools, such as the InventoryHelper because the dropdown to open it does not appear. ![](https://varian.gitbook.io/files/IZnFMFPGxxdNbeaxtW09) \* Some tools are causing heavy lag spikes. This is an engine bug, the \`DetailsView\` widget is invalidating itself hundreds of times when it's updated. This issue seems to have started with Unreal 5.4 and was not present in earlier engine versions. \* The "Reset to Default Property Value" button for container settings is not resetting values to their proper defaults and it's always showing for all values, even if the value is set to its default. This is an engine bug. \* The drag widgets sizing is much larger than it is supposed to be for a couple of frames. There is currently a 0.05 delay inside \*\*WBP\\\_Drag\*\* to resolve this. This is a band-aid fix, I'll try to resolve this fully in the future. \* While inside a editor utility widget, the gameplay tags slate widget is not updating properly. The DetailsView widget is riddled with a few bugs as of at least 5.2 when it comes to custom slate struct widgets. The best you can do right now is open the gameplay tag to see what values are inside of it and adding/removing something to update it, then it'll show the values inside the tag correctly. \* In 5.2 and beyond, saving an icon has a chance of crashing the editor. This is happening because Epic modified how this is handled into an async task, but left no delegate for me to bind. For now, a delay is being used instead of a delegate, but on slower computers, the async task might not be finished by the time the delay finishes, causing a crash. If you are crashing, go into \*\*WBP\\\_InspectDebug\*\* and click on B\\\_SaveIcon and find its OnPressed event. You'll find a delay and you'll want to increase it. \* The inventory component might be falsely reporting it might be "corrupted" or a custom property list is not initialized correctly. This is happening because when a component is declared in C++ and then the ComponentClass is set to a blueprint, it starts loading everything connected to that blueprint. Some assets seem to be breaking something inside of UE's loading process and causing issues. I haven't noticed any patterns, but most of the issues seem to occur when a player character is referenced. Because of this, you really have to mind your hard references, or go through the process of removing the C++ version, which I do not recommend. You should be minding your hard references, especially when it comes to the inventory component. ### Common Problems These aren't bugs, but problems that can be misinterpreted as bugs. \* The inspector debugger changes are being set but not being saved after closing the editor. This is because the engine seemingly refuses to label assets as dirty while a gameplay session is active and doesn't label them as dirty after closing the gameplay session. An asset that is dirty will have an asterisk (\\\*) indicating that you have changes that need to be saved, but since it refuses to label it as dirty, it means that you have to manually open the asset and pressing save, even though there is no star indicating that you have changes that need to be saved. This may be a engine bug or is intended, but it seems that there's nothing I can do about this. \* The \*\*WBP\\\_Highlight\*\* widget and \*\*WBP\\\_InventoryItem\*\* widget padding doesn't take into account any scaling their parent widgets have to do (like borders). So if you are getting issues with items being dropped in a different tile or an item not lining up properly, there is most likely an issue with your UMG hierarchy/scaling. You might have this problem with scroll bars most of the time. An easy fix for that is to go into the ScrollBox, go into Scrollbar Padding, let's say the scroll bar is on the right side, go into the right side padding and minus the thickness of the bar. \* \*\*BP\\\_PreviewActor\*\*'s automated camera distance is determined by all components which have collision enabled. This means if you have collision hitboxes or something similar on your actors, the camera will try to adjust to fit that in the camera view. Remember to use the tag “\*\*DONOTPREVIEW\*\*” on those collision components if the \*\*BP\\\_PreviewActor\*\* is copying them. \* Your item is not showing up in the asset manager or your getting a "Ignoring PrimaryAssetType Items - Conflicts with SOMECLASSNAME - Asset: ITEMNAMEHERE" in your message log. This happens when there are two identical data assets. This will most likely happen when you have two completely blank data assets. \* The highlight widget is going outside the boundaries of the container or is getting clipped. This happens if the sizing of the widget does not match the container dimensions. This is most common if the container is slotted into a canvas panel. If that is the case, you can check "Size To Content". For other widgets, you will have to manage the sizing of the container and in some cases, it's handled automatically. ![](https://varian.gitbook.io/files/xRQ8qruywKvZRFWjcpEs) In game issue ![](https://varian.gitbook.io/files/YdF42yrlTuXH9LYraYjC) In editor issue \* After adding or changing default values inside \*\*FS\\\_InventoryItem\*\*, the InventoryHelper will falsely report a value is no longer set to default and will reset it to the wrong value when pressing the reset button. This is happening because the struct inside the InventoryHelper did not get updated. You must go into \*\*EUW\\\_InventoryHelper\*\* and find \*\*SelectedItem\*\* and update its default settings. The same might happen to the context menu, so you must go to \*\*WBP\\\_ContextMenu\\\_EditorOnly\*\* and find \*\*Item\*\* and update its default settings. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/bugs.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_container.md). # W\\\_Container This widget is responsible for holding both the tile widgets and item widgets and also acts as a proxy for the component to access any tile widgets or item widgets. The component (\*\*AC\\\_Inventory\*\*) should not rely on these widgets at all for any data for its functions, like I mentioned at the start of this documentation. Even though there are \*\*ContainerSettings\*\* inside of these, they are immediately overridden by the component when created. They are mainly used as a fallback default, used for previewing how the container will look or used to bind the widgets to a specific container in a component. I recommend looking at the comment on \*\*GetContainerSettings\*\*. To reduce the work for everyone when modifying containers, \*\*W\\\_Container\*\* has a function (\*\*GetContainerSettings\*\*) to get the \*\*ContainerSettings\*\* straight from the component it belongs to. This way you do not have to update the \*\*ContainerSettings\*\* for the widget every time the container is modified in any way and also allows designers to make children of \*\*W\\\_Container\*\* and still have access to the same data as other children. \*\*TileSize\*\* refers to how large you want your tile widgets to be. Ideally both dimensions should be the same to minimize stretching. If you decide to not have the dimensions 1:1, your item icons will have to accommodate for your new icon ratio. Yclamp refers to when you want the scroll bar to appear. This should be (Your Tile Y Size) \\\* (How many Y tiles you want until the scroll bar appears) So if I want mine to appear after 8 tiles while my container is 10 tiles tall and my tile Y size is 60, I would do 8\\\*60. \*\*TileClass\*\* and \*\*ItemClass\*\* are the default classes used to create the widgets for each instance of a container. It is recommended to try and keep these the same where ever your containers are to try and maintain consistent visuals through out your game. \*\*DA\\\_CoreItem\*\* has a override map, where if the current containers class is found in that map, it'll then use the item widget in that map instead of the assigned \*\*ItemClass\*\*. This could be useful for when a special item needs it own item widget. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_container.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1.md). # 3.1 Engine support: 5.5 This update focuses on quality-of-life, debugging and IFP's presentation. ## Quality of life \* All major classes related to IFP now have custom slate icons ![](https://varian.gitbook.io/files/ARMmSNw4oqhGCwC6Qjs5) \* A one-time welcome popup now appears on engine startup to help direct new users to the documentation ![](https://varian.gitbook.io/files/DmLzg2K63CfRi132zCxQ) \* Custom IFP log category has been added. To help with logging, most of IFP's \*\*PrintString\*\*'s has been replaced with a new function; \*\*LogIFPMessage\*\* ![](https://varian.gitbook.io/files/NNQkbVMKwk7EgCHX7VQo) \* The \*\*ItemFailedSpawn\*\* delegate now gives a reason why it failed. It also logs the reason. \* \*\*LootItem\*\* now lists failure reason and logs the reason. \* When the item widget can not evaluate to any icon, it will print an error and assign a "Bad Blueprint" error texture to the widget to indicate something is wrong. \* When saving an asset and it can't evaluate an icon, it will also alert you through the output log. \* All properties inside the item asset are now \`BlueprintReadWrite\`. This is to help editor tools automate the creation of item assets. ## Inventory \* \*\*LoadItemAssets\*\* now has a callback for when all items have been loaded. \* \*\*UniqueID\*\* can now be used in TMaps/TSets \* You can now override the max stack on items through the new \`MaxStackOverride\`tag value. \* Some arrays, such as the item components, external objects will now remove nullpointers and shrink themselves during garbage collection. ## Crafting \* Timed crafts no longer use a timer, they use the tick event and keep track of the game time to decide when the craft should finish. \* This is to allow crafts to occur while the game is paused. \* Added \*\*RD\\\_TimeToCraftBase\*\*, which has a overridable function for getting the time it takes to craft a recipe. This provides more flexibility, for example creating a timed craft recipe data that returns a different value depending on the characters crafting skills. ## Bug fixes \* \*\*StartComponent\*\* could in some cases not alert the client. \* Item icons could shrink in some cases when equipping \* \*\*GetItemComponent\*\* would in some cases add an item to the network queue, but not remove it. \* Preview actors were causing external objects to receive irrelevant updates. \* \*\*MassReduceCount\*\* could fail with non-stackable items. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.1.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da\_coreitem.md). # DA\\\_CoreItem \*\*\* This is the data asset that is responsible for the base information for your items. I highly suggest looking at the \*\*DA\\\_CoreItem.h\*\* file to see all the settings, functions and comments. You can show and hide certain settings depending on your setup, and I use that a lot with the \*\*ItemType\*\* enum. Look at all the options, check out the meta properties (EditCondition and EditConditionHides) to see how it’s done, and you can then implement your own options and rulesets for their visibility. Keep in mind, these settings are only HIDDEN, not disabled in the data asset editor, you can still access those variables from the data asset in blueprints and C++ and you have to remember that when making your functions and gameplay logic. One of the most important settings to set up here is \*\*EItemType\*\* as many functions use this enum to do casts to the proper children of this asset. Whenever you make a new child, remember to go into the .cpp file and set the default value. You can see an example inside all the .cpp children of this. If you are new to C++ or Unreal Engine, I suggest looking \[\*\*here\*\*\](https://benui.ca/unreal/uproperty/) to find all the specifiers you can give each variable. \*\*\* ## Creating new items \[\*\*Video documentation\*\*\](https://youtu.be/GzxE6spwgCQ) (slightly outdated, for example the content browser and item actor name have been changed, but majority of it is still relevant. The only thing that should be ignored is around \`06:23\`, I state that you should import the containers from the data asset into the item actor. This is no longer needed, only the first index needs to be setup.) Creating new items is very simple. To start off, you'll need to go into the engine and find your content browser, right click and go to \*\*Inventory Framework -> Inventory Item Asset\*\* and a pop up will appear asking you what parent your data asset should derive from. You might have your own children or have removed some of the children that come with the asset, but whatever asset you choose must derive from \*\*DA\\\_CoreItem\*\* at some point in its hierarchy. I suggest creating a folder for your item and placing the data asset in there. To create a blueprint actor for your item, you will have to create an actor who at some point in its hierarchy is a child of \*\*A\\\_ItemActor\*\* (The blueprint child is called \*\*BP\\\_ItemActor\*\*), then set that as your \*\*ItemActor\*\* The actor will automatically get the blueprint inventory component assigned to it. You will need to go into the component settings and change a few things. 1. Set \*\*InventoryType\*\* to "\*\*Pickup\*\*" 2. Add one index to \*\*ContainerSettings\*\* and set the \*\*ContainerType\*\* to "\*\*ThisActor\*\*". This will then hide most of the settings except for the items array. 3. Your items array should only have one index, which will be your newly created data asset. All settings can be left to their default. 4. (Optional) If your item has containers associated with it, the data asset should have an array of \*\*DefaultContainers\*\*. You will want to populate these with your containers and also assign the widget. Only available to supported data assets, such as \*\*IDA\\\_Equippable\*\* and \*\*IDA\\\_Weapon\*\*, to create your own item asset with container support, override the \*\*GetDefaultContainers\*\*. An example can be found in the example project with the gun and backpack item. To have the asset manager pick up your data asset, it can not be identical to another data asset. (This includes the base file, so if all your variables are set to default, the asset will not get picked up.) Typically you want to immediately give your item a name and a developer image for the InventoryHelper. \*\*\* ### Creating new C++ children of DA\\\_CoreItem You might want to create your own category of items, and since the engine does not allow you to mix C++ and blueprint children of data assets, you are unfortunately forced to create C++ children. I suggest installing the plugin directly to your project, and then creating new children inside the \*\*Items\*\* folder, which is found inside the plugins \*\*Core\*\* folder. \*\*\* ## Changing the Item Actor class Currently your item actors must be a child of \*\*AA\\\_ItemActor\*\*. If you want to change this, you can change it like so: {% tabs %} {% tab title="From" %} \`\`\` UPROPERTY(EditAnywhere, BlueprintReadOnly, Category="CoreSettings") TSoftClassPtr ItemActor = nullptr; \`\`\` {% endtab %} {% tab title="To" %} \`\`\` UPROPERTY(EditAnywhere, BlueprintReadOnly, Category="CoreSettings") TSoftClassPtr ItemActor = nullptr; \`\`\` {% endtab %} {% endtabs %} AActor can be swapped out for any class, it does not need to be AActor, but it must be a child of AActor. +++ \*\*\* ## Custom shapes This inventory system features container styles where items can be different lengths and different heights. The way you define your shape is by adding the Custom Shape trait to your \*\*TraitsAndComponents\*\* array and using the \*\*DisabledTiles\*\* array. Though this is not very pleasant to work with in its raw array format. It is recommended to use the \[ItemEditor\](/varian-docs/inventoryframework/inventory-framework/tools/item-editor.md), where you'll find a toolbox with a few tools inside of it, one being the shape editor. Which gives you a much better UI to work with. \*\*\* ## Asset verification To aid quality assurance, the data asset will run custom data verification when the asset is saved. The verification validates everything in the following process: 1. Use the \*\*ValidationClass\*\* in the \*\*DeveloperSettngs\*\* category to execute its \*\*VerifyData\*\* function. (Because we can't access a blueprint graph in each instance of a data asset, we do this to get around that limitation.) 2. \*\*ValidationClass\*\* -> \*\*VerifyData\*\* will run some code to check if any mistakes have been made. Since every project is different, it is suggested to create your own child of \*\*O\\\_ItemAssetValidation\*\* and write your own code. To validate the data of trait references, an interface function from the \*\*I\\\_Validation.h\*\* interface also named \*\*VerifyData\*\* is called. You can see an example of this inside of \*\*O\\\_BasicItemValidation\*\* and \*\*IT\\\_Consumable\*\* 3. If any error messages are created during any of the \*\*VerifyData\*\* functions, you'll get a message at the bottom right stating the error message. If the \*\*ErrorMessages\*\* array is empty, the item passes the verification. Do note, if an item does not pass the verification, it does NOT prevent you from playing the game. {% hint style="info" %} Remember, modifying any variables from a data asset's object reference will change the base asset. This feature is great for a system like this. For example, if you want a specific setting to always be set to something specific, you could programatically change the setting inside these validators. Ensuring these settings remain consistent across a large data-base. I personally use this to ensure all my first-person meshes always have their shadows and collision disabled. If I ever have to change this setting, I just have to change the validator and resave all of my assets and my changes will be reflected across all current and future assets. {% endhint %} \*\*\* ## Where to store runtime logic As the plugin has grown, more and more features have been added, blurring the definition of what an "item" is and where any gameplay logic should be stored. All items are data assets. Then when the inventory is made, a struct is made, which contains all data that can be modified during runtime and this data is replicated under specific conditions. \* Data inside of data assets should NOT be modified during runtime. If you have 2 guns in your inventory, then change any data inside the asset, it'll change for both of the guns. But modifying the struct for a gun will only modify that specific struct. The four primary options below leave you with many options to tackle where to store your data and logic. It's up to you to resolve which method is best for what you are trying to accomplish. ### GAS abilities or helper components What I, and many others have been doing, is simply constructing one object, a GAS ability or helper actor component, and having that run the logic for, let's say, a gun item. Whenever you swap weapons, you'd just send an event to the ability or component and it would update what weapon is equipped. This approach has a host of benefits: \* Many performance benefits. \* Simpler for source control. \* Easier to find gameplay logic that might not have been touched in some time. \* Easier to maintain. \* Far fewer points of failure. For each blueprint you create to handle runtime logic, it's another point of failure. This approach minimizes the amount of blueprints, and thus reducing the amount of point of failures. I would recommend using GAS over all other options whenever you can, but of course, not all use cases are the same. There is no ultimate solution that covers every scenario. I personally recommend using \[\*\*GAS Companion\*\*\](https://www.unrealengine.com/marketplace/en-US/product/gas-companion) and/or \[\*\*Gameplay Blueprint Attributes\*\*\](https://www.unrealengine.com/marketplace/en-US/product/gameplay-blueprint-attributes) to help with your GAS implementation. \* The only downside of GAS that I've found is that it is extremely difficult to have abilities be "instanced per item". As in, a new ability instance is created for each item instance without overriding a lot of C++ code and having a really good understanding of how GAS works under the hood. This type of logic can be achieved with the \[\`ItemAbility\`\](/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration.md#item-component-ability) item component. ### Traits and Components Data assets have "\[traits" and "components\](#traits-and-components)", which I recommend you read the documentation for, but in essence, they are: \* Traits: Extra data you can add to any specific asset without creating a new parent. Essentially giving you "horizontal" hierarchy, just like how interfaces add functions to a class without reparenting it. \* Example: You have a sword and a health potion asset. Both of these can be crafted, but you don't want to create a "Craftable" item asset to insert into their hierarchy. Not all swords and not all potions might be craftable. You can now add an trait to any asset that has a recipe and have that trait link to that recipe data asset. You can now ask your data asset if it is "craftable" without asking your entire recipe data base if it has a recipe for that item. \* Components: Actor components that can be created during runtime and are attached to the same actor that the inventory component lives on. These can run gameplay logic and destroyed during runtime, just like any other actor component. These are tied to traits so they can also be thought of as "horizontal" hierarchy. ### Item actor Then there's the optional actor to spawn when the item is dropped, or in some cases equipped. These can be destroyed and created frequently, so it shouldn't really be trusted with a lot of gameplay logic. This should be treated as just the "visual representation" of your item. ### Item Instance \`ItemInstance\`'s are optional objects created when an item struct is created, and they're tied together. Unlike actors, \`ItemInstance\`'s can be trusted to handle gameplay logic. \* \*\*Assigning an instance with an item\*\*: There are two ways to assign an \`ItemInstance\`'s with an \`ItemAsset\`: 1. \*\*Data Asset Default\*\*: The default instance is set in the data asset. This is the recommended way. 2. \*\*Override per Struct\*\*: Individual struct instances can override variables for more customization. 3. \*\*Recommendation\*\*: I highly recommend using the first method as that is soft-referenced. \* \*\*Replication\*\*: Fully supported and can be optimized with custom replication conditions. \* \*\*Restrictions\*\*: By default, assigning an \`ItemInstance\` in the item struct has 2 rules: 1. "Wild" \`ItemInstance\`'s are not allowed. This refers to items which have no default \`ItemInstance\` assigned in the item asset, but you still want to add one to the item struct. It is highly advised to keep this rule enabled to prevent random items having random item instances as keeping track of this is extremely difficult in medium to large projects. 2. You are not allowed to select \`ItemInstance\`'s that do not match the same class that was assigned in the item asset. This is to prevent two identical items having two different ItemInstance classes, leading to odd behavior.\\\*/ 3. To disable either or both of these restrictions, modify \*\*FL\\\_InventoryFramework\*\* -> \*\*ProcessContainerAndItemCustomizations\*\* \* \*\*Serialization (Experimental)\*\*: Item Instances can be serialized, saving only variables marked with the \`SaveGame\` flag. This feature is experimental and may change in future updates, so it's not recommended for production. I recommend going with a much more robust serialization system that covers much more than just the inventory. \*\*\* #### Creation & Destruction \* \*\*Creation\*\*: Item Instances are created during \`StartComponent\` and remain tied to the item until the item is destroyed, unless you enable \*\*ConstructOnRequest\*\*. Then it will only be constructed when you call \*\*GetItemsInstance\*\*. \* \*\*Destruction\*\*: They stay alive until garbage collection activates, just like widgets. Use \`IsDestroyed\` to check their status. \*\*\* #### Networking \* \`ItemInstances\`'s replicate to all clients relevant to the inventory owner. However, the item struct data itself isn't replicated and shouldn't be trusted on non-owner clients due to networking optimizations \`IFP\` enforces. \* \`ItemInstances\`'s can declare their own replication conditions, allowing for optimized network performance (e.g., replicating only to the owner or server-only). \* \*\*Important\*\*: If you move the inventory component to the player state for seamless travel, \`ItemInstance\`'s will replicate to every client. To avoid this, use replication conditions or consider not using \`ItemInstance\`'s, depending on your game's needs. #### Performance \* Constructing these \`ItemInstance\`'s is cheap, but if you plan on using hundreds of these, the small cost can pile up. I highly recommend leaving the \*\*ConstructOnRequest\*\* option set to true. The main worry you might need to consider is the garbage collector. The developers of Hogwarts Legacy had this problem where they abused instanced objects so much that the garbage collector would cause hitches, though I am not sure as to how many objects they were making. I suggest only making these instances for items that actually need it. \* If you have a pooling system, then I will continue recommending having \*\*ConstructOnRequest\*\* enabled, then overriding the \*\*RemoveObject\*\* function to no longer mark the object as garbage and move the \`ItemInstance\` into your pooling system, then modifying \*\*GetItemsInstance\*\* to access your pooling system. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da\_coreitem.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations.md). # Optimizations While \`IFP\` is already extremely optimized, there's a few things you can do and keep in mind to make sure you are getting the absolute most out of \`IFP\`. To start, lets first cover what are the most expensive parts of \`IFP\` (Listed in semi-random pattern. It is not possible to 100% be certain what is the MOST expensive in all projects as there are multiple factors as when some things might become more expensive than others): \* The biggest performance culprit are the item widgets. About 33% of the cost of making a widget for an item just goes into creating the UMG hierarchy inside the widget. \* Finding an available tile during \*\*StartComponent\*\*. The more tiles an item occupies, the more calculations are required to find a spot. This is also where the InventoryHelper can improve performance. If a specific tile is provided to an item, it doesn't have to scan the entire container to find a free tile. This can be alleviated with the \`SkipValidation\` system, which can be found in the inventory component documentation. \* Disabling rotation for items through \*\*AC\\\_Inventory\*\* -> \*\*CanItemBeRotated\*\* will reduce the amount of calculations required during \*\*StartComponent\*\*. \* Unfortunately, removing some Blueprint features greatly improves performance. Let's take \*\*CheckCompatibility\*\* as an example. In a test with 100 items, this function in total took 1.5ms, but removing the \`BlueprintNativeEvent\` keyword from the UFUNCTION, which is the keyword that allows the function to be overriden at a Blueprint level, reduced the total time down to 0.090ms. Removing Blueprint support improved the performance by about 16 times. ## Separating lag spikes One of the great benefits of IFP's structure is that it doesn't require widgets to function. Which means we can separate the lag spike of starting the component, creating the inventory, the widgets, and adding the inventory screen to the viewport into four chunks. 1. Loading item assets asynchronously. 2. Calling \*\*StartComponent\*\*. 3. Creating the inventory screen widget. 4. Binding the containers with the widgets inside of the inventory screen. 5. Adding the inventory screen widget to the viewport. \* The function \`GetDynamicMaterial\` is surprisingly expensive the first time it is called and can cause a noticable spike. This is used by the item widgets. If possible, you should try to trigger this function during your loading screen or staggering these function calls, for example creating the inventory screen during the loading screen. Doing all of these at the same time will in some scenarios create a spike that is noticable to players. But separating them will make it (hopefully) invisible to players. ## Widgets ### Tiles The tile widget is already highly optimized. The hierarchy can be reduced to just an image. (The demo widget has an overlay inside of it for debugging assistance. Removing it will almost double the construction speed. \* The only feature in the tile widget that is expensive is the \`TileTags\` feature. It's not that the functionality behind it is expensive, it's simply the fact that this feature is getting executed per tile and containers can end up being 100+ tiles and the price starts to pile up, which is something you need to keep in mind in general when working with tiles. All your code must be highly optimized when it comes to the tile widget as your code might be spammed by hundreds of tiles within one frame. \* If you plan on having a very large amount of tiles, then the simple rendering cost of so many separate widgets might become a limiting factor for you. At this stage, \`IFP\` can't do any more optimizations. But that doesn't mean you can't. The reason why \`IFP\` can't do any more optimizations is because this ultimate optimization would remove some features and make some operations slightly more complicated.\\ The TLDR; You want to modify \`IFP\` so that it only generates one tile widget. Then give it a material that tiles the material you want to use. Now you're only paying for one widget render and only rendering one material.\\ This does mean that a few features, like dynamic shaped containers and tile tags become extremely complicated or not possible to use. This should be a last resort and you should evaluate whether this is worthwhile for you by profiling your project with Unreal Insights.\\ There's 2 other paths you might want to consider before this: \* Use the \`View\` widgets (like \`List View\`) to host the tiles. These widgets are designed to only spawn a widget when it becomes visible in the viewport. \`IFP\` might someday implement this natively, as this is a good way of optimizing inventory screens and this should not affect any \`IFP\` features. \* Convert the tile widgets to slate. ### Items The item widget will be going under a few optimizations throughout the next updates, but there are some core optimizations you can do: \* Generated item icons are and always will be much more expensive than just disabling it and using a texture. The \`ItemEditor\` tool can take the generated item icons and save them to disk as a texture to assign in the data asset. Getting the best of both worlds, though this will remove any features where the icon updates depending on what is attached to an item, for example attaching a silencer on a gun and having the icon update accordingly. \* Staggering out the generated item icons. This is actually a default feature that can easily be enabled in \*\*WBP\\\_InventoryItem\*\*. \* Depending on the simplicity of your equipment, you might want to do what some of the Resident Evil games do. They have a texture for each gun and every combination of it with attachments. Of course, they had very few weapons and very few combinations of equipments. So again, depending on the simplicity of your project, you might want to consider this technique. \* Create some of the widget components during runtime. For example, the ItemCount text. If the majority of your items can't be stacked, you are then creating a text widget that will never be shown for a lot of items. By default, \`IFP\` does not do this as this is generally a more annoying workflow. This really comes down to per projects needs. ### Other notes These are notes that aren't directly around \`IFP\`, but are still useful for all UI design. \* If the player can not see the world while looking at the inventory or in an escape menu or something else, you can implement and call this function to completely disable world rendering and gain tremendous frame rate gains: ![](https://varian.gitbook.io/files/jR03kjhck1LS21d1YlaZ) ![](https://varian.gitbook.io/files/QAWnilEY4W39gRk8FEPn) \* Epic's \[\*\*documentation for optimizing\*\*\](https://dev.epicgames.com/documentation/en-us/unreal-engine/optimization-guidelines-for-umg-in-unreal-engine?application\_version=5.2) everything related to UMG: ## Networking The only real meaningful thing you can do about network performance is trimming down the \`FS\_ContainerSettings\` and \`FS\_InventoryItem\` struct. For example; if you don't need the overwrite settings for items, you can remove it to reduce the RPC size of all items. ## Equipment \* Do not use Blueprint Actors for your equipment. They are in some cases 11 times more expensive than skeletal/static meshes. Many people have proven that it is possible to do complex logic, like guns with animations and so forth without using Actor equipments. I personally suggest using GAS and whenever an item is equipped/unequipped, you fetch the mesh and let the GAS ability animate it and so forth. \* Equipment easily take up 70%+ of the lag spike caused by \*\*StartComponent\*\*. If you want to keep using lots of equipment, you need to start calling \*\*StartComponent\*\* during your loading screens or managing equipment better. In reality, only the player character should be spawning equipment meshes. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a\_itemactor.md). # A\\\_ItemActor This is your physical representation of the item. If you already have items/weapons of any sorts, you will want to reparent those classes to this. This is not supposed to run important logic as these can get destroyed and created by the user. (for example equipping and unequipping) In your data asset, you can access this class so whenever you drop the item out of the inventory or want to spawn it in some way, here is how you access the original pickup class. It’s very important when making your items that have a physical representation in the world and can be picked up that the component on that actor references the data asset that references this physical actor. Otherwise when you drop the item, it’ll spawn the wrong class. The setup for pickups goes like this: In your \*\*ContainerSettings\*\* index 0, you set \*\*ContainerType\*\* to \*\*ThisActor\*\* and item index 0 is the pickup data asset. There should be no other items in this items array. Containers that might be attached to the pickup are added after and they can have Inventory or Equipment selected, but never \*\*CurrentItem\*\*. \*\*\* ## Custom Blueprint Children The \*\*BP\\\_ItemActor\*\* is a optional parent in your hierarchy. It has some code that you will want to copy over to any parents that you have if you wish to make your own, primarily the BeginPlay, Equip and Unequip delegates, and Destroyed event. The C++ inventory compoonent will automatically get added to your actor, but the base C++ version should not be used. You want to click on the InventoryComponent in your components list and set ComponentClass to \*\*BP\\\_AC\\\_Inventory\*\* (Or your own child of the inventory component if you've made one) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/a\_itemactor.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components.md). # Traits and Components ## Item Trait \*\*Item Traits\*\* are pure data-only UObjects associated with item data assets. They allow you to add variables and functions to an item data asset without modifying the parent data asset. \* \*\*Retrieving Data\*\*: Use \`GetTraitsByTag\` or \`GetTraitsByClass\` functions. The class version automatically casts to the correct blueprint, while the tag version requires manual casting. \* \*\*Use Cases\*\*: Traits are ideal for adding variables or functions that don't fit into the item category, such as quest data, without needing to add that data to the item asset \* \*\*Function Limitations\*\*: Traits can run functions but cannot use delays, timers, async tasks, or RPCs. Avoid writing data to trait variables as traits are shared among items with the same data asset. Unique trait instances are not created per item. \* \*\*Important Note\*\*: Prefer soft references over hard references to avoid creating a complex web of hard references, which can lead to excessive loading of game assets. Item data bases are one of the biggest culprits to create a large web of hard references in almost every project. \*\*\* ## Item Component \*\*Item Components\*\* are actor components that attach to the owner of the inventory component that drive gameplay logic related to items, such as equipping, consuming, or creating widgets. They can be assigned through any trait derived from \`IT\_ItemComponentTrait.h\`. An ItemComponent relies on a trait, but a trait does not rely on an item component. It's a one-way dependency. \* \*\*Requirements\*\*: Each Item Component needs an associated trait to function, but not all traits require an Item Component. \* \*\*Role\*\*: Item Components act as proxies between the inventory system and other systems, allowing flexibility without affecting core inventory functionality. They operate like any other actor component, supporting delays, timers, RPCs, etc. \* \*\*Replication\*\*: \* \*\*Server\*\*: Exists only on the server. \* \*\*Client\*\*: Exists only on the client. \* \*\*Both\*\*: Created on the server and replicated to the client (typically used). \* \*\*Client Requests\*\*: Clients can request the creation of an Item Component with a specific tag to associate with a function. Note that if creating a "Both" component, the function may not return immediately due to RPC delays. \* \*\*Paylod\*\*: When a component is created, the client can pass in a payload that gets sent to the server. This struct is not used by the plugin, so it is safe to modify for your projects needs. ## Why are they separated? 1. Due to the type of logic that components could handle, such as casting, handling abilities, VFX and so forth, you would want it to be soft-referenced. But you can't have it be instanced (as in, able to edit its properties in the item asset) and be soft-referenced. So we allow the trait to be hard-referenced, and the component to be soft-referenced 2. Due to the simplicity of traits, they take up very little memory. Like what was talked about in point 1, we can't soft-reference traits. Actor components have a lot of irrelevant data that doesn't need to be loaded when the item asset is loaded. 3. In some cases, you want to run a function without loading the component class or creating an instance of the component. For example, the item ability trait has a function to "loosely" check if the item ability would even activate successfully after being created. In this case, you can save performance by checking this type of logic inside of the trait, rather than the component. \*\*\* ## Tips and tricks By default, your traits will display their default class name in the drop down menu. ![](https://varian.gitbook.io/files/AjOrIg3VqaLkmmUOoePz) You can change the name they are given inside this drop down menu by following the next steps. ![](https://varian.gitbook.io/files/dulyAEwwdyMHErRktBQQ) \\- By going into your Class Settings (1) you can change the class name (2). The drop down menu will now display whatever text you put in here. ![](https://varian.gitbook.io/files/AvJ1NQyrtQ7g8HGBLgOJ) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp\_tooltip.md). # WBP\\\_Tooltip The tooltip widget is an example of \[External Objects\](/varian-docs/inventoryframework/inventory-framework/systems/external-objects.md). It automatically updates when items receive events, similar to MVVM without using MVVM. ## Debug mode The tooltip can have its debug mode enabled or disabled through the \`IFP.Debug.Tooltip\` console command --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/wbp\_tooltip.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor.md). # Item Editor The item editor is a simple, but powerful tool that allows you to select any item the asset manager can detect and directly edit the asset without opening a new window. This tool is also meant to provide a simple interface for designers to create tools to help with their workflow. There are two tabs, the library and the editor. The library simply is where you can find all your assets and filter them. The second tab is your asset editor. At the bottom you'll find a toolbox. By default there aren't many tools in here, but it is meant for you to expand for your games needs. \*\*\* ## Tool box With the asset comes a icon editor, a shape editor and a socket manager. \* The icon editor allows you to edit the inspect and generated item icon settings, and allowing you to see how the item will look like in game with whatever item widget you have selected. You might want to go into \*\*WBP\\\_ItemWidgetPreview\*\* and setting the default widget class to a class you commonly use. \* The shape editor allows you to easily modify the \*\*DisabledTiles\*\* inside the \*\*IT\\\_Shape\*\* object, if it has been added to the item. \* Tip: You can click and drag to change the state of multiple tiles without having to click over and over again. \* The socket manager lets you manage the sockets on the item if it has the \*\*IT\\\_SocketManager\*\* object. \*\*\* ## Tips and tricks \* You can resize the segments with the white bars. \* If you click and drag the item asset icon into the viewport, you can place the item actor, just as if you were dragging the item actor from the content browser. \* Right clicking the asset icon will open the item asset just as if you were to double click it in the content browser. \* The top section of the library allows you to refresh the library, in case you create new assets while the editor is open. You can also scale the icons up with the slider. The final button will save the currently selected item asset. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/tools/item-editor.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting.md). # Crafting \*\*\* The inventory system does come with an \*\*optional\*\* module for crafting. The crafting is a completely independent system and the inventory system has no reliance on it. Removing it will have no impact on the inventory system as this is a one-way relationship. The crafting system relies on the inventory, the inventory does not rely on the crafting system. \*\*\* ## Classes Most classes can be created by right clicking the content browser and going into InventoryFrameworkPlugin -> Crafting, the entire crafting system revolves around two classes: \* \*\*AC\\\_Crafting\*\*: The actor component that handles the crafting and replication. It also stores all recipe's a player owns. \* \*\*DA\\\_CoreCraftingRecipe\*\*: The core crafting recipe data asset, these are your definitions for a recipe. This asset uses four different classes to create the recipe: \* \*\*Recipe Requirements\*\*: All must return true for the recipe to be craftable. This is only asked on clients to enable the interaction of some widgets, but then asked again on the server when starting the craft. \* \*\*Display Requirement\*\*: All must return true for the recipe to be visible when opening the crafting screen. \* \*\*Craft Events\*\*: Code that is ran when a craft is successful, such as playing a sound effect or granting a crafting skill experience. \* \*\*Recipe Data\*\*: This is ambiguous data meant mostly for blueprint programmers who don't want to modify or create custom children of the data asset. This allows you to add any data to a recipe, such as "Time to Craft" or a description to display in the UI. \*\*\* ## Recipe handling Many games have recipes bound to things such as a "crafting bench", which is completely natural. The pain points come when you are deciding where you want to store recipe's and finding out what recipe's the player can and cannot craft. When a player unlocks a recipe, even if it is tied to a unique object such as a crafting bench or area, the player still holds onto the recipe. This is so it is much easier to evaluate how far the player is into the game and evaluating whether or not you should grant the player a recipe as the other object might not be loaded. In general, it is much simpler and efficient to just have the player hold a reference to all recipe's they have unlocked, then either blocking the craft or preventing it from being displayed (or both) through other means, such as applying a tag on the player when they are near a bench and the recipe requires that tag to be displayed. \*\*\* ## Widgets The plugin itself does NOT come with any widgets to use the system. Only the example project has widgets and that is the primary learning source for creating custom widgets and UI. These examples are not needed in your project, they are simply an example of how I would use the component and data asset. My setup begins inside of \*\*WBP\\\_Inventory\*\* -> \*\*Receive External Component\*\*, which will lead to a subgraph called CraftingExample. Most of the system runs on delegates (For blueprint users, these are most often called Event Dispatchers, in C++ and C#, they are referred to as Delegates, so I will continue calling Event Dispatchers as Delegates), which can be simply handled since the player is responsible for holding all recipe's as mentioned above. I always name any functions related to a delegate with a \*\*D\*\* prefix and most often sort them into their own \*\*Delegates\*\* category. Since the system uses soft references for most recipe's, you can decide whether or not to instantly or async load your recipe's. I've chosen to async load them as that is better for performance. There are no rules on how to make your own widgets when using the crafting system, my system primarily uses the recipe requirements, display requirements, craft events and craft data to design how and when recipe's should be visualized. \*\*\* ## Serialization To save the players recipe's, the crafting component has an array of "Recipes" which you will want to save and then restore when loading a save. \*\*\* ## Timed Crafts When doing a timed craft, there's a few things to consider. First, you'll want to add the \*\*RD\\\_TimeToCraft\*\* recipe data to your recipe asset. Then when you are about to perform a craft, you will want to call \*\*GetUniqueCraftHandle\*\* and pass that into \*\*S\\\_CraftRecipe\*\* and save the value on the client. If you now wish to cancel the craft, for example if the player dies, then you can call \*\*S\\\_CancelCraft\*\* and pass in the handle. By default, clients do not get any kind of callback for when a craft is starting to handle something like a craft bar. Most games simply do not handle it this way. One way to handle this is to simply start the visual timer - for example a progress bar - instantly. Then retrieve the \*\*RD\\\_TimeToCraft\*\* data to get the timer length, but then add the players ping on top of that. Other methods would include simply allowing the progress bar to reach the end, but not actually vanish until the server says the craft is finished. The majority of players pings are low enough to not notice most methods. It's up to your code to handle how the visuals are displayed, what events cancel these crafts and for you to store and retrieve these handles. \*\*\* ## Removing the crafting system To remove the crafting system from the plugin, follow these steps: 1. Remove all references in your project from any of the crafting system. 2. Go into the plugin folder and into Content and delete the Crafting folder. 3. Go into the plugin folder and into Source and delete the IFP\\\_Crafting and IFP\\\_Crafting\\\_Editor folders. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/crafting.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system.md). # Working in the system - \[Adding new items during runtime\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime.md) - \[Creating custom functions\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions.md) - \[Creating custom widgets\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-widgets.md) - \[Creating new items\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items.md) - \[Compatibility Settings\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/compatibility-settings.md) - \[Drag and drop\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/drag-and-drop.md) - \[Equipping and unequipping items\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/equipping-and-unequipping-items.md) - \[Modifying Critical Files\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/modifying-critical-files.md) - \[Optimizations\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/optimizations.md) - \[Setting up vendors\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/setting-up-vendors.md) - \[Sorting Items\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/sorting-items.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query.md). # Item Query The \`ItemQuery\` system is a separate module (Just like how the crafting system is a separate module) that includes a system that allows for quickly filtering and querying a specific set of items while supporting multithreading. These queries are very simple; They listen to specific events and if they pass the filtering function, they are added to an array, which can be reused extremely efficiently. To enable item querying, add the \*\*AC\\\_ItemQueryManager\*\* component to your actor. To add a \`ItemQuery\` to the manager, either add one to the \*\*ItemQueries\*\* array inside the component... ![](https://varian.gitbook.io/files/R5l5SxfCJVCZaKc5rBNM) .. or call \*\*ConstructObjectFromClass\*\* (We use this function so any \`ExposeOnSpawn\` parameters can be set) or use \*\*NewObject<>()\*\* if you're in C++, and then call \*\*AC\\\_ItemQueryManager\*\* -> \*\*RegisterItemQuery\*\* To then get the items from the query, you can either call \*\*AC\\\_ItemQueryManager\*\* -> \*\*GetItemsFromQueryByClass\*\*/\*\*GetItemsFromQueryByIdentifier\*\* or call \*\*GetItemsFromQuery\*\* on the item query instance you just created. The \`ItemQuery\` is now responsible for listening to any events relevant to it. For example, if you wanted to filter out all items with a specific tag, you would listen to the \*\*ItemTagAdded\*\*/\*\*ItemTagRemoved\*\* delegate. If an item had the tag added, you'd register the item. If the item had the tag removed, you're unregister the item. ![](https://varian.gitbook.io/files/f2e0yndR6AQtRwdhLDgh) Listen to the TagAdded and TagRemoved events ![](https://varian.gitbook.io/files/Le7t7XYUt1AXiuWVeYWh) If an item suddenly has the desired tags, register it. If the desired tags got removed, unregister the item. ![](https://varian.gitbook.io/files/XrGZuq0FMDEuEYP5SmDn) DoesItemPassFilter is called whenever you try to register an item. It must pass this filter to get added. By default, all queries will automatically listen to 4 delegates: 1. ComponentStarted - It will try to register all items. 2. ComponentStopped - All items will now be removed from the query. 3. ItemAdded - It will try to register a newly added item 4. ItemRemoved - It will remove the item from the query. \*\*\* ## Creating a query class To create a \`ItemQuery\`: 1. Right click the content browser and select InventoryFramework -> Other -> ItemQuery 2. Override the \*\*QueryRegistered\*\* function and bind the relevent delegates your query will use. Then call \*\*RegisterItem\*\* and \*\*UnregisterItem\*\* when needed. 3. Override the \*\*DoesItemPassFilter\*\* to dictate what items will ultimately get registered with the query. The example project includes 3 examples. \*\*\* ## Performance In a test of over 300 items, registering a query that checked for a tag on the item took on average 500 microseconds, which is only 1/32 of a 60 FPS frame budget. Getting those items from the query then took on average 100 microseconds. \* For maximum performance, it's recommended to remove the \`BlueprintNativeEvent\` from the \*\*DoesItemPassFilter\*\* function and only use C++ item queries. As talked about in the \`Optimizations\` page, removing Blueprint support can improve performance by about 16 times. \* The main area that C++ dominates Blueprints are heavy for-loops. Running a similar hard-coded query through blueprint code took a whopping \*\*34.7 milliseconds\*\*. These queries provide a simple interface for blueprint programmers to leverage the speed of C++ while staying in Blueprints by just overriding one function. \* The only downside for queries in regards to performance is that they take up memory, but it shouldn't be that much that you'd notice. \* Queries can be multithreaded. This can be extremely powerful in the right scenarios. For example, spawning the equipment can be expensive. This is why the manager component will try to multithread its default queries while that is happening, greatly improving CPU utilization. \* Do keep in mind that sending a task to a different thread does have a small cost. I advise you to use Unreal Insights to evaluate whether it is worth for your inventory to bother with multithreading or not > Keep in mind, Blueprint debugger does not work when blueprint code is NOT being executed on the game thread. So blueprint breakpoints won't work in the multithreading scenario \*\*\* ## Storing extra information Queries do not just have to store a list of items. Since queries are living objects, you can store whatever information you want. The example project includes a query that keeps track of specific item asset and how many of that item asset there are. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-query.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-sockets.md). # Item Sockets \`ItemSockets\` is a system that allows you to assign a socket to an item, similar to a static or skeletal mesh. This socket contains a name, a local position, a tag, and a rotation. Then using helper functions to get the tile index of that socket (\*\*GetTileForSocket\*\*), with another function allowing you to provide an offset to the sockets tile (\*\*GetTileForSocketWithOffset\*\*). The \`ItemSocket\` system can be enabled for items by opening the item asset and adding the \`Socket Manager\` trait. It is recommended to open the \`ItemEditor\` tool as that will provide you with a editor utility widget to visually assign your sockets. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/item-sockets.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac\_inventory.md). # AC\\\_Inventory This is where the vast majority of the logic is handled and starts. You have full control of when the component activates by calling the \*\*StartComponent\*\* function. When called, the component initializes the containers and the items inside or the pickup if the owning actor is a pickup. This does NOT prepare the widgets versions of the containers and the items. But this function must be called before you display any widgets or any data to the player. To create the widget version of a container and its items, call \*\*BindContainerWithWidget\*\* and hook in the container struct and the container widget. This should give you full control of when you want to construct the widget for a container. Some examples would be when the player opens their inventory, but you don’t want to load all the items' attachment widgets. You could then load the attachment widgets when the player inspects the item. For inventory systems that can get massive with a lot of items inside of it with attachment widgets associated with it, this massively improve performance and memory usage if used correctly. For pickups, I recommend calling \*\*StartComponent\*\* on either \*\*BeginPlay\*\* or when the player is close to the item and has line of sight of the item, as items that have a spawn chance associated with it need that spawn chance rolled. The item might also have items attached to it and be visible, such as a sight on a gun, which also might have a spawn chance and you don’t want that sight to be visible if it failed its spawn chance. \*\*\* ## Settings The first category is \*\*Settings\*\* and most of these are instance editable, so you’ll be spending most of your time with these settings for your item actors. \*\*ContainerSettings\*\* is where the majority of the work is done. I recommend going into \*\*IFP\\\_CoreData.h\*\* and find \*\*FS\\\_ContainerSettings\*\* and looking at the comments for everything as there are some variables that aren’t instance editable. \*\*\* ## Optimizing StartComponent When the component starts, a bunch of calculations, compatibility checks and validation occurs. This can be expensive if you initialize hundreds to thousands of items or containers. If you apply the \`IFP.Optimization.SkipValidation\` tag, these steps are mostly skipped. You are now telling the system that YOU have validated the position, compatibility and so forth. Without this tag, items can take anywhere from 1 microsecond, to 100 microseconds or more, depending on the quantity, size, shape and so forth. With this tag, items consistently take anywhere from 100 nanoseconds to 2 microseconds. \* This tag is automatically applied to any save files, since it makes sense to assume that the containers you are trying to save have already been validated in some way. \* It is recommended whenever loading a save from a previous version of your game to remove this tag. In this case, you'd want to add some version number to your save files and enabling the \*\*Remove SkipValidation tags\*\* parameter on \*\*StartComponent\*\* if the save files version number does not match the games current version. \* Do keep in mind that this has no failsafes. If you apply this tag on an item and odd behavior occurs, you have either found a bug or the tag was applied when it shouldn't have been. \* The \`InventoryHelper\` tool automatically applies this tag to items whenever possible. \* The main performance benefits come from applying this tag to items. Very little performance gain happens when applying this to containers. This tag should only be applied to containers in save systems. \`IFP\` already handles this automatically. \* In a few runs of a simple A-B test with 18 items; without this tag it would take on average 340 (total time for all items) microseconds to initialize quite complex items in a large grid container. With the tag, this number dropped to 8 microseconds. \*\*\* ## Inventory Extension Components Any actor component on the inventory components owner implementing the \*\*I\\\_InventoryExtension\*\* interface will be treated as "inventory extension components". These components will receive two events; pre/post \*\*InventoryComponentInitialized\*\* This is especially useful for when \*\*StartComponent\*\* is called during \*\*BeginPlay\*\*, as the order of \*\*BeginPlay\*\*'s can be difficult to predict for actor components, making it difficult to bind to the appropriate delegates to inject any logic before or after \*\*StartComponent\*\* is called. With this interface, you do not have to worry about that. The example project's helper components utilize this feature and can be used as examples. {% hint style="info" %} Do note that this means that a component can receive these events \\\*before\\\* their own \*\*BeginPlay\*\* is triggered. {% endhint %} \*\*\* ## Color settings Third category is \*\*ColorSettings\*\* and this is where most of the colors used by the system are dictated. This is set in here so all the widgets can fetch colors easily and so designers can extend any color settings (for example color blind settings) to the user settings. If you want to add any color settings, this place is the preferred place. Item rarity colors are handled in here. \*\*\* ## Network Queue The component has an array called \*\*NetworkQueue\*\*, these are items that are waiting for a server RPC to finish. If you are writing your own networking code, it is up to you to call \*\*C\\\_AddItemToNetworkQueue\*\* and \*\*C\\\_RemoveItemFromNetworkQueue\*\*. This will automatically call \*\*ItemAddedToNetworkQueue\*\* or \*\*ItemRemovedFromNetworkQueue\*\*. If the item widget is available, it'll also call: \*\*W\\\_InventoryItem\*\* -> \*\*ParentItemAddedToNetworkQueue\*\* / \*\*ParentItemRemovedFromNetworkQueue\*\* By default, the widgets will play a blinking animation when they are in the network queue. These events are where your designers hook in any logic that alerts the player the item is pending some networking event. This is most often seen as making the item's icon gray-scale or flashing the icon. You will want to implement some way of preventing players from interacting with items that are pending a network event, either by making the widget uninteractable or through code. You can check if an item is in the queue by using: \*\*FL\\\_InventoryFramework.h\*\* -> \*\*IsItemInNetworkQueue\*\* The Network Queue system is only relevant for clients, it's never used in single player or server scenarios. \*\*\* ## Infinite containers Containers can be infinite in either the X or Y direction, the system tries to dynamically resize the container whenever an item is moved, added or removed from it. \*\*\* ## States The containers can be in one of three states during development. \* The "raw" state is where \*\*UniqueID\*\*'s are not set and containers \*\*BelongsToItem\*\* directions are direct index directions and all object references are null. The component is designed to be in this state for when you call the \*\*StartComponent\*\* function. This is where all the data is "human readable", but most functions won't work. \* The "Editor" state is where \*\*Unique\*\*'s have been initialized and \*\*BelongsToItem\*\* are set to the items and containers \*\*UniqueID\*\*'s and some object references might be valid. This state is meant for development and it might make some data not human-readable, and it'll mean most of your functions will work as if you are in a valid game session. Many tools depend on the component being in this state, such as the InventoryHelper. \* Finally there's the "Initialized" state. This simply means the gameplay logic has called the \*\*StartComponent\*\* function and you are inside a gameplay session. The component should never be put into this state while you're outside of a game session. You can use \*\*GetComponentState\*\* to resolve what state it is in, and look inside that function to better understand what conditions must be met for each state. There is a function called \*\*ConvertToRawState\*\* which will prepare all containers for a gameplay session. Ideally, this function should not be called during a gameplay session as it's a waste of CPU time. All container data should already be prepped for gameplay. By default, the component calls this function on its \*\*BeginPlay\*\* if it detects the actor was not setup properly and spit out a print string. There is also another function called \*\*ConvertFromRawStateToEditorState\*\* which preps all data to be usable for editor tools. \*\*\* ## Attached spawned items An important aspect to remember is that whenever you have a item that has a spawned actor to represent it, such as a gun item inside the players equipment container, the inventory component on the spawned item should NOT be used. This will mostly happen with the equipment system when using Blueprint items. The reason for this is because spawned blueprints can be deleted and restored over and over, so they are unreliable to store any important data. It would also mean that the blueprint would always have to stay alive if you wanted to explore the items containers while the item isn't spawned (In this example, the gun item hasn't been equipped). An items containers always live on the component that own the item, (In this example, the gun's containers live on the character that is holding the gun). To retrieve the items true data, you need to retrieve the UniqueID of the owning item in some way. Generally this means storing the items UniqueID inside your spawned blueprint. \*\*BP\\\_ItemActor\*\* does this through an interface event called \*\*PassUniqueID\*\* and stores the data inside \*\*RootItemData\*\*. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac\_inventory.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/world-settings-and-actions.md). # World Settings and actions \`OmniToolbox\` provides a system similar to Lyra's user experience system. By changing your World Setting's class in the project settings to \`OmniWorldSettings\`, you will get a new array of \`WorldActions\` inside the \`World Settings\` panel. When the world's BeginPlay is activated, these world actions are activated. ## UOmniWorldAction Utilized by the \`UOmniWorldSettings\` class during \`BeginPlay\`to enable specified game features and activate specific game feature actions, or enable specific game features. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/world-settings-and-actions.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/documentation-button.md). # Documentation button Any asset implementing the \`I\_AssetDetails\` interface and overrides the \`GetDocumentationLinks\` will have a button appear next to the compile button that when pressed, will open that URL in the browser. ![](https://varian.gitbook.io/files/KeaCuAaMf5NTq0JkYIP0) \`\`\`cpp virtual TArray GetDocumentationLinks\_Implementation() const override { return TArray { FOmniDocumentationLinkAndText("https://varian.gitbook.io/varian-docs/tagsmetadata") }; } \`\`\` Providing more than 1 index will convert the button into a dropdown menu ![](https://varian.gitbook.io/files/UK14JFsLqbaDCawKNURE) \`\`\`cpp virtual TArray GetDocumentationLinks\_Implementation() const override { return TArray { FOmniDocumentationLinkAndText( "https://varian.gitbook.io/varian-docs/tagsmetadata", "Option1") FOmniDocumentationLinkAndText( "https://varian.gitbook.io/varian-docs/", "Option2") }; } \`\`\` {% hint style="info" %} \`FOmniDocumentationLinkAndText\` has 2 parameters, a URL and a text. Remember to fill in the text when providing multiple links, as this text will be displayed to the user. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/editor/documentation-button.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration.md). # Ability System Integration \[\*\*Video tour\*\*\](https://youtu.be/rvd6SbspA9E) An important note around \`IFP\`'s design is that it was NOT built with any specific ability system in mind, but rather have good extension points to allow for it to interact with any ability system and for any ability system to interact with \`IFP\`. This design philosophy has led to \`IFP\` being extremely easy to integrate with any ability system. This page will mostly cover \`GAS\`, since that is the most popular ability used with \`IFP\`. But concepts can still be adapted to any type of ability system. > In 2.10 a separate module including several classes to help with \`GAS\` integration is included in the plugin. This does mean that \`IFP\` has a dependency on \`GAS\`. To remove that dependency, remove the \`IFP\_GAS\` module folder, then open \`InventoryFrameworkPlugin.uplugin\` and remove the \`IFP\_GAS\` module from the modules list and the \`GameplayAbilities\` plugin from the plugins list. \*\*\* ## Connecting IFP with your ability system The primary way \`IFP\` is meant to connect to your ability system is through the \`Traits and Components\` system that can be found in item assets, or by either modifying the item asset or creating specialized children who then contain references to classes, such as an ability class. Then through code, you'd fetch these references and either grant, remove or activate them. The other method would be through the various delegates that come with the inventory component, such as the ItemEquipped delegate is a good candidate to grant the player abilities. Then the primary way of your ability system interacting with \`IFP\` is through some type of reference to a specific item or a group of items. For example, a gun firing ability could fetch what is currently equipped in a specific container and use data stored on that item to run its logic, such as fire rate. In this case, the ability could remain active for the entire lifetime of the actor and simply continue using data from equipped items to run its logic. This is one of the most performant and perhaps most scalable solution. This also means you are only creating one object to handle this logic rather than creating a new one for each item. \* This topic is covered more in \[\*\*here\*\*\](/varian-docs/inventoryframework/inventory-framework/classes-and-settings/da\_coreitem.md#gas-abilities) In some cases, it might be worthwhile adding direct references to either system into the other system, for example adding ability class references to the item asset or modifying abilities to reference and depend on an inventory item. \*\*\* ## Native GAS support As mentioned above, 2.10 includes \`GAS\` support out of the box. This section covers how it works and how to customize it. > Remember, this is just one way of implementing \`GAS\`. Many projects might have different requirements or different needs. Hence why I made the native \`GAS\` implementation simple to remove. This is just one way for \`GAS\` to be implemented with \`IFP\` \* \*\*IT\\\_GameplayAbilityReferences\*\*, \*\*IT\\\_GameplayEffectReferences\*\* and \*\*IT\\\_AttributeSetReferences\*\* are item traits which stores class references and include events for granting and removing their respective system. \* The actor component \`AC\_GASHelper\` will handle all items containing these data-only objects and handling the events that grant and remove them. You will want to add this component to the same actor that the inventory component is on. \* This component has a simple "Tag Event" system. This is meant to help filter out when to grant and remove abilities and attributes for specific events. These events can be called from anywhere by simply broadcasting the \`TagEventActivated\` delegate with a tag event. The component will now automatically get all items for that event and attempt to either grant or remove abilities, attributes and effects. \* To process an item, you need to call the \*\*ProcessItem\*\* function and pass in an event. This function will call 6 functions, trying to grant and remove any abilities, attributes and effects. If you want to, you can call each function individually or separately. \* This component can have a blueprint child and most functions can be overriden to customize its behavior. \* By default, this component handles 3 events (You can override the \*\*BindDefaultEvents\*\* function to increase the number of events the component automatically handles): 1. When \*\*AC\\\_GASHelper\*\* has its \*\*StartHelperComponent\*\* function called. 2. When an item is equipped. 3. When an item is unequipped. ### Notes \* This system does not keep track of duplicate items. For example, the player can equip 2 rings sharing the same item asset. When they unequip Ring1, then it will try and remove anything the asset wants removed, even though Ring2 should still grant them the asset wants them to have. To get around this, I'd recommend overriding the \*\*BindDefaultDelegates\*\* and do not call the parent, so it stops handling the \`ItemEquipped\` and \`ItemUnequipped\` event and you would now either make your own delegate that tries to accomodate this, or improve the code behind these two delegates, or handle this through some other code somewhere else. \* For effects, it is recommended to use \`Infinite\` effects. If you use \`Instant\` or \`HasDuration\`, the effect might not be reversable. For example, modifying an attribute with \`Instant\` will just modify the attribute and when we try to remove the effect, nothing will happen. If it has \`Infinite\` duration, then the modification made to the attribute will be reversed when you remove the effect. \*\*\* ## Item Component Ability \`IFP\` includes a "ItemAbility" \`ItemComponent\`, which is not related to \`GAS\` or any other ability system, but is designed to look and behave very similar to \`GAS\` abilities (This is the closest \`IFP\` has to an "ability system"). While you should continue to use \`GAS\` abilities whenever possible, the levels of networking optimizations that Epic have provided for \`GAS\` has created a few limitations to \`GAS\`, which includes: 1. \`Instanced Per Execution\` does not seem to have replication support anymore. 2. Changing ownership of an instanced ability does not seem to be supported. 3. Having a \`GAS\` ability treat an item as its owner requires a lot of work (as in, an ability that would use \`Instanced Per Actor\` would only ever have 1 instance created for the owner of the inventory component, but you might want it to be something like \`Instanced Per Item\`, so you could have an instance made for an item, but only 1 per item). This ability component is designed to get around these limitations. So again, use \`GAS\` abilities whenever you can, and only use this component if the above limitations are preventing you from making your ability. To activate an item ability, you can call \*\*TryActivateItemAbility\*\* or \*\*TryActivateEquippedItemAbility\*\* The scope for this ability component is very small to try and reduce complexity and just provide the basic interface of an ability system. Item Components already have networking support, but you will have to implement any RPC's to communicate to clients. By default, item abilities are completely server authoritative. ### Creating a new item ability {% hint style="info" %} I advice you make your own item ability parent and ability trait parent, then have all your item abilities be children of your parent and override some functions to fit your project, for example \*\*GetOwnersTags\*\* {% endhint %} To create a new ability, create a new child of \*\*ID\\\_ItemAbility\*\*, or of your item ability parent. \* Optional: You can also create a item ability object if you want to expose more variables to the item asset or override some functions. For example, you can override \*\*AllowNewInstance\*\* to customize the "instancing policy" for the ability or the \*\*LooselyCheckCanActivateAbility\*\* function to minimize failed activations. You will now want to open your item asset and add an item ability object to your \*\*Traits and Components\*\* array and assign the \*\*Item Component\*\* to your new item ability --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/ability-system-integration.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime.md). # Adding new items during runtime \*\*\* ## Single player Adding new items during runtime for single player is no problem and has no restrictions. Just call the function \*\*AC\\\_Inventory\*\* -> \*\*TryAddNewItem\*\*. \*\*\* ## Multiplayer For multiplayer though, I've had to wrap this function with a very strict safe guard. Clients are under no circumstance allowed to call this function. If they do find a way, they will get kicked. There is simply no circumstance where the client should even have the slightest chance of gaining access to this function as they could potentially feed it bad data and grant themselves any item within your data base. Only the listen server or dedicated server is allowed to use this function. This means if you have a quest system or anything of the sort where the player is granted an item, you will have two options: 1. Pre-store the item in a component and call the \*\*MoveItem\*\* function, but this will permanently remove the item from the old component. Though you could always reset the data after the function is called. 2. The system which is calling \*\*TryAddNewItem\*\* is already owned by the server, and thus is allowed to call the function. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/adding-new-items-during-runtime.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions.md). # Versions - \[0.3\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.3.md) - \[0.2\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2.md) - \[0.1\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.1.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1.md). # 3.3.1 ## Inventory Component \* Count is now revealed if ShowCount is set to true. This is automatically set, but can be changed by fragments. The random count fragment shows an example of this. \* A new template system has been introduced. \[Documentation can be found here\](/varian-docs/inventoryframework/inventory-framework/systems/templates-for-inventory-and-containers.md) \* Added a new \*\*PreItemRemoved\*\* delegate \* Unique ID's are now global and never change when items move from one inventory to another. Once an item or container has received an ID, it will remain valid for as long as that item exists. \* This is slightly experimental. The old system can be toggled through the runtime IFP project settings. \* \*\*StartComponent\*\* now calls numerous virtual functions. This can help projects inject custom logic into the inventory initialization process. ## Quality of Life \* Many functions inside the item asset are now virtual. \* The function library can now be overriden. Greatly improving a projects ability to override some of IFP's functionality without touching the source code. \* Not all functions have been made virtual, but the most popular ones have been made virtual. More will be added when people ask for them. ![](https://varian.gitbook.io/files/6u4ebpv10bOM4FdCyhZG) \## Editor \* The struct customization for containers and items have been improved and should now work no matter where the struct is, meaning the custom title and other utilities are no longer restricted to just the inventory component or some item assets. \* The item count variable is now revealed when an item is stackable and has no random count fragment assigned. ## Bug fixes \* \*\*GetItemsPrice\*\* had a faulty if else statement leading to all items being worth 0 \* \*\*AdjustContainerSize\*\* was miscalculating items TileIndex so items were moving to wrong places \* \*\*ItemMoved\*\* was not returning the correct \*\*ItemIndex\*\* \* Odd crash from containers tick event ## 3.3.1 fixes \* \*\*GetContainerSettingsForSpawningItem\*\* was not wiping the item widget reference. \* \*\*GetItemsShapeWithContext\*\* would unnecessarily validate the item, when it doesn't need to. This would cause \*\*GetFirstAvailableContainerAndTile\*\* to break only for grid containers \* Item instances were getting their ItemID assigned in the editor, causing a crash when opening a context menu in the blueprint. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/3.3.1.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work.md). # How does the networking work? \*\*\* ## Listeners Certain inventory data can become quite large, especially with how many containers and items you allow in an inventory. To optimize, we try to simplify things. Players only receive data from components that they request data from and data from their own components, but also any update from components they are currently interacting with. The component keeps track of the players that are currently interacting with a component with the \*\*Listeners\*\* array, then whenever PlayerA moves, adds, removes or interacts with an item in some way, the component sends RPC calls to the other "listeners" so their widgets and data get updated. For functions that modifies a components data, such as moving an item or modifying an items stack count or modifying any other data, you must remember that clients only have authority over their own component, they do not have authority over other components and thus can't call functions on other components. This is simply how networking in Unreal Engine works. Because of this, most functions require you to call the function on the component the client has authority over. Even though the item you are trying to modify is not on that component. This is why, when you look at some of the source code, the functions are getting the component the item belongs to through its \*\*UniqueID\*\*.\*\*ParentComponent\*\* and modifying that component's data through the component the client has authority over. To simplify the code, any function that attempts to automate the replication for you stores its logic in a function with the same name but with a \*\*Internal\\\_\*\* prefix. For most functions that modify data in some way, only a single version of that function is available for you to call, and that function handles the replication for you. This is to simplify the amount of functions exposed as it can get very daunting to try and handle every replication scenario and making sure your calling the right function. If you wish to modify how the replication is handled, you can always go into the functions, modify them, or enable the server/client/internal functions to be BlueprintCallable (Example would be \*\*AC\\\_Inventory\*\* -> \*\*Internal\\\_AdjustContainerSize\*\*). {% @mermaid/diagram content="graph TD A\\\[Function called\] --> B(Evaluate if function should be replicated) B -->|Is Single player| C\\\[Call internal function\] B -->|Is Multiplayer| D\\\[Send server RPC\] B -->|Is Multiplayer| H\\\[Add item to network queue\] D --> E\\\[Call internal function on server, gather list of listeners\] F --> G\\\[Send Client RPC's to listeners\] E --> F\\\[Call internal Function on client\] G --> R\\\[Remove item from network queue\]" %} Code example \`\`\`cpp //Increase the count of an item by @Count void IncreaseItemCount(FS\_InventoryItem Item, int32 Count, int32& NewCount) { if(UKismetSystemLibrary::IsStandalone(this)) { //Single player, don't bother with any replication stuff InternalIncreaseItemCount(Item.UniqueID, Count, NewCount); return; } //Update server data S\_IncreaseItemCount(Item.UniqueID, Count); //Predict the result if item is stackable. if(Item.Item->CanItemStack() == true) { NewCount = FMath::Clamp(Item.Count + Count, 1, Item.Item->MaxStack); } else { NewCount = Item.Count; } //Notify the player the item is currently busy C\_AddItemToNetworkQueue(Item.UniqueID); } //Increase the item count on the server void S\_IncreaseItemCount(FS\_UniqueID ItemID, int32 Count) { int32 NewStackCount if(GetOwner()->GetRemoteRole() == ROLE\_SimulatedProxy) //This is dedicated or listen server. Don't bother with client RPC { InternalIncreaseItemCount(ItemID, Count, NewStackCount); } else //Client is calling, update server, then call client RPC { InternalIncreaseItemCount(ItemID, Count, NewStackCount); C\_IncreaseItemCount(ItemID, Count); } for(const auto& CurrentListener : ItemID.ParentComponent->Listeners) { //Update all clients that are currently listening to this component's replication calls. if(CurrentListener->GetOwner()->GetRemoteRole() == ROLE\_AutonomousProxy && CurrentListener != this) { CurrentListener->C\_IncreaseItemCount(ItemID, Count); } } } //Increase the item count for listening clients void C\_IncreaseItemCount\_Implementation(FS\_UniqueID ItemID, int32 Count) { //Find the item we are processing bool ItemFound; FS\_InventoryItem Item; ItemID.ParentComponent->GetItemByUniqueID(ItemID, ItemFound, Item); if(ItemFound) { int32 NewStackCount; InternalIncreaseItemCount(ItemID, Count, NewStackCount); //Item has been processed, remove from network queue C\_RemoveItemFromNetworkQueue(Item.UniqueID); } } void UAC\_Inventory::InternalIncreaseItemCount(FS\_UniqueID ItemID, int32 Count, int32& NewCount) { //Start moodifying the item in here. //This was called on both client and server, so the same logic is ran for everyone. } \`\`\` \### Why not just use a multicast or RepNotify? Because of how large some RPC's can get, I did not find multicasts to be acceptable for most of the functions. A lot of the RPC's are just simply not relevant for most clients anyways, and managing relevancy is a lot more complicated than a simple array of actors. RepNotify's also can not be used because there is no way to ensure their order. When you label a RPC as "Reliable", Unreal will make sure all reliable RPC's get replicated in the order you called them. Variables will always get replicated, even with packet loss, so they are in a way "reliable", but not truly reliable. Variables will replicate whenever they get an opportunity to, and they have a lower priority than RPC's. RepNotify's also always re-sync the entire array even if one element is updated. So if you'd just update the item count for one item, the entire inventory would be re-replicated. \*\*\* ## Requesting inventory data IFP does not automatically replicate any inventory data between clients other than their own inventory component. This means that actors in the level, like a chest, for clients will just contain the class defaults. For a client, they must call \*\*C\\\_RequestServerDataFromOtherComponent\*\* and they will then be added as a listener. Then eventually you will need to manually call \*\*S\\\_RemoveListener\*\*. An example can be found in \*\*BP\\\_ItemActor\*\* in the interaction events. \*\*\* ## Unique ID The \*\*UniqueID\*\* is a simple method to quickly find containers or items, or ensuring containers or items are valid, and for linking some object to an item (Such as the \[item components's\](/varian-docs/inventoryframework/inventory-framework/classes-and-settings/traits-and-components.md)). This is covered in multiple sections in the documentation, but here are some things to consider for networking. \* Clients and servers must stay in sync when it comes to UniqueID's. This leaves you with two options; 1. Pre-generate the \*\*UniqueID\*\*'s on the server, then pass them to the client and have your logic assign that \*\*UniqueID\*\* to the item. This is not advised as it can get bad for networking and it is generally cumbersome to program and manage it. 2. Use \*\*GenerateUniqueIDWithSeed\*\*. Now the only thing you need to ensure is that the client and server are using the same seed and they'll both generate the same \*\*UniqueID\*\*. \* \*\*UniqueID\*\*'s \[scale extremely\](/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-custom-functions.md#network-optimizations) well with RPC's. It is advised to use \*\*UniqueID\*\*'s as often as possible. \* There's no way to evaluate from a \*\*UniqueID\*\* if it was assigned to an item or container without going through all items and containers until you find a match. It is not recommended to add more information to this struct as it's meant to be small and simple, so that it gets replicated extremely quickly and cheaply. \* \*\*UniqueID\*\*'s from components the client does not have information on will not work. For example, two players are interacting with a chest and Player-1 moves an item from their inventory to the chest, Player-2 will not have the information necessary to move the item on their side, since they do not have the information needed from Player-1's inventory component. Some functions simply need more information than the \*\*UniqueID\*\* can provide. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-networking-work.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/suggested-plugins.md). # Suggested Plugins No matter what plugin of mine you are using, this is a list of plugins I recommend for everyone due to their excellent quality. ## \[GAS Companion\](https://www.unrealengine.com/marketplace/en-US/product/gas-companion) Unreal Engine's built-in Gameplay Ability System (GAS) is extremely powerful and is becoming an industry standard. There is a problem with it though; it's not very beginner-friendly. It's annoying to make attributes and can take a long time to set it up. The plugin GASCompanion does all the heavy lifting for you, has good documentation and good Discord support. ## \[Flow Graph\](https://github.com/MothCocoon/FlowGraph) Made by one of the developers of Witcher 2 and 3 and is being backed by Riot Games, this plugin has revolutionized how I make things like quests, dialogues and much more through its amazing graph editor. A tool that I truly think should be introduced to Unreal's base toolset. ## \[Editor Scripting Tools\](https://github.com/HoussineMehnik/UE4-EditorScriptingToolsPlugin) This plugin lets you customize the editor without touching C++. It allows you to add UMG widget tools into detail panels all inside blueprints and without touching the plugin that class resides in. ## Gameplay Message Router This is a plugin that can be found in Lyra and it provides a simple yet powerful global messaging system. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/suggested-plugins.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/input-nexus/input-link/link-bundle.md). # Link Bundle \`LinkBundle\`'s is a simple data-only object meant to store an array of \`InputLink\`'s to quickly grant a set of \`InputMappingContext\`'s, \`InputAction\`'s and \`InputLink\`'s. ![](https://varian.gitbook.io/files/l43zID5FaJSjgaSFxaAq) \* This is a data-only class with no functions. Hence why this is not a data asset and just a object class. \* Only 1 copy of each \`LinkBundle\` can be active at a time per \`InputNexus\` component. \* Default \`LinkBundle\`'s will have their links added to the start of the \`InputLink\`'s array and everything defined in the component and \`LinkBundle\`'s added during runtime will have their \`InputLink\`'s added to the end of the array. It's designed this way because default \`LinkBundle\`'s are expected to be used as the base data, then everything added through the \`InputLinks\` array should be treated as the links added on top of them. \* Remember, the \`InputLink\`'s at the \[end of the array are activated first\](/varian-docs/input-nexus/input-link.md). We use a reverse for-loop rather than a standard for-loop. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/input-nexus/input-link/link-bundle.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2.md). # 0.2 ## Float Provider \* Structs have been renamed, added a new \`FOmniFloatProvider\` which exposes instanced structs to blueprint users and enables struct customization. \* Float providers have been customized. It now enforces at least a basic float provider, ensuring a null instanced struct is never assigned and puts a input value into the title. ![](https://varian.gitbook.io/files/8tSuXTY2qVGjKlQbjDXt) \## New functions \* Exposed \`AddInstanceComponent\` to blueprints, which helps add actor components through scriptable tools and ensure they get serialized. ## Bug fixes \* \`Omni\_InsightsTrace\` was not using \\\_\\\_FUNCTION\\\_\\\_ correctly --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.2.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work.md). # How does the system work? \*\*\* ## Design structure With how strict the performance requirements were for this plugin, I’ve had to design this inventory system slightly differently from other systems you might find either on the marketplace or Youtube tutorials. The biggest thing to keep in mind is that this system does NOT rely on widgets being valid or created to keep track of its data or run gameplay logic. This is to achieve five things: 1. This greatly speeds up widget construction since all the data they need (for example where an item is inside the container and so forth) is already prepped. 2. Allows you to remove widgets from memory and still have the necessary data to find out important things like looting an item and finding a free space for that item. 3. Since widgets have way fewer references, there is less work to be done to manage widgets getting garbage collected properly. 4. Designers are able to create new widgets and prototype much faster since all the data they need about containers and items is always available from the component. 5. You have complete control over when you want to construct these widgets, meaning you can reduce lag spikes when starting your game or even speed up the time it takes for your players to load a level or area. \*\*ContainerSettings\*\* is an array inside of \*\*AC\\\_Inventory.h\*\* and this is your inventory. Each container hosts a set of items and dictates its dimensions, compatibility settings and so forth. Some settings are hidden as they are not relevant to designers. When creating a widget for a container, the widget uses a \*\*UniqueID\*\* to find out what container it is representing. This is typically referred to as "Binding" a container with a widget. Items differentiate themselves from each other by using a \*\*UniqueID\*\* as items can have the same name, same data asset and so forth, they can even share the same position inside a container while in-editor. A component can not give items or containers the same \*\*UniqueID\*\* twice. This is essential for functions to work properly. The component is designed to live on individual actors, not the player controller. Though there is no reason why it can't live on the controller, but I won't be actively testing it that way. It is highly recommended to head over to the \[AC\\\_Inventory\](/varian-docs/inventoryframework/inventory-framework/classes-and-settings/ac\_inventory.md) page and giving a read. Understanding the main component that makes this system work is crucial to understanding the in's and out's of the system. \*\*\* ## How are the infinite items inside of items achieved? Since UE does not support recursive structs and recursive structs are difficult to manage, containers use a coordinates system explaining what item they belong to. The array is simply containers and those containers have an array of items. The only thing the compoonent needs to know whether a container is owned by the component or owned by an item is by checking \*\*FS\\\_ContainerSettings\*\*\*\*.\*\*\*\*BelongsToItem\*\*. I recommend reading the code comment for the \*\*FS\\\_ContainerSettings\*\*\*\*.\*\*\*\*BelongsToItem\*\* property and then looking at \*\*AC\\\_Inventory.h\*\* -> \*\*GetItemsContainers\*\* for an example. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/how-does-the-system-work.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide.md). # Style Guide I have tried to follow the popular \[\*\*UE5 Style Guide\*\*\](https://github.com/Allar/ue5-style-guide). Though I may sometimes accidentally or purposefully sway from it. I am very open to criticism, if something is confusing or inconsistent, don't hesitate to let me know. \*\*\* ## Functions Networking functions are prefixed with \*\*C\\\_\*\* for client, \*\*S\\\_\*\* for server and \*\*MC\*\*\\\_ for multicast. For functions that attempt to automate replication, the bulk of the function's code is stored in a function with a \*\*Internal\\\_\*\* prefix. These are typically called both by the server and client. If you want access to the internal functions, you will need to add \*\*BlueprintCallable\*\* to the UFUNCTION above them. \*\*\* ## Tools All editor utility widgets are stored inside Plugin folder -> Content -> Core -> Widgets -> EditorUtilityWidgets -> Tools. Any widgets or special components for each editor utility widget is stored in its own folder named after the editor utility widget inside the EditorUtilityWidgets folder. This is done so you can bookmark/favourite the Tools folder and have access to all the tools quickly. You can also find all your editor utility widgets at the top of the editor -> Tools -> Tools, though there is no way to separate the inventory tools from your own editor utility widgets. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/style-guide.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items.md). # Creating new items \[\*\*Video documentation\*\*\](https://youtu.be/GzxE6spwgCQ) \*\*\* Creating new items is very simple. To start off, you'll need to go into the engine and find your content browser, right click and go to \*\*Inventory Framework -> Inventory Item Asset\*\* and a pop up will appear asking you what parent your data asset should derive from. You might have your own children or have removed some of the children that come with the asset, but whatever asset you choose must derive from \*\*DA\\\_CoreItem\*\* at some point in its hierarchy. I suggest creating a folder for your item and placing the data asset in there. To create a blueprint actor for your item, you will have to create an actor who at some point in its hierarchy is a child of \*\*BP\\\_ItemActor\*\*, then set that as your \*\*ItemActor\*\* The actor will automatically get the blueprint inventory component assigned to it. You will need to go into the component settings and change a few things. 1. Set \*\*InventoryType\*\* to "\*\*Pickup\*\*" 2. Add one index to \*\*ContainerSettings\*\* and set the \*\*ContainerType\*\* to "\*\*ThisActor\*\*". This will then hide most of the settings except for the items array. 3. Your items array should only have one index, which will be your newly created data asset. All settings can be left to their default. 4. (Optional) If your item has containers associated with it, the data asset should have an array of \*\*DefaultContainers\*\*. You will want to populate these with your containers and also assign the widget. This variable only exists for weapon and equippable item types. An example can be found in the example project with the gun and backpack item. To have the asset manager pick up your data asset, it can not be identical to another data asset. (This includes the base file, so if all your variables are set to default, the asset will not get picked up.) Typically you want to immediately give your item a name and a developer image for the InventoryHelper. \*\*\* ## Creating new C++ children of DA\\\_CoreItem You might want to create your own category of items, and since the engine does not allow you to mix C++ and blueprint children of data assets, you are unfortunately forced to create C++ children. I suggest installing the plugin directly to your project, and then creating new children inside the \*\*Items\*\* folder, which is found inside the plugins \*\*Core\*\* folder. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/working-in-the-system/creating-new-items.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.0.0.md). # 1.0.0 Engine support: 5.1 \* Official release --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/1.0.0.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.1.md). # 0.1 Marketplace and beta release --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/releases/versions/0.1.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/content-browser.md). # Content Browser > ## Credits: > > \* Thanks to mklabs for his \[GAS Companion\](https://www.fab.com/listings/72e2bc50-658e-43cd-bd40-535f46d2f113) plugin, his content browser extension code is the original reason I pursued this system. Although no GAS Companion code is used in this plugin. > \* Some of the code is borrowed from the open-source \[VoxelCore\](https://github.com/VoxelPlugin/VoxelCore) plugin. \`OmniToolbox\` allows any C++ class to be easily added to the content browser's context menu by simply adding the \`I\_AssetDetails\` interface and returning true for \`AppearsInContextMenu\`. ![](https://varian.gitbook.io/files/igZcCXYIBiTRK4VM6tSz) Your asset will now automatically get a \`UOmniAssetDefinition\` and \`UOmniFactory\` to handle displaying it in the context menu and to create the asset. {% hint style="info" %} This only supports basic assets (data assets and normal blueprint types) {% endhint %} The interface provides some utilities, such as enabling a class picker ![](https://varian.gitbook.io/files/2ZgAHJVCQyWCLTLxu8Na) ![](https://varian.gitbook.io/files/914WxTVUTF5EtiScOZCw) When overriding \`AppearsInContextMenu\`, I recommend doing it like this: \`\`\`cpp virtual bool AppearsInContextMenu\_Implementation() const override { return GetClass() == UEntityAbility::StaticClass(); } \`\`\` Handling it like this will prevent child classes from also attempting to appear in the context menu. ## Blueprint support {% hint style="danger" %} I do NOT recommend using this system for blueprints. It's not good practice to have your base abstract classes be blueprints and there are many potential issues that can occur when loading blueprints like this. {% endhint %} To allow blueprints to appear in the content browsers context menu, a little bit more work is required: 1. Go to your editor settings and find \`OmniToolbox\` and add your blueprint to \`Context Menu Entries\` 1. The blueprint must implement \`I\_AssetDetails\` to appear 2. Restart the editor. 1. The code that handles this system is only executed once and that is when the plugin is started. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/editor/content-browser.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_drag.md). # W\\\_Drag Visual representation of the item you are dragging, but also provides updates to \*\*W\\\_Highlight\*\* whenever you hover over a tile so the highlight widget knows where to move. All data you need when dragging and dropping an item should be stored in this widget. Both \*\*W\\\_Drag\*\* and \*\*W\\\_Highlight\*\* are updated inside of \*\*WBP\\\_Tile\*\* -> \*\*PerformDrop\*\* and \*\*BP\\\_AC\\\_Inventory\*\* -> \*\*UpdateHighlight\*\* The chain of events begin at \*\*WBP\\\_InventoryItem\*\* -> \*\*OnDragDetected\*\*. An important note to consider is that Epic, in their ever-ending glorious top tier coding, have a built in interpolation for the drag and drop drag visual that you CAN NOT interact with without modifying the engine. But you have to go through a lot of trouble to replace the built-in drag and drop system for Unreal. So I leave the drag visual for the drag/drop operation as empty and allow \*\*WBP\\\_Drag\*\* to drive the visuals and most of the logic. The Drag/Drop operation is primarily just used to trigger the "On Drop" events. ## Rotation This widget is the primary handler of certain settings when trying to move an item, such as the rotation. You can see an example on EventTick. If you wish to permanently change the system to no longer support 180 and 270 rotation, there is a code comment near the end of EventTick explaining how to enforce only 0 and 90 rotation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_drag.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/libraries.md). # Libraries \`OmniToolbox\` comes with several function libraries that are constantly expanding. Each one can be found in the runtime module inside the \`FunctionLibraries\` folder to simplify the API. It's highly recommended to look over the templates and functions provided. This can easily be done before installing the plugin by reviewing the \[Github page\](https://github.com/Varian-s-Unreal-Plugins/OmniToolbox/tree/main/Source/OmniToolbox/Public/FunctionLibraries)\\ Many of these libraries contain various functions from either my projects, or been posted onto the Epic forums to solve a specific problem. They also contain functions that - for some unknown reason - Epic have not provided a way to call from blueprint (such as \`GetParentTag\`) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/libraries.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0.md). # 2.6.0 Engine support: 5.3 This update focuses on code quality, deprecating unused properties and general performance. \*\*\* ## Inventory \* Data-Only container style has been added. This container style is highly optimized by not handling collision, dimensions, capacity or anything of the sort. Allowing you to handle the styling of containers purely through widgets, or create a optimized space for hosting item data that the player shouldn't see, such as a hidden wallet. \* Example widget has been added (\*\*WBP\\\_DemoDataContainer\*\* and \*\*WBP\\\_DemoTileDataContainer\*\*) \* Added more helper functions: \* \*\*IsSpacialContainer\*\* \* \*\*IsSpacialStyle\*\* \* \*\*DoesContainerSupportTileMap\*\* \* FS\\\_InventoryItem -> \*\*Item\*\* has been renamed to FS\\\_InventoryItem -> \*\*ItemAsset\*\* \* Added \*\*GetLocalInventoryComponent\*\* function to help those who want the inventory component to live on something other than the player pawn. \* \*\*GeneratedItemIcons\*\* has been moved to the C++ component. \* \*\*OldItemData\*\* has been removed from ItemEquipped delegate. \* Added "Type" option for sorting items. \* Containers \*\*TileTags\*\* can now be modified during runtime and replicate. \[\*\*Documentation\*\*\](https://inventoryframework.github.io/workinginthesystem/tiletags/) added. ## Widgets \* \*\*W\\\_Tile\*\* -> \*\*ParentTile\*\* has been removed. \* \*\*W\\\_Tile\*\* -> \*\*OwningItem\*\* has been removed. \* These two were forcing very heavy math and ForLoops, just to cache tiles that seemingly no one was using. As the codebase has improved, there are better ways of retrieving these values without caching them. \* Deprecated \*\*W\\\_Container\*\* -> \*\*Items\*\* \* Added \*\*GetAllItemWidgets\*\* to replace deprecated variable. ## Crafting \* Added \*\*GetRecipesRequiringItem\*\* async function. \* Added \*\*GetRecipesForItem\*\* async function. ## Bugs \* \*\*UniqueID\*\* was not being assigned in some scenarios in \*\*MoveItem\*\*. \* \*\*InteractingWith\*\* was visible in the details panel for the inventory component. \* The item count while inside the \*\*InventoryHelper\*\* would not display correctly when both values were set to the same amount. \* the cpp file for \*\*A\\\_ItemActor\*\* was not named correctly. \* The InventoryHelper would treat the highlight in list containers as if it was a grid container, making moving items around difficult. \* Items moved from a equipment container to a grid container would not have collision. \*\*\* ## Color Sheet: \*\*functions\*\* - \*\*variable\*\* - \*\*category\*\* - \*\*class\*\* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.6.0.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue.md). # Dialogue This plugins approach to dialogue is nothing special, since dynamic custom output pins are native to \`BlueprintTasks\`, everybody can make their own dialogue system with ease. This more or less serves as an example of how to make your own, alongside bringing an example of how to decorate a dialogue node. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution.md). # Structure and contribution \`OmniToolbox\` comprises of 2 modules: \* OmniToolbox \* Contains various helper function libraries and other things that are only relevant to runtime based logic. \* Runtime module \* OmniToolboxEditor \* Contains developer settings, thumbnail renderer, content browser modification and many other editor-only based changes. \* Editor module ## Creating plugins with OmniToolbox ### Copyright \`OmniToolbox\` is published under the MIT license and everyone has permission to fork it, copy the code, or publish their own version. ### Minimal implementation By minimal, I mean no gameplay features and having the possibility of using your plugin without having OmniToolbox installed. This can be done like so: 1. Add this code to your modules build.cs file: \`\`\`cpp if(Plugins.GetPlugin("OmniToolbox") != null) { PublicDefinitions.Add("OMNITOOLBOX\_INSTALLED=1"); PublicDependencyModuleNames.Add("OmniToolbox"); PublicDependencyModuleNames.Add("OmniToolboxRuntime"); } else { PublicDefinitions.Add("OMNITOOLBOX\_INSTALLED=0"); } \`\`\` 2. Wrap your code with \`#if OMNITOOLBOX\_INSTALLED\` \`\`\`cpp #if OMNITOOLBOX\_INSTALLED Omni\_SetClassIcon(AgentIntelligenceFramework, EntityController, EntityControllerSlate) #endif \`\`\` \`\`\`cpp UTexture2D\* GetThumbnail\_Implementation() { #if OMNITOOLBOX\_INSTALLED if(FEffectDataUIIcon\* EffectIcon = GetStructPtrFromInstancedStructArray(EffectDefinition.Effect.Data)) { return EffectIcon->Icon.LoadSynchronous(); } #endif return nullptr; } \`\`\` \* Blueprints do NOT have the ability to filter code like this. If you add any blueprint code to your project that originates from \`OmniToolbox\`, you now have a hard dependency on \`OmniToolbox\`. \* Instead of checking if \`OmniToolbox\` is installed, I recommend checking by version #### Asset details interface From my testing, there seems to be an issue with Unreal recognizing interfaces while in the editor when it comes to interfaces wrapped with preprocessor macros \`\`\`cpp UCLASS(Abstract, Blueprintable) class AIF\_MASS\_API AEntityController : public AController #if OMNITOOLBOX\_INSTALLED , public II\_AssetDetails #endif \`\`\` The code above will compile and during runtime will continue to work normally, I've even validated this with my other plugins and using other interfaces. But while in the editor, it will not work. Unfortunately, this interface must work while in the editor. If you want to make assets utilize the interface, but still be able to compile the plugin without \`OmniToolbox\` installed, you will have to do this evil hack: \`\`\`cpp #if !OMNITOOLBOX\_INSTALLED class II\_AssetDetails {}; #endif UCLASS(Abstract, Blueprintable) class AIF\_MASS\_API AEntityController : public AController, public II\_AssetDetails \`\`\` This is essentially just creating a new class with the same name if the plugin isn't installed. It's not ideal, but it's the best we can do for now. ## Making contributions \`OmniToolbox\` follows 3 philosophies: 1. Simplify the lives of developers (for example; utility functions, systems or \[macro's\](/varian-docs/omnitoolbox/macros.md) to reduce repetitive work, such as giving assets custom icons) 2. Adding abstract features (for example; \[float providers\](/varian-docs/omnitoolbox/runtime/float-providers.md)) 3. Exposing C++ logic to blueprints (for example; gameplay tags have many functions that for some reason Epic have not exposed to blueprint) Any contribution that wants to be accepted should try and follow these goals. Examples of contributions that would get declined: \* Combat system using GAS \* A combat system is not abstract enough (not all games have combat) and not everyone wants a dependency on GAS \* Prototyping assets, such as materials, widgets, etc \* This can quickly clutter up people's projects and asset validators in some projects might not be happy with these assets. \* While useful, I feel like a separate plugin, specifically designed for prototyping material, should be developed. I might create one to speed up development of my example projects, but there's no guarantee on that. In some cases, it might be better for some people to simply make a pull/feature request for the engine itself. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/structure-and-contribution.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps.md). # First Steps - \[Installing the plugin\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin.md) - \[Asset Manager\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/asset-manager.md) - \[Example Project\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project.md) - \[Adding the component and containers\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/adding-the-component-and-containers.md) - \[Activating the component\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/activating-the-component.md) - \[Custom Interaction system\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/custom-interaction-system.md) - \[Suggested Plugins\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/suggested-plugins.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/first-steps.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/debug-draw-system.md). # Debug Draw system Unreal has had three issue that has annoyed me for a long time; Vislog and the DrawDebug functions aren't cross-integrating, they behave slightly differently, and there's no way to update a previously create debug draw. For example, drawing a capsule around the player, then moving that capsule with the player. 1. If you want to debug something both live and in the vislog recorder, you have to call 2 different functions. 2. \`DrawDebugCapsule\` will center the capsule at the origin point. But \`Vislog Capsule Shape\` will create a capsule with the bottom of the capsule touching the origin point. 3. Functions like \`PrintString\` have a "key", so you can monitor a specific message in the corner of the screen and modify that one. The draw debug functions do not have this. 4. Bonus issue: With the introduction of Mass, it's far easier to do multithreading code that often has to debug draw something. But the debug draw functions can sometimes cause odd crashes when used outside the game thread \`OmniToolbox\` provides numerous functions called \`Draw and Log...\` and then a shape. These functions look to solve all problems in one go. {% hint style="info" %} To disable runtime visualization, use the \`OmniToolbox.Debug.DrawDebugShapes\` console command. It will continue to record vislog shapes. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/editor/debug-draw-system.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_tile.md). # W\\\_Tile There is very little logic or variables handled in this widget, as you have to keep in mind that this widget can end up with hundred copies or more, so it can get bad for memory allocation if overdone and if you don’t manage the variables those tiles are initializing. Creating these tiles is by far the most expensive process I’ve found in this component. It is essential they store as little data and perform as few functions as possible so we can optimize the construction cost. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/classes-and-settings/w\_tile.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/input-nexus/input-link.md). # Input Link When it comes to running meaningful gameplay code, \`InputLinks\` is where that code is stored. Links are tied to an \`InputAction\` and \`TriggerEvents\` to control when their code is ran. When that action is activated with that trigger event, the \`InputLink\` will call \`OnInputActivated\` Input events are handled like so: ![](https://varian.gitbook.io/files/0SLwu36uCBlppPg5RQ6W) \* Links can be dynamically enabled and disabled, for example an ability input being disabled while the ability is on cooldown. \* Links will only receive the input event if: \* They are registered to the specific trigger event that is currently occurring. \* \`CanHandleInput\`returns true \* The link is enabled. \* If the link decides to consume the input, it will prevent the input event from continuing on down the chain of links for that input action. \* To add a input link during runtime, in Blueprints use the \`ConstructObjectFromClass\` node, this will allow you to edit \`ExposeOnSpawn\` parameters as you wish. In C++, use \`NewObject<>()\`. Then call \`AddInputLink\`. \*\*\* ## Runtime Input Links \`InputLink\`'s can be constructed during runtime. Sometimes, all you need is to listen to an input event as if the object is an input link. For example; a GAS ability ![](https://varian.gitbook.io/files/ZrNFptgV7cV1hbdTc2nF) This GAS ability is now receiving input events as if itself was an \`InputLink\`. The events are just being filtered and forwarded through a \`InputLink\`, making it act as a proxy between \`GAS\` and \`InputNexus\`. This method now allows you to utilize all the strenghts of \`InputNexus\` with minimal work and complexity. This ability can now benefit from input buffering, input consumption and more. \*\*\* ## Practical examples \* During the tutorial, you might want to listen to specific input events, such as the movement keys. Normally, you'd now have to hard code this into the player character and have redundant code throughout your entire game. With a \`InputLink\`, you can listen to an input event, execute custom code, then remove it. Separating that logic from the character and not have redundant code being executed throughout the game.\\ I use the FlowGraph plugin to add a input link to the jump and movement input actions during the tutorial and broadcast an event when it happens. The input link has then been designed to remove itself when it hits a broadcast limit. ![](https://varian.gitbook.io/files/UuMvz2GMRSXYHQaj2803) ![](https://varian.gitbook.io/files/1l7WljTl8INnnxbw1A9Q) \* For my project, I've integrated support with \[\*\*ObjectTags\*\*\](https://varian.gitbook.io/varian-docs/object-tags/) so I can natively block \`InputLink\`'s depending on a tag query. Now all I need to do to block movement is fill in what tags would block the movement \`InputLink\`, such as a stunned tag. I never have to repeat this code anywhere, I just need to make my \`InputLink\`'s a child of this tag support class. ![](https://varian.gitbook.io/files/YqtfduFHbGIXfN1SK4Xa) \*\*\* ## Creating custom input links \`InputLink\`'s have several functions for you to override and call. ![](https://varian.gitbook.io/files/TdYGsoyfInfaahllsDWk) {% hint style="info" %} \`InputNexus\` comes with 2 simple examples, which can be found in the \`Links\` folder. {% endhint %} The majority of the time, you'll be overriding either \`OnInputActivated\` or \`CanHandleInput\` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/input-nexus/input-link.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1.md). # 2.10.1 Engine support: 5.4 > The documentation has a new category - \`Systems\` - Some documentation has been moved and some has been added to this category. \*\*\* ## Item Query \* Added a new multithreaded \`ItemQuery\` system, documentation can be found \[\*\*here\*\*\](https://inventoryframework.github.io/systems/itemquery/) \*\*\* ## Inventory \* Added native container UI navigation support, for example using a controller to navigate around a container. Documentation can be found \[\*\*here\*\*\](https://inventoryframework.github.io/systems/uinavigation/) \* Item widgets can now have a custom drag and drop system to help with gamepad navigation. \`Drag and Drop\` documentation has been updated. \* Inventory component now has a reference to the drag widget to help evaluate whether the player is currently dragging an item and retrieving that item. \* Many \*\*GetParentCompoent\*\* functions have been renamed to \*\*GetInventory\*\* \*\*\* ## GAS \* Native \`GAS\` integration has been added through a new module. Documentation can be found \[\*\*here\*\*\](https://inventoryframework.github.io/systems/AbilitySystem/) \*\*\* ## Drivers \* Drivers now have a payload parameter to pass custom data from clients to server. \* Added a new "item ability" driver. Documentation can be found \[\*\*here\*\*\](https://inventoryframework.github.io/systems/AbilitySystem/#item-ability-driver) \*\*\* ## Crafting \* Added native support for "timed crafts". Documentation has been updated. \*\*\* ## Bug fixes: \* The Item actor would be destroyed if the player moves an item from its own inventory if the item was in container 0 and was item index 0 \* The ItemDropped event was not being called. \* ApplyTileOffset could go 1 tile out of bounds. \* Item icons were not updating when unequipping items inside of them. \* Splitting an item as a client on a different component would lead to the original items count not updating. \* Reverted a bug fix from 2.9 where the equipment manager was not removing tags when unequipping an item to fix an issue where the items visuals were not being removed when an item was unequipped by moving the item to another inventory component, such as a chest \* Item icons could stretch or shrink in some cases. \* TryAddNewItem could cause a crash in some cases. \* GetItemsVisual was not working for blueprint equipment on clients \*\*\* ## 2.10.1 Bug fixes: \* Items would not craft if they were missing the \`TimeToCraft\` recipe data. \* Debugging code was being used in \`LootItem\` resulting in it not working as expected. \* Unequipping a static mesh equipment would also unequip the parent actor it was attached to. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/versions/2.10.1.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/place-actor-palette-control.md). # Place Actor Palette control \`OmniToolbox\` provides 2 ways of adding any actor to Unreal's \`Place Actors\` panel. 1. Through the \`Omni\_AddActorToPlacementPaletteCategory\` macro in C++ 2. Through the \`OmniToolbox\` project settings, which is primarily used for blueprints. You can then define your own categories in C++ like so: \`\`\`cpp Omni\_PlacementPaletteCategory( "Agent Intelligence Framework", /\*Category name\*/ "AIF", /\*Display name\*/ "EditorViewport.VisualizeVirtualShadowMapMode", /\*In-engine SVG icon\*/ 0); /\*Order priority - higher number means = closer to the bottom\*/ \`\`\` ![](https://varian.gitbook.io/files/gLhX3c7GeOSJv2mSwvFW) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/editor/place-actor-palette-control.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/float-providers.md). # Float Providers A borrowed concept from \[Hogwarts Legacy\](https://www.youtube.com/live/CeX9uFRfyxE?si=D1rVcFOYZfwgCrfl\\&t=20981). This is a simple instanced struct that will return a float. You can make children of this struct to create new available dropdowns. I use this for my GA base cooldowns. In some cases, I want a scalable float or a runtime float curve. The plugin comes with three examples: ![](https://varian.gitbook.io/files/5aTCa2JgdvtL2du17VGC) ![](https://varian.gitbook.io/files/VxxnnlWtjq3VW6vheuci) To use a float provider, make a variable with \`FOmniFloatProvider\` as the type. You can optionally give it a default value and a default float provider child. \`\`\`cpp UPROPERTY() FOmniFloatProvider Duration = FBasicFloatProvider(5); \`\`\` Depending on the type you're using, you might have to initialize the data float provider like so: \`\`\`cpp Duration.FloatProvider.GetMutable<>().WorldContext = GetWorld(); Duration.FloatProvider.GetMutable<>().BaseValue = SomeFloat; \`\`\` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/runtime/float-providers.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests.md). # Functional Tests {% hint style="info" %} Due to dependency issues with the \`FunctionalTesting\` module, \`OmniToolbox\` can't make a C++ child of \`AFunctionalTest\`. Hence why we use an actor component instead. {% endhint %} \`Vanguard\` offers an actor component designed specifically to be placed on \`AFunctionalTest\` actors called \`TestAssistantComponent\`. It provides several utilities, such as: \* Generate a spreadsheet that displays what sub-tests were successful and what sub-tests failed. ![](https://varian.gitbook.io/files/Hh4i3pjKiob9fV7LYFbZ) This code will generate this spreadsheet (if the \`OmniToolbox.Vanguard.GenerateSpreadsheet\` console variable is set to true) ![](https://varian.gitbook.io/files/PpplNDXP828J4OFItSL5) \* When running a test, a folder with the current timestamp is created that can contain several files. One being a performance log (Do NOT use these numbers to drive your performance metrics if the session was in PIE. Only use these numbers for packaged builds). ![](https://varian.gitbook.io/files/AUigkyIN7vPWCOxsmRf8) The other files can be visual log files or spreadsheets generated from tests. If no file was generated, then that test did not want to generate a spreadsheet and did not use the visual logger. ![](https://varian.gitbook.io/files/t1Hiwbh0ijoW0HUVMHPX) {% hint style="info" %} When doing tests through the project launcher, these files can be found in \`Saved -> StagedBuilds -> Platform (for example; Windows) -> ProjectName -> Saved -> Automation -> Vanguard\` {% endhint %} ## Unreal Insights Integration The assistant allows you to automatically begin and end a trace for the duration of a test. (Enable \`Automatically Start Insights Trace\` in the components settings) When this is used, the assistant also automatically: \* Takes a screenshot when the \`WriteResults\` function encounters an error ![](https://varian.gitbook.io/files/frg2AMXPE4F9zpsqF7yy) \* When a new spreadsheet row is added, we start a new region \* The trace file is moved from the profiling directory and into the \`Vanguard\` folder and renamed to the testers name. {% hint style="info" %} You can drag and drop a \`.utrace\` file into Unreal Insights to open it {% endhint %} {% hint style="warning" %} Stopping a trace can cause a spike in FPS. {% endhint %} ### Notes \* By default, all trace channels are disabled when making a new profile. You will want to f\[amiliarize yourself\](https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-insights-reference-in-unreal-engine-5#tracechannels) with them and enable the ones you want. \* The more you enable, the larger the trace file and potentially more performance overhead. ![](https://varian.gitbook.io/files/LZfmySrzWkPtalMOen9D) \## Visual Logger Integration The assistant allows you to automatically begin and end a Vislog file for the duration of a test. (Enable \`Automatically Record Vislog\` in the components settings) This gives you a file you can open through the Visual Logger tool inside of the Unreal editor (\`Tools\` -> \`Debug\` -> \`Visual Logger\` ![](https://varian.gitbook.io/files/4iJj2y8q68C0QUWqG3yc) ![](https://varian.gitbook.io/files/7sPeTzkcJQ3N36e4XpzD) You can now see any \`Visual Logger\` shapes your test performed on the timeline. ![](https://varian.gitbook.io/files/2zFMNmZOiPSdxG4V3YFH) \* I recommend using \`OmniToolbox\`'s \`DrawAndLog(Shape)\` functions to see the shapes both during the test and in the Visual Logger recording. ## Performance requirements \`Vanguard\` allows you to mark a test as failed depending on if a large enough hitch/lag spike was detected or if a target game thread time was not achieved. There's a few notes to take around this system as there are big plans in the future to expand this: \* You can find the settings to control this inside \`Editor Preferences -> Plugins -> Vanguard Testing Settings\`. \* It's placed inside the editor preferences and not the project preferences because we want each computer to have its own settings. \* As of \`0.3\`, the \`Scalability Perf Test Settings\` is not yet implemented. Use the settings above it. \* This combined with the point above is aiming to achieve a test environment where you can have a computer with a bad CPU/GPU have appropriate settings for specific scalability settings.\\ For example, a 5 year old cheap CPU might target 60 FPS on low scalability (index 0). Where as a modern expensive CPU might target 180 FPS on low scalability. There's no timeline for when this feature will be implemented or how much the API will change. {% hint style="info" %} The API might change in such a way where you list a CPU by its product name and give that specific CPU a target. {% endhint %} Do note that Epic \\\*might\\\* be \[working on something similar\](https://youtu.be/aqNL8tdfIHI?si=4kkMIQKk5pcJLAxq) to this, but focusing specifically on performance. Depending on how this advances, this feature might get scrapped or focus only on CPU performance. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/vanguard/functional-tests.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading.md). # Saving and loading The demo includes an extremely basic save and load system. I will not be implementing anything advanced, because if you ever decide to remove the inventory system from your project, you will have to extract the save and load system from this project. You should have some system which you can bring to all of your projects. Everything is saved in structs, so it should be compatible with your save system. It’s up to your save and load system to manage this, but if you need an example, the demo project has an example of a simple save and load system. But let’s be honest, Unreal Engine’s blueprint save system is not very good and lacks too many fundamental features. If you are going to make your own save and load system, I suggest using C++ as the current Blueprint functionality of Unreal's save and load system is really bad. There are a few C++ saving and loading system tutorials on Youtube which cover how to serialize nearly any data you want, all of which should be compatible with this system. ## Things to keep in mind UniqueID's must reset whenever you try to save containers and items. The parent component object reference can not be saved. The component has a function called \*\*GetContainersForSaveState\*\* which provides you with a copy of the containers, but some data has been modified to be compatible with save files. I recommend looking inside this function to better understand what can not be stored in the save file. ## Multiplayer When a client connects, it's up to your save system to assign them the appropriate container settings. ## Equipment When you load a save, you might want some equipment the player has to become visible. You have two options: 1. The component has a delegate for when it is started, from which you can assign a Trigger Filter inside of the Equipment Item Component. These should be instantaneous attachments and no animations should occur at the same time as they can cancel each other before any critical notifies occur. 2. Your save and load system has the ability to restore actors. From here you must ensure the restored actor gets the owning items UniqueID as a tag, unless you've also implemented a way to save the owning items UniqueID. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/systems/saving-and-loading.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests/decorator.md). # Decorator The decorator for the quest node contains an example of retrieving the value of a pin on the node to drive its visuals. Where as usually you'd enable \`AllowInstance\`and then have the decorator be driven by the instance. But since the quest node is simple enough that it doesn't require an instance, it's far simpler to just retrieve the value of the \`QuestAsset\`pin. ![](https://varian.gitbook.io/files/siCekVbxFP6jFGcsedZm) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/quests/decorator.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/input-nexus/input-link/input-buffer.md). # Input Buffer Each \`InputNexus\` can temporarily suspend events to \`InputLinks\` that enable input buffering. Buffers are separated by \`InputBufferChannels\`, which is a TMap of gameplay tags and \`InputLinks\`. When the channel is opened, this buffer is populated by any links that attempted to be activated but were stopped, while also storing the last action value. When the channel is closed, the \`InputLinks\` will act as if the player just pressed the button, but using the last stored action value that was used. \* Keep in mind, this is not a queue system. Only the last input event will be repeated. {% hint style="info" %} To open a buffer channel, call \`OpenInputBufferChannel\`, then to close it, you call \`CloseInputBufferChannnel\`. {% endhint %} Inputs are buffered inside \`UInputLink\` ➝ \`BufferInput\`. If you wish to override or customize how a link handles buffering, override this function. Once the channel is closed, all the inputs are released like so: ![](https://varian.gitbook.io/files/nW5sjMFphYecbRATvvYS) Do note, this follows the same code execution as when an input is pressed, as in, checking if it's enabled, can handle the input and consumption {% hint style="warning" %} If you have the \`InputLink\` trigger on the \`Completed\` event, the released buffered input might not trigger the way you'd expect. Since the \`Completed\` event can reset the input value, that means the data inside of \`FInputActionValue\` will be null. {% endhint %} To cancel an \`InputLink\`'s buffered input, call \`FlushBufferedInput\` \## Animation based buffering \`InputNexus\` provides an animation notify state that allows you to open and close a input buffer channel ![](https://varian.gitbook.io/files/cgd1M7Jo0MywgYUBhho8) When it starts, the buffer channel is opened. When it ends, the buffer channel is closed. ![](https://varian.gitbook.io/files/KBh4wFQjfJh3NeTIC2Pw) \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/input-nexus/input-link/input-buffer.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/input-nexus/to-do.md). # To-do This to-do list contains features that might get released in the next update, worked on in the future or is in progress. \* \[ \] UI or game input \`InputLink\`'s \* \[ \] \`Cog\` debugger should show what buffer channels are open/closed \* \[ \] Add and remove \`InputLink\`'s through Modular Game Features --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/input-nexus/to-do.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/omnitoolbox/editor/asset-validation.md). # Asset Validation \`OmniToolbox\` provides a module called \`OmniToolboxValidation\` that provide several asset validators that suit all projects and providing a project settings category to control them. The default asset validation system has one critical flaw; Any marketplace assets you import or utilize in your project might fail the validator (such as a naming convention). But modifying these external assets can make updating them very difficult. \`OmniToolbox\` looks to optionally solve this through its project settings. You can make all validators that are children of \`UOmniAssetValidator\` ignore certain paths by adding those paths to the \`Directories To Ignore\` array. {% hint style="info" %} The \`FDirectoryPath\` struct seems to be bugged as of 5.7, which is the struct that provides a dropdown view of the projects directories. You might have to restart your project for your modifications to be registered. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/omnitoolbox/editor/asset-validation.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue/decorator.md). # Decorator The dialogue task decorator provides an example of how to handle images inside a node. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/blueprint-tasks-extension/dialogue/decorator.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/test-environment.md). # Test Environment The Test environment for \`IFP\` utilizes \`OmniToolbox\`'s automation framework to power a plugin called "IFP\\\_TestingEnvironment". This plugin can be accessed through \`IFP\`'s github organization. \* \[How to request access to the Github organization\](/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/example-project.md#github-repository-access) \* \`OmniToolbox\` \[Fab page\](https://www.fab.com/listings/db6ebd6c-e95d-40c3-9a9d-1c9d815e6295) and \[Github repo\](https://github.com/Varian-s-Unreal-Plugins/OmniToolbox) This environment hosts a number of testers to validate \`IFP\` is functioning as expected and provide numerous small code-snippets for how to utilize IFP {% hint style="danger" %} The test environment is NOT for testing replication. Results of these tests only apply to single player and server. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction/test-environment.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction.md). # Introduction \* This plugin was created for an open-world game that had very strict performance requirements. Because of this, most logic is handled in C++ and only minor , designer-based things are handled in Blueprint.\\ The design architecture is also designed to give programmers more control of when widgets and data is initialized to not just optimize memory, but also reduce lag spikes. The architecture has also been made in mind for large-scale projects by providing useful editor tools. \* The architecture was made with designers in mind, so certain C++ functions can be overridden in Blueprints and some functions are only needed on the Blueprint level. This system is not meant to be purely C++ or Blueprints, rather a healthy mix of the two. If you can't write in C++ or don't have access to anyone who can write C++ code for you, the current functions should allow for you to create nearly any Blueprint logic you should need. \* The plugin was designed to be \[\*\*installed locally\*\*\](/varian-docs/inventoryframework/inventory-framework/introduction/first-steps/installing-the-plugin.md) to your project, not the engine. \* Many things have been designed to be as abstract as possible and assume as little as possible about YOUR project and creation process. I do not want to dictate any creative vision and I do not want to step on any toes. I’ve tried to keep the system as painless as possible for you to integrate YOUR systems and assets with this inventory system, such as an attribute, ability or crafting system. Even though some of those things are provided out of the box, every project is unique and has specific requirements that you may have already solved. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/inventoryframework/inventory-framework/introduction.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. --- # Unknown \> For the complete documentation index, see \[llms.txt\](https://varian.gitbook.io/varian-docs/llms.txt). Markdown versions of documentation pages are available by appending \`.md\` to page URLs; this page is available as \[Markdown\](https://varian.gitbook.io/varian-docs/welcome.md). # Welcome Welcome to the main source of documentation for all of my plugins! Below are shortcuts to my plugins. You can also hover over the top left dropdown. ![](https://varian.gitbook.io/files/9efNlI9PYBQPzR10G7xk) Paid-only plugins: | | | | | | --- | --- | --- | --- | | Inventory Framework | * Design your perfect inventory system | | [https://varian.gitbook.io/varian-docs/inventoryframework](https://varian.gitbook.io/varian-docs/inventoryframework) | | Input Nexus | * Streamline and componetise your input actions | | [/spaces/oMPMkfK8Z7Abx42Ut6mi](https://varian.gitbook.io/spaces/oMPMkfK8Z7Abx42Ut6mi) | Free, much smaller plugins: | | | | | | --- | --- | --- | --- | | OmniToolbox | * A utility plugin, which some of my plugins depend on | | [/spaces/HaVAFyKjs3d16ljfQ2o0](https://varian.gitbook.io/spaces/HaVAFyKjs3d16ljfQ2o0) | | Tags Metadata | * Add simple metadata to gameplay tags | | [/spaces/k78LHfXaaau9UrBYk0Pe](https://varian.gitbook.io/spaces/k78LHfXaaau9UrBYk0Pe) | | Object Tags | * Global tag system supporting all UObjects | | [/spaces/jP5XAKMs1xUM2psZ0ZK9](https://varian.gitbook.io/spaces/jP5XAKMs1xUM2psZ0ZK9) | | Tag Facts | * Simple fact database for keeping track of events. | | [/spaces/GjNOeFzjjRbJR8VE6VXy](https://varian.gitbook.io/spaces/GjNOeFzjjRbJR8VE6VXy) | | | | | | Private or in-development plugins. Some of these plugins are either for my personal projects and stored here so either I or team members can view it. {% hint style="info" %} If any of these interest you, you can message me on Discord and the plugin could potentially be shared with you. {% endhint %} | | | | | | --- | --- | --- | --- | | Object Recycler | * Object pooling system to help with performance | | [/spaces/tAr71XXXtm6BySwwYkT3](https://varian.gitbook.io/spaces/tAr71XXXtm6BySwwYkT3) | | Hermes | * Global and local messaging system. | | [/spaces/mntIpWUvlipeLfrUqPPF](https://varian.gitbook.io/spaces/mntIpWUvlipeLfrUqPPF) | \--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the \`ask\` query parameter: \`\`\` GET https://varian.gitbook.io/varian-docs/welcome.md?ask= \`\`\` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections. ---