Scene Graph - spawned prefab at runtime crashes server on verse hot reload even after cleanup

[ArcaneStudio]

Summary

If you spawn a prefab in a simulation and clearing it with OnEndSimulation → RemoveFromParent + FortRoundManager.OnRoundEnd → RemoveFromParent, it will still crash the server

Please select what you are reporting on:

Verse

What Type of Bug are you experiencing?

Verse

Steps to Reproduce

1. Create a prefab. Add mesh_component, transform_component, keyframed component.
2. Spawn this prefab in runtime
3. Subscribe the class to clear RemoveFromParent with .fort_round_manager.SubscribeRoundEnded + OnEndSimulation.
4. Finish the round
5. Try running verse hot reload
6. Server crashed

• Crashes only with prefab.
• Normal entity{} does not crash the server
• Building the same entity through code, adding the same components, no server crash.

Expected Result

The server shouldn’t crash

Observed Result

Server crashes

Platform(s)

windows

[Jimbohalo10]

hi @ArcaneStudio
This is possibly a known error related to another bug report
Editable references in scene graph prefabs stay unique and are not being overridden in the main level - General / Issues and Bug Reporting - Epic Developer Community Forums

[ArcaneStudio]

Thanks. It’s a completely different bug.

[Jimbohalo10]

Hi @ArcaneStudio
Lets hope they find this by 35.00 this post is linked anyway

scene graph is experimental known issues

• Components are initialized much earlier than creative devices, which means that trying to fetch a creative device from component.OnBeginSimulation or component.OnSimulate will not work. To work around this you can loop and sleep until the components are found or can spawn your prefabs from a creative device’s OnBegin call.

Maybe the <transacts> <decides> which will trap Verse runtime errors could be used, as Scene Graph is experimental

[ArcaneStudio]

Thank you. It’s not an initialization problem, it’s a problem with the entity being spawn in the simulation, specifically a prefab problem.

[Jimbohalo10]

hi @ArcaneStudio ,
Yes, it does seem a problem at the remote server end.
The <transact> <decides> just traps the problem, by restoring from the error.
The <decides> records a wrong fail.

Let hope there is enough information for the engineers to fix it in 35.00, but we should remember this still experimental, so not a priority
Thanks