Setblock & Getblock issue
XeonG opened this issue · comments
So I have a small problem basically if I set bunch of solid blocks to be air, and then in the same update on another part of the code call getblock to see if certain positions are air or solidblock.. the getblock will return old information where it will still see those same blocks as solid instead of them being air, even though the sequence of events was setblock stuff first, and then later getblock.
...problem is even if i delay waiting another frame update or use a coroutine with yield return new WaitForSeconds(0.1f); before running the code that uses getblock.. it will still see old block information for a while...infact it still seems to see old information until setblock is triggered again, and then getblock will see the updated information on getblock for the previous setblock calls which for example could have happened like 500ms ago or even longer..
I'm not sure why this is going on, is there unity script execution order stuff I need to look into?
Set operations are queued and executed the next frame (if I remember correctly :) ).
yeh I see the stuff is queued and only processed in I guess the following update() i originally thought it was some sort timerdelay but that wasn't the case.
but still that is the weird thing.. even if I delay the function that calls getblock.. by a 0.2f or more.. its still not seeing the updated getblocks info ...until... say I place/remove another block again.. only after that update, is the previous update of block that were changed seen.. at least thats the way it appears, i dunno its very weird..
i've taken to just hooking into the setblock function and if the blocks that are set, are in the region of interest then I store those in another list, and then the function that needs to call getblock, I'll pass it this additional list, for it to go through that and overwrites whatever it picked up from getblock that was changed before in the list.. that way it has the latest changes that were made on that frame by setblock. Seems to work, but maybe a better way of doing this so setblock stuff is done before getblock and getblock will always retrieve what setblock stuff that changed on that same update?
if not whatever the workaround seems to be fine.. please add block materials :D
if not whatever the workaround seems to be fine.. please add block materials :D
You can already use them (and the game already does). Sort of. The world component accepts a list of materials. You only need to specify the name in your block's config (see configs to get the idea).
oh really.. maybe you could update the example scene sometime
It already uses 2 (colored world) or 3 materials (textured world). They're up to date.
You can now pass a callback to Modify methods. The callback is called once the operation finishes. No need for hacks.
Rev: 09871d3
Check VoxelmetricExample.cs to see how it works.
look interesting.. will check it out
if I have whole bunch of setblock operations in a loop that took place on one frame, and just have last setblock operation with an action to call... that would be fine?
If those operations happen within one chunk then yes, it will be fine. If it's set operations in multiple chunks it will not work because your chunk could be unloaded in the meantime.