You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After removing some entites, when reloading previous state, the deserialize function seems to reuse cursors that might be already present in packet to load
That, I think, is giving this weird behavior when instead of loading 2 entries, it's loading the last of them with matching previously removed entities, and it allow "another load" of the same packet with dangling entities I guess (me lost a 🧠 )
// [...]it("should load 2 item after removing them",()=>{// givenconst{ assertItems, assertLength, more, less, save, load }=setup();// when// We add 2 itemsmore();more();assertItems([[1,100],[2,101]]);assertLength(2);// when// We save the stateconstpack=save();// when// We remove the 2 itemsless();less();// NOTE(douglasduteil): reseting the globals seems to hack the test// HACK(douglasduteil): use setDefaultSize to trigger a resetGlobalssetDefaultSize(1e5);// when// We load the last stateload(pack);// thenassertItems([[0,100],[1,101]]);assertLength(2);});// [...]
I'm not sure about the setDefaultSize above...
It make the test pass but smells pretty wrong, I don't know ... (404 on 🧠 again)
The serialiser doesn't capture a snapshot of the state at the time, but rather the diff between the current capture and the previous capture. This is useful for syncing state between a server and client without sending large packets containing the entire state.
Hi @NateTheGreatt
That bitECS of yours is 🚀 for me.
I'm not sure I'm using it the proper way...
Anyway, I found a freaky behavior in the deserialize process, confusing old and new entities.
I narrow the mismatch to
bitECS/src/Entity.js
Line 70 in 53458fc
After removing some entites, when reloading previous state, the deserialize function seems to reuse cursors that might be already present in packet to load
bitECS/src/Serialize.js
Line 343 in 53458fc
That, I think, is giving this weird behavior when instead of loading 2 entries, it's loading the last of them with matching previously removed entities, and it allow "another load" of the same packet with dangling entities I guess (me lost a 🧠 )
One word : WHY
I simplify the confusing demo above to an integration test to investigate :
I'm not sure about the
setDefaultSize
above...It make the test pass but smells pretty wrong, I don't know ... (404 on 🧠 again)
Here is a test case sandbox to illustrate the behavior.
https://codesandbox.io/s/bitecs-0-3-34-serialize-test-b7uxt?file=/Serialize.test.js
Might be related to #67
Thanks for the reading :)
Looking forward to new versions.
🧠 🛹
The text was updated successfully, but these errors were encountered: