Interactive Loadout Manager

PROJECT OVERVIEW

What ILM is

ILM turns viewer-controlled gear into a managed stream system instead of a single random wheel or one-off command.

VIEWER-CONTROLLED LOADOUTS

Requests can affect individual gear, full builds or an entire squad.

Interactive Loadout Manager allows supported viewer interactions to choose or randomize parts of a Helldivers 2 loadout while keeping existing selections organized. New requests wait in structured queues instead of immediately replacing gear that is already active.

The same system can manage one player or a full four-player squad, keep different request durations separate, apply game-aware restrictions and present results through stream-friendly spinner and active-loadout displays.

VIEWER REQUEST→ CHOOSE / RANDOMIZE→ QUEUE→ ACTIVE LOADOUT→ ON STREAM

01 Controlled Interaction

Viewer choices enter a managed queue instead of directly overriding the current loadout.

02 Specific or Random

Requests can target a specific item or use ILM's configured randomization pools.

03 Duration Aware

Selections can be tied to a Mission, Operation or longer stream-level duration.

04 Squad Aware

Up to four players can carry separate active selections with squad rules still enforced.

CURRENT v0.2.5

What the current system can control

The current development line covers the major Helldivers 2 loadout categories, complete saved builds and several non-gear choices.

S

Stratagems

Four Stratagem positions per player with duplicate and restricted-category rules.

P

Primary

Primary weapons can be selected, randomized, queued and assigned independently.

2

Secondary

Secondary weapons use their own request and randomization pool.

T

Throwable

Throwables are handled as a dedicated gear type.

A

Armor

Light, Medium and Heavy armor can participate in the same interaction system.

B

Booster

Booster handling includes squad-aware duplicate protection.

D

Difficulty

Difficulty can be selected or randomized as its own interaction type.

E

Enemy

Terminids, Automatons and Illuminate can be selected independently.

L

Complete Loadouts

Compatible saved builds can be requested as one entry and can expand into their contained selections when activated, allowing full builds to use the same viewer-request and queue system as individual gear.

ILM CONTROL PANEL

The main place a streamer actually runs ILM

The Control Panel brings the parts used during a live session into one dedicated ILM interface instead of requiring constant changes inside Streamer.bot or individual project files.

DAY-TO-DAY CONTROL

Most normal ILM operation happens from its own Control Panel.

Once the current Streamer.bot actions and OBS browser sources are configured, the Control Panel becomes the working surface for equipment availability, random rolls, requests, active gear, waiting queues, players, saved loadouts and broader ILM configuration.

That separation matters during a stream. Viewer interaction can keep running through Streamer.bot while loadout decisions and queue management stay inside an interface built specifically for ILM.

01

Gear Pages

Dedicated pages keep Stratagems, Primary, Secondary, Throwable, Armor, Booster, Difficulty and Enemy controls separated and easy to identify.

02

Enable / Disable Items

Items can be included or removed from active selection pools without deleting the underlying equipment data.

03

Randomization Weight

Supported items can use different weights, allowing some results to appear more or less often while still remaining available to the randomizer.

04

Manual Random Spins

Random selections can be triggered directly from the Control Panel without waiting for a viewer interaction.

05

Manual Queue Requests

Requests can be added directly with requester information, duration and priority when a manual entry is needed.

06

Active & Waiting State

Current selections and upcoming requests remain visible from the same management area, making it easier to understand what is active and what is next.

07

Squad Controls

Player 1–4 states, mirroring behavior and queued player selections can be managed without rebuilding separate stream systems for each squad member.

08

Loadouts & Profiles

Complete saved builds and broader ILM profiles have dedicated management areas instead of being mixed into individual gear lists.

09

TTS & Interaction Options

Stream-facing feedback options can be controlled alongside the rest of the ILM workflow rather than treated as a separate project.

STREAM DISPLAY SYSTEM

The audience sees the result, not the control interface

ILM separates operator controls from stream-facing browser displays so the working interface can stay off-screen while viewers receive a clean presentation of the current loadout.

ACTIVE LOADOUT DISPLAY

Current gear stays readable after the roll is over.

The main display presents the active selections being used by the tracked player or squad. Player-specific information can remain visible while waiting requests stay out of the main presentation until they actually become active.

Mission, Operation and longer-duration indicators help communicate why an item is still present and how long that request is expected to remain relevant.

P1–P4Player-Focused Layouts

Tracked squad members can have their own active loadout presentation.

O / M / SDuration Labels

Request duration can stay visible with the active selection.

IMGGear Artwork

Equipment imagery makes the display readable at a glance during gameplay.

STATEActive State Only

Waiting requests remain separate from gear that is currently in use.

SPIN

Dedicated Spinner

Random selections have their own animated reveal instead of silently changing the active loadout. The spinner gives the audience a clear moment of anticipation before the result is committed to the request flow.

RESULT

Result Presentation

The selected item is held briefly after the spin so the result can be understood before the stream returns to the normal active-loadout display.

DISPLAY EDITOR

Stream presentation has its own editor

ILM does not require the stream-facing display to be treated as a fixed, untouchable browser page. A dedicated Display Editor keeps presentation changes separate from live loadout management.

PRESENTATION WITHOUT CODE EDITING

Display changes can be handled from an ILM-specific editor.

The Display Editor provides a focused place for configuring how ILM's stream-facing information is presented. That keeps visual setup separate from the Control Panel, which is focused on requests, players and loadout state.

The practical benefit is a cleaner workflow: live operation happens in the Control Panel, while presentation changes belong in the Display Editor. Stream layouts can evolve without turning normal ILM use into a web-development task.

01 Separate From Live Control

Visual setup does not clutter the interface used to manage active requests.

02 Streamer-Friendly Editing

Presentation changes can be approached as display configuration rather than direct browser-page editing.

03 Reusable Stream Setup

A configured display can remain part of the ILM setup while day-to-day loadout state changes independently.

04 Room for Future Games

The editor direction supports a future where different games can require different types and display needs.

FOR STREAMERS

Designed around live audience interaction

ILM is built to turn audience-controlled loadouts into something practical to run during an actual broadcast: requests come in, queues stay organized, the Control Panel keeps the operator informed and dedicated displays show the audience only the information that belongs on stream.

CHAT

Twitch & YouTube Requests

Supported chat and redemption flows can submit loadout requests using the viewer's name, requested gear type and intended duration.

Viewer-triggered requests
Requester names carried through the system
Mission / Operation / Stream durations
Formatted request and result messages

OBS

On-Stream Displays

Browser-source displays show active loadout information separately from the control panel, keeping the stream presentation clean.

Active player loadouts
Per-player gear display
Duration indicators
Dedicated spinner presentation

TTS

Optional Voice Feedback

Request and result events can optionally trigger TTS so major viewer interactions can be heard without constantly watching chat.

Request acknowledgement
Approved result feedback
Separate request/result toggles

QUE

Viewer-Friendly Queue

Queue summaries can be surfaced through chat so viewers can see upcoming requests and understand why a selection has not become active yet.

Top / Priority / Normal levels
Mission / Operation / Stream labels
Upcoming request summaries
Waiting requests remain separate from active gear

WHY ILM STANDS OUT

Complex interaction without making every stream feel complicated

The value of ILM is not a single random button. It is the way several streamer problems are brought together: viewer requests, queue order, multiplayer state, game restrictions, randomization, full loadouts, chat feedback and stream presentation all use one coordinated workflow.

01Less Manual Tracking

Active gear and waiting requests do not need to be remembered outside the system.

02Safer Viewer Control

Audience interaction can be fun without allowing every new request to overwrite the current run immediately.

03One-to-Four Player Scale

The same project can support solo play or a full Helldivers squad.

04Built for Broadcast

Control, animation and persistent display are separate parts of the same system.

05Game-Aware Rules

Loadout restrictions remain part of the experience instead of being discarded for the sake of randomization.

06Future-Ready Direction

The planned Core and Game Editor are intended to carry the same interaction model into additional games.

CURRENT REQUIREMENTS

What a v0.2.5 setup currently needs

The current 1.x branch grew around a live-stream workflow and is still closely connected to the applications used to run that workflow.

SB

MAJOR CURRENT DEPENDENCY

Streamer.bot

Streamer.bot is a major part of ILM 0.2.5. It handles much of the viewer interaction, chat commands, redemption flow, queue actions, TTS triggers and coordination needed to run the current system during a live stream.

Current v0.2.5 is not intended to operate independently of Streamer.bot.

OBS

OBS Studio

OBS is used for the browser-source side of ILM, including the spinner and active-loadout displays shown to the audience.

LOCAL

Local Project Files

Configuration, saved state, display pages, spinner assets and related ILM files remain together in the local project package.

SETUP

Configured Stream Setup

A working setup requires the ILM Streamer.bot actions, browser sources, project paths and supported chat integrations to be configured together.

VIEWER REQUESTS

Different requests can have different lifetimes

Duration is part of the request so ILM can distinguish a short change from something intended to remain active longer.

M

Mission

The requested choice applies to the next mission-length period.

O

Operation

The requested choice remains relevant across the operation-length period.

S

Stream

Longer-duration requests can remain associated with the stream session.

Specific choices and random rolls use the same managed request path.

A viewer can request a supported item directly where configured, or trigger a random result from the currently enabled selection pool.

QUEUE SYSTEM

New requests wait instead of taking over

Queue priority makes live interaction manageable when several viewers submit choices close together.

TOP

Top Priority

Highest-priority manual or special requests.

PRIORITY

Priority

Higher-priority interactions that should move ahead of normal requests.

NORMAL

Normal

Standard viewer requests waiting for their turn.

ACTIVE

Currently In Use

Gear already assigned to a player stays separate from the waiting queues.

Waiting entries are preserved when active Mission or Operation gear is cleared, preventing unrelated future requests from being lost.

MULTI-PLAYER SUPPORT

One streamer or a four-player squad

The current Helldivers 2 setup supports up to four tracked players with separate active loadout states.

P1Player 1Required

P2Player 2Optional

P3Player 3Optional

P4Player 4Optional

Separate Loadouts

Each enabled player can hold different active gear.

Mirror or Queue

Additional players can mirror Player 1 or receive their own queued selections.

Duplicate Rules

Cross-player duplicate behavior can be controlled for stricter or more flexible squad setups.

Booster Protection

Squad-aware rules help avoid duplicate active boosters.

SAVED BUILDS

Full loadouts can be part of viewer interaction

ILM can work with individual gear or with complete compatible loadout files.

FULL LOADOUT REQUESTS

Saved builds can enter the same queue as individual gear.

A compatible saved loadout can be treated as one request. When loadout unloading is enabled, that build can expand into the appropriate active slots when it reaches a player.

SEAF

SEAF-LT Compatible

Compatible .ilmloadout files can be shared between SEAF Loadout Terminal and ILM workflows.

PRF

Profiles

Broader ILM setup states can be saved as profiles for different stream configurations.

FUTURE PLANS

Moving beyond the Streamer.bot-dependent 1.x design

The long-term goal is to keep the interaction system while making ILM a standalone platform that can connect to streaming tools instead of depending on them.

ILM 2.0 DIRECTION

A dedicated ILM Core becomes the center of the system.

Future versions are planned around an independent local Core that manages game data, player state, queues, rules and loadout logic. Streamer.bot and OBS remain valuable integrations, but are planned to become optional connections around ILM rather than the system that ILM must rely on to function.

01

Independent ILM Core

Move primary state, queue and loadout logic into a dedicated ILM application so the system can operate without requiring Streamer.bot as its foundation.

02

Optional Streamer.bot Integration

Streamer.bot remains available for chat, redeems and stream automation, but connects to ILM instead of owning the core workflow.

03

Optional OBS Integration

OBS connection and status become an integration layer for displays and stream presentation rather than a requirement for the core application.

04

Add & Remove Games

ILM is planned to support game packages that can be added, selected and removed instead of keeping the project permanently tied to one game.

05

Dedicated Game Editor

A separate editor is planned for creating and maintaining games, types, categories, items, player limits, images and gameplay rules.

06

Game-Specific Player Counts

Player layouts are planned to adapt to each game's own supported player limits instead of assuming the same squad size everywhere.

07

Generalized Types

Future games can define gear and non-gear types without requiring every new type to be hard-coded as a special ILM feature.

08

Game-Specific Rules

Duplicate limits, category restrictions, player limits and other rules can be defined per game and type.

09

Dynamic Control Panel

The Control Panel is planned to adapt its navigation, type pages and player controls to the selected game so a new game does not require a completely separate ILM interface.

10

More Flexible Randomization

Randomization is planned to support selected subsets, stronger filtering and game-specific options without changing the underlying core.

11

Connection Management

Streamer.bot and OBS connections are planned to have clear connect, disconnect and status controls inside ILM.

12

Game-Aware Display Editing

Display editing is planned to evolve alongside the multi-game system so stream presentation can adapt to the types and player layouts used by each game.

13

Expanded Logging

More user actions, results and Core events are planned to be recorded for troubleshooting while preserving useful roll and history logs.

CURRENT PROJECT STATUS

v0.2.5 remains a private development build.

ILM is still under active development and is not currently offered as a public download. The information on this page describes the current project direction and the capabilities of the present development line.