PTR Changelog 2017-02-17
-
The problem arises when you got more than 1MB of runtime data to load after a global reset.
Loading more than 1 MB of segments data is possible only during multiple ticks. This is a design decision, in order not to saturate server internal network.
-
Fair enough!
-
Can we get a fresh copy of prod on PTR?
-
Can we get a fresh copy of prod on PTR?
Done!
-
Seems like the Game.time was offset, I think my code can recover from the current state the rooms are in though.
-
Can we make it so
RawMemory.requestSegments([0,5]);is remembered between ticks? This way we won’t have to re-request memory segments every time. This helps when you get timed-out or when a tick errors out (CPU limit reached).You could effectively “swap” databanks by calling
RawMemory.requestSegments([1,6]);
-
Maybe to alleviate network I/O you'd have to explicitly mark a memory segment as dirty before it's saved to the database.
-
Can we make it so RawMemory.requestSegments([0,5]); is remembered between ticks? This way we won’t have to re-request memory segments every time. This helps when you get timed-out or when a tick errors out (CPU limit reached).
Good point. It should persist between ticks now.
-
Thanks! Amazing change!
-
It would be amazing if we could put data into segments that aren't "active" yet.
I also want to say that making segments available via HTTP would really help with the various stat collection programs.
-
Also for backups/testing! I like to periodically grab a snapshot of my memory & room objects for porting over to a private test server.
-
Thank you for adding this!
This seems like an incredibly useful feature, and one thing would make it even more useful: the ability to save segments that aren't loaded during the tick. Even if it was limited to 10 total segments saved during the tick, this would allow for an expensive calculation that should be merged into one of the "main" segments being saved in an "extra" segment reserved for that specific purpose.
Of course, this could be worked around using values in Memory, but if that can be avoided, that would be ideal for me. Say I'm storing a list of paths that my script should remember & request in segment 2, and on one tick I need to path urgently, when I hadn't expected it (perhaps an invader showed up, and waiting a tick would not be acceptable). The code could create and save the path (and some metadata) to segment 82 (not previously requested), and then request it for the next tick. The next tick, the code now seeing that it has segment 82 and segment 2 loaded, would merge the data from 82 into 2.
That would be just one usage of this feature (the ability to save non-loaded segments), but I could imagine it would be very useful in other cases as well, and would alleviate some of the possibly expensive calculations needed to predict which segments data will need to be stored into!
-
Would it be possible to add an "isSet" style function to see if a segment is in use (even if it's not "active")?
-
What happens if we attempt to store data in a segment that isn't available? Will it throw an error?
How will we know which segments are available? `Object.keys(RawMemory.segments)` ?
-
To answer my own questions-
* All segments are set as empty strings, so there probably isn't a real way to get a list of segments with length greater than one other than manually checking.
* Unavailable segments just return "undefined"
* `Object.keys(RawMemory.segments)` sort of works but not really. It returns the values as strings, but an actual int is required in lots of places. There's also a weird "null" value that is returned by Object.keys that needs to be filtered out. To get the real set of available segments-
var availableSegments = _.filter(Object.keys(RawMemory.segments).map(Number), function(a){return Number.isInteger(a)})
