Memory inconsistencies

[ktodyruik]

Hi,

Has anyone run into inconsistencies when accessing / modifying creeps memory?

I started noticing that the cleanup script in screeps-starter-rust wasn't picking up all the creeps entries in memory (on the screen). Or it did delete an entry and that deletion didn't seem to be removed from the client memory tab on refresh. So, cleanup didn't seem to be working as expected, cleaning up deceased creeps.

 if let Ok(memory_creeps) = Reflect::get(&screeps::memory::ROOT, &JsString::from("creeps")) {
            // convert from JsValue to Object
            let memory_creeps: Object = memory_creeps.unchecked_into();

When I compare memory_creeps in the cleanup with raw memory, they aren't the same. Raw memory has more entries.

I read this section in the api docs mentioning that memory access can be tricky: https://docs.rs/screeps-game-api/latest/screeps/index.html#data-persistence It feels like this copy isn't staying in sync with the server memory. Is this possible? Should I be using raw memory and write my own serialization/deserialization instead, as is mentioned in these docs?

I'm running the Steam client/server version of Screeps, running and developing against the private server.

I'm quite puzzled over this. Any suggestions would be appreciated. Am I missing something?

Thanks, Kerry

[ktodyruik]

Update...

I did more testing around this. The raw memory and the client memory tab on the screen are consistently the same.

The memory::ROOT entry seems to get out of sync with the raw memory. The memory::ROOT entry also works consistently in my process until I restart the server. Setting creeps entries through the memory:ROOT and cleanup all work fine until I turn off and start up the server. Then I lose my updates.

[shanemadden]

I read through this several times, days apart, before I came up with an idea of what it might be -- are you by chance hanging on to a reference to memory::ROOT between ticks?

The game driver swaps the underlying javascript Memory object before each tick with a fresh one, so if you're writing to an old tick's version of the object, you'd get the behavior you're describing (at least, without adding any tweaks to compensate for doing so -- a common trick referred to as "memhack" in the screeps community would retain the same Memory objects across ticks and fix your issue, if my guess about the cause is correct).