Inspection system #

---

Introduction #

The Inspection System is a modular Blueprint framework for presenting readable, audible, and viewable interactables to the player. It supports traditional item inspection, readable documents, audio logs, video playback, pickup-oriented inspection, and world-space inspection where the actor remains in the level instead of being moved into a model viewer.

At a high level, the system is built around a shared inspection data structure, a central player-owned inspection component, and a set of inspectable actor blueprints that decide how the experience is presented. A single data row can define the inspectable’s type, visual representation, document pages, optional narration, optional reaction dialogue, optional databank injection, and playback configuration.

The system is deliberately data-driven. In the common setup, an inspectable actor references a row in DT_Inspection and resolves its full F_Inspection payload at runtime. For more custom cases, the same actor can bypass the row-handle workflow and use custom inspection data supplied directly via exposed variables.

• Supports multiple inspection experiences through one shared data model.
• Lets actors resolve inspection data from DT_Inspection or from directly supplied custom data.
• Separates presentation logic across specialized child blueprints instead of forcing one actor to handle every case.
• Tracks inspected entries so first-time-only reactions can be gated cleanly.
• Can optionally inject entries into a databank and optionally grant the inspected item to inventory.

Inspection types and intended use cases shown in the example map.

---

Inspection Types at a Glance #

The enum and demo content show the following supported inspection modes:

---

Core Assets and Data Model #

The system revolves around one master struct, one data table, a small set of supporting structs, and a component/actor split that separates manager logic from presentation logic.

Core enums, the main F_Inspection struct, and the shared data table asset.

F_Inspection is the central payload passed through the system. It contains all data needed to present an inspectable: identity, viewing rules, mesh references, document contents, audio configuration, reaction behaviour, playback settings, and databank options.

---

Enumerations Explained #

Creation type is important because multiple flows reuse the same data. The same inspectable can be opened directly from the world, shown in a fullscreen overlay, or surfaced inside an information/databank panel depending on where the interaction originates.

---

Structures Explained #

The inspection system is intentionally split into focused structs so each part of the payload remains understandable and reusable. DT_Inspection rows are built from these same structures, which means the live runtime data mirrors the authoring workflow in the editor.

Expanded struct definitions used by the system.

---

F_Inspection #

---

F_Inspection_General_Settings #

---

F_Inspection_Viewing_Settings #

---

F_ItemInspection_MeshInfo #

---

F_Inspection_Document_Details #

---

F_Inspection_Audio_Settings #

---

F_Inspection_Reaction_Settings #

---

F_Inspection_Playback_Settings #

---

F_Inspection_Databank #

---

Dt_inspection #

DT_Inspection is the main authoring surface for the system. Each row stores one complete F_Inspection payload, which means a designer can configure documents, audio logs, item view settings, reactions, databank behaviour, and playback data without changing Blueprint logic.

DT_Inspection row editing, with a placed actor example referencing a row directly from the details panel.

• Placed inspectable actors can point to a DT_Inspection row through the Inspectable Row handle.
• If Use Custom Inspection Data Via Expose On Spawn is disabled, the base actor resolves its data from the row handle at runtime.
• The same row format works for multiple inspection types, which keeps authoring consistent across documents, items, audio, and video.
• For bespoke runtime cases, the row-driven workflow can be bypassed and the actor can use directly supplied inspection data instead.

The data table structure is especially useful for teams selling the system to buyers, because it gives them one obvious editor surface for most common use cases. The actor blueprint then acts as the presenter rather than the place where all content must be hardcoded.

---

Ac_inspection #

AC_Inspection is the live manager that receives create, close, destroy, and inspected-entry events. The provided graphs show that it is responsible for spawning or updating the active model viewer, caching the created inspection widget, removing the widget when inspection ends, and maintaining the list of already inspected IDs.

AC_Inspection routes create/close/destroy events and owns the active model viewer lifecycle.

---

Bp_inspect_base #

BP_Inspect_Base is the common actor used for standard inspectables. It holds the shared components, exposes the inspection data setup in the details panel, resolves DT_Inspection rows when needed, and coordinates the standard interaction pipeline.

BP_Inspect_Base resolves inspection data, plays reactions, and optionally injects databank content.

The base blueprint is therefore both the content bridge and the policy layer. It decides where data comes from, when databank content should be created, when a dialogue line should be spoken, and when the inspectable should be considered already seen.

---

Specialized Inspect Actors #

The specialized child blueprints reuse the base data model but present it differently depending on the intended gameplay result.

Representative runtime flows for modelviewer, pickup, and world inspection children.

---

Bp_item_model_previewer #

BP_Item_Model_Previewer is the visual inspection actor spawned by AC_Inspection. It owns the camera, light room, item pivot, render handling, zoom and rotation behaviour, video material setup, and examination traces while an item is actively being viewed.

---

Core Runtime Flows #

The provided graphs reveal a few recurring runtime patterns that buyers should understand, because they explain why the system is flexible even though it is data-driven.

---

1) Standard modelviewer inspection flow #

A placed inspectable receives interaction, resolves its F_Inspection payload, optionally queues databank and reaction behaviour, then asks AC_Inspection to create or update the modelviewer. AC_Inspection either updates the existing previewer or spawns BP_Item_Model_Previewer and stores the active reference.

• The create request carries both the F_Inspection payload and the creation type.
• The previewer is designed to be reused for fast successive inspections instead of always being recreated.
• The created inspection widget is cached so it can later be removed cleanly.

---

2) World inspection flow #

BP_Inspect_World skips the standard modelviewer path and instead creates the inspection widget directly, passes in inspection data and reaction type, blends the player view to its own camera, disables movement, and binds a widget-deactivated event for cleanup.

• This is the correct flow for screens, terminals, fixed world displays, or any inspectable that should stay where it is.
• If playback settings are configured, the world actor also applies the video material to the configured mesh slot and opens the media source.

---

3) Databank injection flow #

The base actor checks the databank block of F_Inspection and either injects an explicit databank payload or builds one from inspection fields such as title, description, icon, audio, and video.

• This allows the inspection system to serve both as a live interaction and as a content authoring bridge into the databank.
• The row does not need a bespoke databank entry unless the buyer wants tighter control over how the databank card is assembled.

---

4) First-inspect reaction flow #

Before playing a sentence, the base blueprint checks whether the inspectable tag already exists in the component’s inspected list. If it has not been seen before, the first-inspect response can be used; after that, subsequent inspections fall back to the standard predefined dialogue flow.

• This is how the system avoids repeating introductory bark lines every time the same object is opened.
• The inspected-state cache is maintained by AC_Inspection rather than by each actor separately.

---

5) Pickup inspection flow #

BP_Inspect_Pickup shows how inspection can be fused with item data and pickup behaviour. It constructs a custom F_Inspection payload from item attributes, opens the inspect UI, and when the player confirms pickup it routes back into the parent interaction logic.

• This is useful when an item should be looked at before being claimed.
• The same flow can still add databank data and inventory output if the configuration calls for it.

---

Details Panel / Important Variables #

The world instance screenshot shows the intended buyer-facing setup: the placed actor exposes a simple toggle for direct custom data and an Inspectable Configuration block that can either store a full F_Inspection payload or point to a DT_Inspection row.

Example placed BP_Inspect_Modelviewer instance using a DT_Inspection row.

---

How to Use and Extend the System #

Below are the most likely questions a buyer will have when first integrating the system. These are written deliberately as practical setup guides rather than low-level Blueprint commentary.

---

How do I create a simple readable document? #

1. Create or reuse a placed BP_Inspect_Base or BP_Inspect_Modelviewer actor.
2. Leave Use Custom Inspection Data Via Expose On Spawn disabled.
3. Assign DT_Inspection as the data table inside Inspectable Row and select or create a row.
4. In that row, set Inspectable Type to Document Read or Document Narrated.
5. Fill in Document Title and Document Contents, and optionally assign Document Narrated Audio.
6. If you want the player to rotate and zoom the physical document mesh, make sure the mesh and viewing settings are also populated.

---

How do I add a standard inspectable item that the player can rotate and zoom? #

1. Create a DT_Inspection row and set Inspectable Type to Item Inspection.
2. Populate Mesh Settings with a static mesh or skeletal mesh.
3. Adjust Viewing Settings such as Min Zoom FOV, Max Zoom FOV, Distance From Object, and Base Rotation Offset.
4. Place a BP_Inspect_Modelviewer in the world and point Inspectable Row at the row you created.
5. On interaction, the system will create the model viewer and hand the payload to BP_Item_Model_Previewer.

---

How do I use custom data instead of a DT_Inspection row? #

1. Enable Use Custom Inspection Data Via Expose On Spawn on the placed actor or when spawning it dynamically.
2. Populate the Inspectable Data struct directly.
3. This is the better option when the object is generated at runtime or when its text, icon, or mesh must be assembled from another system such as item data.

---

How do I make an inspectable add itself to the databank? #

1. Open the row or inline payload and expand the Databank block.
2. Enable Should Add Item To Databank.
3. Either provide a specific databank payload override or leave the override empty so the system builds databank information from the inspection payload.
4. Set the databank category tag so the entry is organized correctly.

---

How do I make the player hear a line only the first time they inspect something? #

1. Populate Reaction Settings.
2. Assign the normal predefined dialogue and then populate First Inspect Response for the one-time variant.
3. Make sure the inspectable tag is unique, because inspected-state tracking is tag-driven.
4. Once the item is inspected, BP_Inspect_Base adds the tag to the component cache and subsequent inspections will not reuse the first-time response.

---

How do I create an audio log? #

1. Set Inspectable Type to Audio Recording.
2. Fill Audio Settings with the display name and sound asset.
3. Enable Auto Play if you want playback to begin immediately after opening the inspectable.
4. You can still combine this with reaction settings or databank injection if desired.

---

How do I create a video or screen-based inspectable? #

1. Use BP_Inspect_World when the video should remain on the actor already placed in the level.
2. Set Inspectable Type to Video Playback.
3. Populate Playback Settings: Media Player, Media Source, Video Material, target material slot index, and looping/autoplay options.
4. Place the actor, verify the correct mesh slot index, and test the cleanup path to ensure the original material is restored when inspection closes.

---

How do I inspect a pickup before the player collects it? #

1. Use BP_Inspect_Pickup.
2. Let it construct or receive the inspection payload from item data.
3. When the player confirms the pickup, the child blueprint routes back into the parent interaction logic and can still use the inventory/databank rules from the inspection data.

---

How do I make a world inspectable instead of moving the item into a model viewer? #

1. Use BP_Inspect_World.
2. Set up its SpringArm, Camera, and optional MediaSound components as needed.
3. Tune Target Arm Length and camera blend values so the inspection view feels correct.
4. This is the best option for terminals, control panels, wall notes, screens, and environmental props that should not be detached from the world.

---

How do I tune rotation and zoom? #

1. Use Viewing Settings inside F_Inspection.
2. Allow Rotation and Zoom must be enabled for both rotation and FOV zoom input to function.
3. Use Base Rotation Offset to correct awkward default orientation.
4. Use Min/Max Zoom FOV to clamp how close and how far the player can zoom.
5. Distance From Object should be used together with mesh offsets so the item is framed correctly from the moment it opens.

---

Summary #

The Inspection System is a flexible presentation framework rather than a single hardcoded interaction. One shared data model powers documents, items, audio logs, video playback, databank entries, and world-space inspection. AC_Inspection manages lifecycle and inspected-state tracking, BP_Inspect_Base resolves and prepares content, specialized child blueprints decide how the experience is presented, and BP_Item_Model_Previewer handles the live visual viewing experience when a model viewer is needed.

For a buyer, the main strength of the system is that most content creation happens in DT_Inspection and in placed actor details rather than inside Blueprint graphs. Once the author understands how the shared F_Inspection payload is structured, they can build a wide range of inspectable content without changing the core framework.