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

General Issues and Bug Reporting
, ,
1

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

2

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

3

Thanks. It’s a completely different bug.

4

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

5

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

6

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