We need some way to control prop replication base building games are hitting a wall

General Issues and Bug Reporting
, , ,
1

Summary

Im making a 4 player base building island where everyone builds on their own plot. Props are spawned at runtime and movable, a maxed base is ~150 props so a full lobby is 600+ replicated actors.

Performance tanks as bases grow, we tested it, empty plots run fine and missed frames climb the more players build. Switch and mobile get hit hardest (10-40% missed frames vs 0.5% on next gen). We already converted everything static, removed idle vfx and added culling, didnt help because its a replication flood not rendering.

Problem is theres literally nothing to adjust in uefn. No relevancy distance, no update rate, no dormancy, and the limits arent documented anywhere.

Even something simple would fix it, other players bases are basically scenery so a dormancy option or per prop replication distance would solve this whole genre. Right now the only options are capping builds or spreading plots super far apart.

Happy to share the project or test data if anyone from epic wants to look.

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Stability

Steps to Reproduce

1.	Create an island with 4 player plots placed within replication range of each other (under ~100m apart)
2.	Using scene graph, allow each player to spawn movable props at runtime on their plot (grid based building, ~150 props per plot when fully built)
3.	Start a session with 4 players on low end hardware (Switch or mobile shows it clearest)
4.	With empty plots, note performance is normal
5.	Have all 4 players build out their plots and observe missed frames climbing as total placed prop count increases
6.	Fully built (600+ replicated actors total) the session shows severe missed frames on Switch/mobile (10-40% in our creator portal analytics) while next gen hardware stays around 0.5%

Expected Result

creators have some way to manage replication load from runtime spawned props (relevancy distance, update rate or dormancy), or documented limits to design within

Observed Result

no creator facing settings exist for replication, performance degrades with no way to address it beyond removing gameplay content or spreading plots beyond an undocumented distance

Platform(s)

All platforms, most severe on: Nintendo Switch, Mobile (iOS/Android)
Also affected: PC, PS4/Xbox One (last-gen)
Least affected: PS5/Xbox Series X|S

Island Code

3417-3153-6183

6

Hey @finnppp. Does the island code attached have cheats that will allow our testers to quickly spawn full bases?

7

Hey @Dallan-MT , You could start up a private version and purchase a few cash packs that way you can spawn a big base quick. Not sure if you can see my private codes or I have to share one (Any of the latest ones work)?

8

I had something with sg entities too it caused major hitching/fps drops until i spaced them about more ill find bug report might be related.

Wasn’t much of a report didn’t even get acknowledged(This was my first project i noticed the issue.

2nd Project

What i found tho is with sg entities the more you had in a small area it lags this i believe is around 1k iirc. I was testing a game with just a prefab with circle mesh_comp and it lags like crazy fps drops to 20 and it works on the world stream grid even if you have that disabled. I believe i can repro this every time (Just change the verse value for spawn amount) if you need any info as i still have the project

1 Like
9

Interesting, could honestly be both issues stacking. We spawn everything through scene graph entities at runtime too, so we’d be hitting the SG entity overhead you’re describing on top of the replication load.
Our numbers do point at replication as well though, missed frames scale with total placed props across all plots and clients get hit way harder than the server (10-40% on Switch/mobile vs 0.5% next gen). So my guess is SG entity overhead per client plus a replication flood on top with no way to control either.

10

If you have a private code that can let us test fully bases ASAP, that’d be best. Being able to reproduce your issue as quickly as possible makes it faster to test improvements, iterate on fixes, etc.

Because this report is quite generic you’ll see the attached Bug close as “Won’t Do”. Please understand that we’re focusing really hard on making performance better for you all - we have specific tasks we’re doing that replace this general request.

11

(post deleted by author)

12

FORT-1126411 has been ‘Closed’. The issue reported is not caused by a bug in the tool.