For shared setup guidance, see the Migration Guide and Integration Guide. Use the System Atlas to look up functions, variables, events, components, and ownership references. Use this page for Databank and Codex System-specific setup, runtime behavior, extension points, and integration notes.

Demo-world overview board for the Databank System.

In-game Databank UI example showing nested categories, entry buttons, and the information panel.

Overview

The Databank System is a modular, gameplay-tag-driven knowledge archive for players. It is designed to store readable content such as tutorials, codex entries, faction lore, item records, field logs, archival pages, quest information, and inspection discoveries in a clean, reusable UI.

At a high level, the system is built around two core ideas. First, entries can be authored through a central DataTable so designers can scale content without rewriting logic. Second, entries can also be injected manually at runtime through a struct-based workflow, which makes the system useful for contextual, temporary, or system-generated information.

The demo world shows that each Databank entry is assembled from stacked content sections. These sections are rendered in array order from top to bottom and can mix text, images, hyperlinks, audio, video, and optional dividers. That makes the system flexible enough for both simple one-page entries and longer archive pages with multiple visual blocks.

• Gameplay-tag identifiers are used to find and unlock entries.
• Category tags are used to create menu chapters and subcategories automatically.
• Entries can be authored from DT_Databank or injected at runtime without relying on the table.
• Each entry can control its own button text, icon, button widget class, and information widget class.
• Information screens are data driven and can include text, image, audio, video, hyperlinks, and dividers.
• The demo explicitly shows Guide System and Inspection System integration patterns.

Demo board explaining how a single Databank entry is built from stacked sections.

Adding Databank to the Player Controller

The runtime manager shown in the provided screenshots is AC_PC_Databank_Manager. Based on the naming, exposed variables, and initialization flow, this component is intended to act as the player-owned manager for discovered Databank knowledge.

This manager is responsible for startup entry registration, duplicate prevention, DataTable lookup, manual entry injection, button-class validation, and client/server notification when new entries are unlocked. In other words, the rest of the project does not need to understand how entries are stored internally. Other systems only need to call the manager with an identifier tag or a prepared entry struct.

Why place it on the Player Controller?

• Databank discovery is typically player-specific knowledge, not world-global state.
• A Player Controller component gives UI, quests, interaction logic, and inspection logic one stable place to ask for unlocks.
• Client/server wrappers are cleaner when the manager belongs to the player who owns the knowledge state.
• It avoids duplicating the same discovery state across multiple world actors or widgets.

Details Panel / Important Variables

The manager component exposes a small set of high-value settings plus several runtime containers used during unlock and initialization flows.

Enums Explained

E_SelectionList_Open_Type

The exposed enum shows three values: None, Open First Boxes, and Open All Boxes.

The screenshots do not show the full consuming widget logic for this enum, but the naming strongly suggests it controls the default expansion state of the Databank selection list.

Structures Explained

The Databank System is driven by a small set of focused structs. These define what an entry is, how it appears in the menu, and what content blocks are rendered on the information screen.

F_Databank_Entry

F_Databank_Entry_Instance

F_Databank_Entry_Button

F_Databank_Entry_InformationScreen_Settings

F_Databank_Entry_InformationScreen_Data

F_Databank_Section_Info_Text

F_Databank_Section_Info_Hyperlink

F_Databank_Section_Info_Image

F_Databank_Section_Info_Audio

F_Databank_Section_Info_Video

F_Databank_Entry structure.

F_Databank_Entry_Instance structure.

Data Tables Explained

The provided data workflow is centered on DT_Databank. This table defines authored entries and acts as the primary source when an entry is unlocked by identifier.

DT_Databank

Each row stores a complete F_Databank_Entry definition. The row contains the unique Identifier tag, the Category tag, the button presentation data, and the information screen settings.

• Identifier tags are used by Add Databank Entry From Data Table to find the row.
• Category tags drive the left-hand menu grouping automatically.
• Button Settings control how the entry appears in the selection list.
• Information Screen Settings control what the right-hand information panel renders.
• The table can store simple informational pages, archive entries, equipment records, ammunition records, logs, and media-backed entries.

The sample rows visible in the screenshot include About_Hyper, Ancient Relay, FieldLog_07, The_Silent_Procession, Wooden_Arrow, and Stone_Arrow. That demonstrates the intended breadth of use: broad overview pages, archive-style lore, and item-style codex entries can all live in the same system.

The Ancient Relay sample row is especially useful because it shows a real authored entry: a unique identifier tag, an archive category tag, button text and icon, and an information screen block with text plus an image.

DT_Databank sample rows and the Ancient Relay row setup.

Ancient Relay information screen block showing text, image, audio, and video fields.

Functions to Use

The manager exposes a compact set of functions for initialization, table-based entry unlock, manual entry injection, validation, and lookup.

Core add / register functions

Utility / validation functions

Initialization / startup flow

Client / server flow

The screenshots make the implementation path very clear: Add Databank Entry From Data Table gets a struct from tag, Make Instance Settings From DT converts that authored struct into an instance, then Add Databank Entry performs duplicate prevention, button validation, storage, and notification.

AC_PC_Databank_Manager function list.

Add Databank Entry From Data Table flow.

Make Instance Settings From DT flow.

Add Databank Entry flow and dispatch path.

Button-class fallback validation flow.

Event Dispatchers / Ui Notifications

The screenshots expose two clear notification points: initialization and entry-added events.

The exact dispatcher signatures are inferred from the exposed call nodes. The entry-added call visibly passes New Entry and Select Entry on Activation data, which makes it suitable for UI refresh, popups, guide prompts, and automatic focus behavior.

Categories, Chapters, and Entry Behavior

One of the strongest parts of this system is that category structure is not manually hardwired into the UI. Instead, gameplay-tag hierarchy appears to drive menu chapter and subcategory generation automatically.

Automatic categories and subcategories

• Overview pages can live under overview-style category tags.
• Archive or lore entries can live under archive category tags.
• Item pages can be grouped under broader branches such as Items, then divided into Equipment, Ammunition, and similar subcategories.
• The demo UI shows nested grouping such as Overview -> Games by Hyper and Items -> Equipment / Ammunition.

This is important for scale. Designers do not need to build a custom widget for every chapter. They only need consistent tags.

Stacked information sections

Every information screen entry is built from an array of section blocks. The demo board explicitly states that these sections are rendered top to bottom in the order they appear in the array.

• A section can contain title and description text.
• The same section can also contain image, audio, video, and hyperlink data.
• Create Divider Above allows the author to visually separate one section from the previous one.
• This makes it possible to build longer pages without a one-off custom widget for every entry.

Known entries versus manual injection

The Databank supports both persistent authored entries and temporary/contextual injected entries.

• Known Databank Entries is the live unlocked-entry list.
• Duplicate prevention ensures the same identifier is not added repeatedly.
• Manual struct injection allows one-off entries, temporary quest pages, runtime-generated logs, and system-driven discoveries.
• Override classes and information-data overrides let special entries change how they render without disrupting the standard workflow.

Manual struct injection examples in the demo world.

Random example entries showing automatic chapter/subcategory organisation.

Starting Knowledge and Save-aware Initialization

The startup flow is designed to seed initial entries only when appropriate.

In the Add Starting Entries graph, the manager first waits for a valid pawn, checks whether the character was spawned from save, and only then loops the Starting Databank Entries tag container when it is safe to do so.

• If the player is loading from save, startup seeding can be skipped to avoid overwriting or duplicating persisted knowledge.
• If the player is not loading from save, the manager loops the configured starting tags and adds each entry from DT_Databank.
• After startup work is complete, Call Initialized marks the manager ready and raises the initialization event.

BeginPlay authority flow.

Add Starting Entries flow.

Call Initialized flow.

Audio, Video, and Hyperlink Content

The Databank is not limited to static text and images. The data structures clearly support audio, video, and hyperlink content.

• Audio sections can label the speaker, label the recording, and play a SoundBase asset.
• Video sections use a File Media Source plus stretch settings.
• Hyperlinks provide a button label and a destination string.
• The demo world explicitly includes an audio example, a video example, and a standard text + image example.

The provided media folder screenshot also shows MP_Information_Screen and MP_Information_Screen_Video assets. That strongly supports the intended video playback flow for information screens.

Media assets shown for the Databank information screen/video setup.

Hooking Databank Into Other Systems

The Databank is designed to be a shared service rather than a hardwired lore widget. Other systems can unlock authored entries by identifier or inject manual entries at runtime.

Guide System integration

The demo overview board states that when the Databank is paired with the Guide System, newly unlocked Databank entries can trigger contextual popup widgets. That makes the Databank useful for soft onboarding, tutorial tips, and gentle discovery feedback.

Inspection System integration

The same board states that Inspection System entries can inject Databank entries automatically. That is a strong fit for discovered artifacts, scanned objects, ruins, books, notes, terminals, and environmental storytelling.

General gameplay integration

• Quests can unlock authored pages when the player reaches a milestone.
• Interaction systems can unlock tutorial or codex pages when the player first uses a feature.
• Item systems can add equipment or ammunition entries when the player acquires an item.
• Research or crafting systems can inject new knowledge pages as content is learned.
• Custom widgets can be used for very bespoke entry presentation when needed.

How to Add Your Own Entry From the Data Table

1. Open DT_Databank and create a new row.
2. Set a unique Identifier Gameplay Tag. This is the tag other systems will use to unlock the entry.
3. Set the Category Gameplay Tag. Use hierarchy intentionally, because this is what creates chapters and subcategories in the menu.
4. Open Button Settings and fill in Button Text and Button Icon.
5. Only set Override Button Class if this entry needs a custom button widget. Otherwise let the manager use the default class.
6. Open Information Screen Settings.
7. If the entry can use the standard information screen, leave Override Class empty and fill the Settings array instead.
8. Add one or more Settings array elements. Each array element is one content section shown from top to bottom.
9. For each section, fill the text, image, hyperlink, audio, and video fields you need. Leave the unused content types empty.
10. Save the DataTable row.
11. Unlock the entry by adding its Identifier to Starting Databank Entries or by calling Add Databank Entry From Data Table at runtime.

How to Add a Manual / Runtime Entry

1. Create or fill an F_Databank_Entry_Instance struct in Blueprint.
2. Set the Identifier and Category tags.
3. Fill the Button Text and Button Image fields.
4. Set Linked Button Class only if you want a custom button widget for this entry.
5. Set Linked Information Class if the entry should use a bespoke information-screen widget.
6. If the entry should use data-driven stacked sections instead of a bespoke widget, enable Should Override Information Data.
7. Populate Information Data Override with one or more F_Databank_Entry_InformationScreen_Data blocks.
8. Call Add Databank Entry and pass the prepared instance.
9. Set Select Entry on Menu Open to true when you want the newly added entry to be focused automatically in the UI.

How to Make a Text + Image Entry

1. Create a new Settings array element in Information Screen Settings.
2. Fill the Text.Title field.
3. Fill the Text.Description field.
4. Set Image.Image to the Texture2D you want to show.
5. Set Image.Stretch to the most suitable fit mode for the texture.
6. Leave Audio and Video empty if they are not needed.
7. Enable Create Divider Above when this section should be visually separated from the one above it.

The Ancient Relay example shown in the screenshots follows this pattern: title + description + image, with audio and video left empty.

How to Make an Audio Entry

1. Create or open a section block in the Settings array.
2. Fill the text fields if you want contextual written information above or beside the clip.
3. Set Audio Speaker to the person/source label.
4. Set Audio Name to the clip title.
5. Set Audio to the SoundBase asset you want to play.
6. Optionally pair the clip with an image for extra context.
7. Leave Video empty unless the entry genuinely includes both media types.

The demo world explicitly marks FieldLog 07 as an entry that has an audio file, which is a good reference case for this workflow.

How to Make a Video Entry

1. Prepare the media source used by the entry.
2. Create or open a section block in the Settings array.
3. Fill any supporting text you want shown with the video.
4. Set the Video field to the File Media Source asset.
5. Set the Stretch value that best fits the intended layout.
6. Test the entry in the menu to confirm the information screen widget handles playback correctly.

The media screenshot shows MP_Information_Screen and MP_Information_Screen_Video assets, and the demo world explicitly labels The Silent Procession as a video-backed entry.

How to Add Default / Starting Knowledge

1. Open the manager component settings.
2. Find Starting Databank Entries.
3. Add the identifier tags for the entries the player should begin the game with.
4. Make sure those tags exist as authored entries in DT_Databank if you are using the table-based startup flow.
5. Test BeginPlay in a fresh session rather than a save-restored session so the startup seeding path executes.

This is ideal for tutorials, faction primers, control help, manuals, basic world context, or a starter codex.

How to Open or Highlight a New Entry When It Is Unlocked

1. When calling Add Databank Entry or Add Databank Entry From Data Table, set the Select Entry on Menu Open input to true.
2. Use the entry-added notification to open the Databank menu, show a guide prompt, or highlight the new content for the player.
3. Use this sparingly for important discoveries so the player notices meaningful new information without feeling interrupted too often.

Example Flows

Unlocking an authored codex page from DT_Databank

• A gameplay system decides the player should learn an entry.
• It calls Add Databank Entry From Data Table and passes the entry Identifier tag.
• The manager gets the authored row by tag, converts it into an F_Databank_Entry_Instance, validates its button class, checks for duplicates, and adds it to Known Databank Entries.
• The entry-added notification fires and the UI can refresh or focus the new entry.

Injecting a quest-specific page at runtime

• A quest builds an F_Databank_Entry_Instance directly in Blueprint.
• The quest fills button presentation data and information-data overrides.
• The quest calls Add Databank Entry on the manager.
• The entry appears in the Databank even though it was never authored as a persistent DataTable row.

Starting with default manual pages

• The player begins a fresh session.
• BeginPlay checks authority and startup conditions.
• Add Starting Entries loops the Starting Databank Entries tag container.
• Each listed tag is resolved through the table-based add flow, giving the player an initial library of known pages.

Inspection-driven discovery

• The player inspects an object or artifact.
• Inspection logic unlocks a matching Databank entry or injects a custom one.
• If Guide System integration is enabled, a contextual popup can notify the player that new archived knowledge is available.

Summary

The Databank System is a flexible, data-driven knowledge archive built for scale. It supports authored table entries, manual runtime injection, automatic category hierarchy, mixed media sections, default startup knowledge, duplicate prevention, and player-facing UI notification.

From a technical point of view, AC_PC_Databank_Manager provides the core runtime API. From a user-guide point of view, the main workflow is simple: define an identifier tag, place the entry in a category, author the button and information-screen data, then unlock it through the manager.

That combination makes the Databank System a strong fit for codex pages, archives, item databases, lore, tutorials, inspection discoveries, research logs, and live content expansion without custom widgets for every single page.