4. How to store live object

How to store live object


  • Hey guys, I'm new to screeps.

    Recently, I was trying to define a class and create an instance of it to make my code more flexible. But I was stuck in the problem of "not able to store a live object in Memory" as screeps document mentioned.

    I tried to store object into an array or gobal object outside of function loop, but only found out that screeps will clear everything out every certain amount of ticks. Any ideas of how to keep a live object?

    I would be much convenient if Memory can store an object. 😕


  • You should store the identifiers in memory and then use Game.getObjectById() to retrieve the live object.


  • Another way to view the API is there are no live game objects, only a snapshot of what internal game object looked like at the start of the tick.
    This means using a stale object is totally a thing. A stale StructureController is nearly identical, a stale Creep however is much less forgiving.

    The good news is Game.getObjectById is really really fast. So just store game ids and create an object for them when needed.


  • What deft said.

    I would also point out that you don't directly change the objects you reference with Game.getObjectById() anyway... you REGISTER AN INTENT that the system then uses to change the object AFTER your code runs. So at the end of every tick... any object you have stored is going to be stale.

    You can't have direct control over these objects... if you DID, you could just do stuff like change their hit points on the fly. Your script is like a proxy, once a tick, it runs. It has a shapshot of the current state of the objects, then it orders changes to those objects by issuing intents (Through the API calls.) at the next tick, it gets a snapshot of the updated objects.


  • Thanks for responding my question.

    Its good to know that I can only store object id to Memory, but what if I want to store the object (lets say an instance of a custom class) other than game object into memory?

    1 Reply

  • @fantasticmark Then you store the object's data in the Memory object. The heap can go away at any time, you have no "hard drive", and you have no persistent "data base" outside of the Memory object, which is reconstructed every tick.

    An example: the RoomPosition object. You can create new RoomPosition objects all day with the constructor, and it saves the data on the heap for use during that tick. If you save the object onto the Memory object, only the data is saved, the Memory object won't carry the actual object to the next tick, only the data. You would have to reconstruct the RoomPosition object with the constructor every time you want to use it.

    Now, there are types of data that you CAN safely store on the heap, and that's data that's derived from other data as a convenient cache... you can store THAT on the heap, and not take any cost of serialization every tick, but you have to be ready to recreate the data if a tick starts and it's gone.

    As another example, I have data stored about the colony. It's data that can't be reconstructed if lost, so I store it in the Memory object in an object called "Memory.colony." Any data I need for the colony is stored there as properties. If I stored it on the heap, it would be wiped every time the heap is deleted... which would be bad. So It's in the Memory object where it's rebuilt every tick and available.

    1 Reply

  • @smokeman Thanks Smokeman! That helps a lot!