Server Performance
Theatrical: Realistic Pack (TRP) uses both client-side and server-side systems.
While most of the heavy visual rendering is performed on each player’s computer, the server is responsible for maintaining the shared operational state of the TRP installation.
Server performance can therefore be affected by systems such as:
- Fixture state updates
- Multiplayer synchronisation
- Theatrical Networks
- Patch Tool registry updates
- FollowMe tracking
- RoboSpot ownership and state
- Rack Node routing
- Art-Net / sACN processing
- Flight Cases
- Disco Ball Motors
- Carried fixtures
- Large numbers of loaded TRP blocks and entities
TRP should therefore be monitored as both a rendering system and a multiplayer gameplay/networking system.
Server vs Client Performance
It is important to distinguish between:
Server Performance
and:
Client FPS
A server can run correctly while a player experiences low FPS because of:
- Volumetric beams
- Fixture models
- Gobos
- Pixel effects
- High graphics settings
Likewise, players can have excellent FPS while the server is struggling with:
- Tick load
- Networking
- Large numbers of loaded systems
- Tracking
- External DMX traffic
- Other mods
A powerful GPU on the server does not automatically improve client rendering performance.
Fixture State
TRP fixtures store and synchronise persistent state.
Depending on the fixture, this can include:
- Network
- Universe
- Address
- Mode
- Fixture Number
- Patch metadata
- Lamp state
- Display state
- Pan / Tilt inversion
- Fixture-specific control state
- Installed gobos
This information must remain consistent between the server and connected players.
Large fixture counts therefore increase the amount of state the server may need to maintain and synchronise.
Loaded Fixtures
Server workload depends more on loaded and active systems than on the total number of fixtures that exist somewhere in the world.
A large venue with many fixtures spread across unloaded chunks may behave differently from a smaller venue where every fixture is loaded and actively changing.
When testing server performance, use the actual production conditions:
- Players connected
- Stage chunks loaded
- Fixtures receiving DMX
- FollowMe active
- Rack Nodes receiving traffic
- Other server mods running
External DMX Traffic
TRP can receive external lighting data through:
- Art-Net
- sACN
Rack Nodes route incoming source universes into generated Theatrical universes.
The server therefore participates directly in the external lighting-control path.
For large DMX installations, consider:
- Number of active universes
- Number of Rack Nodes
- Network stability
- Server network interface
- Other network-heavy server systems
Rack Nodes
TRP currently includes:
- Robe Rack Data 8 RDM — 8 routable ports
- Robe Rack Gateway 12 RDM — 12 routable ports
Multiple racks can operate together on the same Theatrical Network.
Their enabled ports are organised using:
- Node Priority
- World Position
and are mapped to generated Theatrical universes.
For large servers, keep the rack topology stable and intentional.
Frequent changes to:
- Node Priority
- Enabled ports
- Rack placement
- Routing
can cause universe mappings to be recalculated.
sACN Processing
TRP includes its own sACN receiver.
The receiver subscribes to the universes required by configured rack ports and processes usable DMX slot data before forwarding it into the server/Theatrical network path.
It rejects:
- Preview data
- Terminated streams
- Non-DMX start codes
Usable data is normalised to a 512-channel universe.
Large numbers of externally active universes can therefore contribute additional network and server processing.
FollowMe
FollowMe is a server-side tracking system.
A configured tracker can control up to:
12 compatible fixtures
The system continually updates loaded and correctly addressed fixtures so they aim towards the tracked player or entity.
Large numbers of simultaneous FollowMe systems can add more server-side work than static fixture operation.
For large productions, use FollowMe only where it is actually required.
RoboSpot
RoboSpot stores and synchronises:
- Fixture bindings
- Presets
- Groups
- Calibration
- Active camera
- Control settings
- Operator ownership
One station can bind up to:
12 compatible fixtures
and only one player can actively operate a station at a time.
Multiple RoboSpot stations can be used, but they should be treated as active multiplayer control systems rather than purely decorative blocks.
Patch Tool
The Patch Tool reads from TRP’s live registry of registered DMX fixtures.
Its client periodically requests an updated fixture scan approximately every:
80 ticks
or around:
4 seconds
and can also request manual refreshes.
For normal use this is manageable, but constantly refreshing or having many operators repeatedly scanning a very large rig can create additional server activity.
Flight Cases
Functional Flight Cases include persistent state and movable entity behaviour.
They can:
- Store fixture counts
- Open / close
- Become movable entities
- Be grabbed by players
- Return to block form
Only one player can control a grabbed case at a time.
Large numbers of simultaneously movable case entities may create more server work than static closed cases.
Survival-Friendly Fixtures
When survivalFriendlyFixtures is enabled, fixtures can become physically carried entities.
The system can restrict player inventory behaviour and preserve complete fixture block-entity data while carrying.
For large survival servers, remember that physically carried fixtures are more complex than ordinary static blocks.
Disco Ball Motors
Disco Ball Motors can operate in:
- Manual Mode
- DMX Mode
When receiving DMX, they process:
- Reflection Dimmer
- Rotation Speed
- Rotation Direction
If valid recent DMX is lost, the motor stops its reflection output and rotation after approximately:
40 ticks / 2 seconds.
The most expensive visual reflection work remains client-side, but the motor itself still forms part of the shared server state.
Chunk Loading
For large venues, avoid keeping unnecessary production areas loaded if they are not being used.
Loaded chunks may contain:
- Fixtures
- Rack Nodes
- FollowMe targets
- RoboSpot systems
- Flight Cases
- Other modded blocks and entities
Separating several large venues across a server can work well, but server performance should be tested with the actual chunks and systems that will be active during the event.
Server RAM
Server RAM requirements depend heavily on the complete modpack and world.
TRP alone should not be used as the only factor when deciding memory allocation.
Consider:
- Minecraft version
- Forge
- Other mods
- Player count
- World size
- Loaded chunks
- TRP fixture count
- External network systems
Avoid allocating excessive RAM simply because the server runs TRP.
Enough memory to avoid pressure is useful, but excessively large Java heaps do not automatically improve server tick performance.
CPU
A modern CPU with strong single-core performance is recommended for demanding Minecraft servers.
Server-side TRP systems can add work through:
- Fixture updates
- Tracking
- Networking
- Registry management
- Multiplayer state
- External DMX routing
However, total server load also depends heavily on every other installed mod and Minecraft itself.
Network Connection
A wired network connection is strongly recommended for servers receiving:
- Art-Net
- sACN
This is especially important when the server is receiving multiple universes continuously.
Network problems can appear as:
- Rack Live / Stale transitions
- No Data
- Intermittent DMX
- Fixture control interruptions
The server’s physical network configuration is part of the lighting-control system.
Server Hosting Providers
Some hosted Minecraft environments may restrict:
- UDP traffic
- Broadcast traffic
- Additional network interfaces
- External ports
- Local-network discovery
These restrictions can prevent Art-Net or sACN from functioning correctly even when TRP itself is working.
For external DMX control, make sure the hosting environment allows the required network traffic.
Recommended Large-Server Practices
For production servers:
- Use a modern CPU.
- Use sufficient but reasonable RAM.
- Keep Forge and TRP versions consistent.
- Use clear Theatrical Networks.
- Keep Rack Node topology stable.
- Avoid unnecessary active FollowMe systems.
- Avoid excessive movable entities when they are not needed.
- Use wired Ethernet for external DMX.
- Monitor server tick health separately from client FPS.
- Back up the server before major changes.
Performance Testing
When preparing an event, test the server under realistic conditions.
Include:
- Expected player count
- All important chunks loaded
- Art-Net / sACN active
- Fixtures receiving live DMX
- FollowMe running if required
- RoboSpot stations active
- Other server mods running
Testing only an empty server with inactive fixtures will not represent actual event performance.
Important
TRP’s most visually expensive systems, such as volumetric beams and projections, are primarily a client rendering concern.
Server performance should instead be evaluated around:
- Shared state
- Multiplayer synchronisation
- Tracking
- Network routing
- Loaded systems
- Overall Minecraft tick health
Always diagnose client FPS and server TPS/MSPT as separate problems.