Hello,

First, I must admit I have not preordered and so I do not have code access (money is a bit tight right now). Otherwise I would test this myself. I was wondering how the ability to hot reload the game DLL interacts with the current background task multithreading. Since the game does not block on tile generation or asset reloading, these operations can span multiple frames and you can hot reload code in the middle. Does this cause a crash or does the thread keep running code from the old DLL?

If it crashes, would making background tasks run in fibres/coroutines help so that we could yield long running tasks between frames and then restore the context after?

Thanks to anyone who can shed some light on this.

P.S. I believe there is a bug in the latest episode where if an asset takes more than one frame to load and there are no other tasks running, two tasks to load the same asset could be created.

P.P.S. I would ask this question after the stream, but I don't get home until about 6:30 Pacific at the earliest so there's really no way for me to make it on time :(

filkry
I was wondering how the ability to hot reload the game DLL interacts with the current background task multithreading. Since the game does not block on tile generation or asset reloading, these operations can span multiple frames and you can hot reload code in the middle. Does this cause a crash or does the thread keep running code from the old DLL?

This is an excellent question, and honestly I have no idea. We should probably go ahead and make hot-reloading force a flush of all tasks first, just to make sure it will always work on any platform no matter what the rules are.

P.S. I believe there is a bug in the latest episode where if an asset takes more than one frame to load and there are no other tasks running, two tasks to load the same asset could be created.

This is specifically discussed in the Q&A.

- Casey

Thank you.