I’m trying to understand the concept of class and I think I’ve arrived there and I’m also trying to separate my code into several files for greater readability. However, I now have a problem that seems simple to solve but which I don’t understand. So I’m asking the question here to find out if it’s a bug or not.
I have a game_manager.verse file in which there is only an OnBegin, and another file.verse in which there are functions.
Here are my two ultra-simplified files to make it go faster:
The file.verse:
using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
my_device := class(creative_device):
@editable
Numbers : []int = array{}
PrintNumbers():void=
for:
Number : Numbers
do:
Print("{Number}")
The game_manager.verse:
using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
game_ganager := class(creative_device):
MD := my_device = my_device{}
OnBegin<override>()<suspends>:void=
MD.PrintNumbers()
The problem being that when I use an @editable variable it doesn’t display anything and it doesn’t fit into the for loop, as if Numbers array was empty even though the device is correctly configured in UEFN
I believe the reason for this behaviour is related to the sequence in which the devices are initialized. The OnBegin function of the game_manager is executed before my_device has completed its initialization, causing it to still have the default array value set in its property at that point.
I’m not sure the way this works currently is always the way it will be, but there are two possible workarounds to address this issue that I can suggest:
Introduce a Sleep(0.0) delay within the OnBegin function of the game_manager. This delay will defer the execution of the remaining code in the function until the next Verse simulation update. During this update, all devices should have had the opportunity to initialize properly (unless they themselves do asynchronous things in their OnBegin). While this approach can work in many cases, it may become unwieldy and challenging to manage execution order, especially in more complex projects with devices that have interdependent initialization code.
Alternatively, you can create a dedicated device responsible for managing the initialization of all your devices. This device would coordinate the initialization process and trigger a single centralized “ready” event when everything is prepared and initialized. While this approach requires more effort to set up, it can provide a more robust solution, especially when dealing with multiple devices that rely on one another during initialization or have asynchronous wait time during initialization.
Edit: It seems it was just missing the @editable attribute… but you might find yourself with init execution order issues at some point, and when that happens you can cast your mind back to this faithful day.