3. PTR Changelog 2016-10-02

PTR Changelog 2016-10-02

  • Dev Team

    This post describes changes on the Public Test Realm. The estimated launch date is October 13.

    • Flags count is now limited to 10,000 per player. Their parsing will not incur any CPU costs, the proposed change from the previous PTR changelog is cancelled.

    Future plans

    We’ll be slowly moving towards the system where you can develop and control all mechanics on your side. There will be a separate visual system (Room.visual) and a separate storage system of your choice based on your Memory, which you can tie together to develop your own replacement for Flags. Once theRoom.visual feature is deployed, we will be gradually reducing the flags limit to some lower level (like 100 flags per player) eventually, over several months, in order to give you time to switch to your own implementation.

    In order to make Memory usage more fine-grained, we’ll introduce the “memory segments” feature, where you can use RawMemory to get/set different chunks of your raw memory data, so that the entire Memory is not required to be parsed/stringified every tick.

    We believe it will both give you more control and features, and at the same time will establish fairer rules of how much cost should by applied on your code, since Room.visual mechanics should be pretty cheap, and storage mechanics are already based on your existing Memory costs.

    Decayable Landmarks from the previous discussion is pretty interesting idea also, and we will think how it can be integrated here, but it’s a whole other take on this subject.

    Thank you for all the feedback, and please keep in mind that this PTR forum is where things are proposed, rather than stated vehemently. It is our intention to discuss upcoming features with you here, and we’re glad that we see some interesting discussions at last.

  • Culture

    Is it an idea to have a maximum amount of flags based of a GCL level? This way you don't have to completely rewrite your code if "suddenly" find out that you have 100 flags.

  • Dev Team

    No, this is the same kind of global limit as memory size limit, code length limit, construction sites limit, etc.

  • Culture

    Ok cool, 100 flags seems kinda limited for larger players which mark their minable sources with flags ( like me ), but the segments can offer a solution to this issue.

    Are there any details yet about the new Memory segment strategy? Will we be able to divide it using really small sections?

    RawMemory.get("sectionName")

    To create segments:

    Memory.createSegment("segmentName", 1024, 1024) // Create segment from byte 1024 with length 1024

    With Memory segments we can use more advanced techniques of storing data in memory (linked lists, hash trees, matrixes, etc) which are currently not viable to store in memory due to Memory serialization costs.

    I'd be cool to have such a feature, but the difficult thing might be dealing with when to save changes. Currently saves are done at every end of each tick, it currently doesn't cost us CPU to change memory, with this change it will.

    If we get control of what and when we are saving, could we also tap into register callbacks before our global scope gets destroyed? Obviously this has some issues:

    • what if an VM error happens, do you call the callback or just reset globals (system failure, fun challenges!)
    • what if someone on the same node forces scopes to be killed off due to an infinite loop
    • out of bucket/CPU

    The player, when using segments, should handle these things gracefully, maybe saving memory every X ticks just to be sure. I just want to make sure we get some heads up before globals get reset.

     

  • Culture

    I'm really disappointed that you're introducing this limit without having the replacement already setup for it. I think you should put the cap at 15k flags until you've provided the segment or landmark feature.

    I"m also not sure why you keep calling them decayable landmarks- i wasn't thinking they'd decay, just that they would be a structure different than flags so you could charge us for the parsing and we could still have unlimited "flags" as long as we were willing to pay the CPU cost. I can see how we can emulate this with the new member stuff you're talking about, but it seems like you're taking a feature away from us now to replace it with another feature in the future (and we already know your roadmap is pretty full).


  • I like everything mentioned here.

    When I started playing, I thought flags were for short term direct player intervention in creep behavior. Then I learned that many players store more permanent information in flags than I store in all of my Memory and I had to rethink that.

  • Dev Team

    Are there any details yet about the new Memory segment strategy? Will we be able to divide it using really small sections?

    Yes, something like that.

    If we get control of what and when we are saving, could we also tap into register callbacks before our global scope gets destroyed?

    The server doesn’t always cause these resets intentionally, sometimes they just happen suddenly, so it cannot handle them in a graceful manner and notify player scripts.

    I’m really disappointed that you’re introducing this limit without having the replacement already setup for it.

    When do you personally expect to overgrow the 10k limit?

    I think you should put the cap at 15k flags until you’ve provided the segment or landmark feature.

    Flags will be replaced by Room.visual + memory segments, not by landmarks. The landmarks concept is still under consideration.

    I”m also not sure why you keep calling them decayable landmarks

    Decaying is a mechanic to justify their CPU cost. You will need to pay CPU to renew their time to live, otherwise they disappear.

    I can see how we can emulate this with the new member stuff you’re talking about, but it seems like you’re taking a feature away from us now to replace it with another feature in the future (and we already know your roadmap is pretty full).

    Considering the fact that there is an immediate need in implementing flags replacement, I think we’ll prioritize it right after the open source server on the roadmap, i.e. in the next 2-3 months.

  • Culture

    > The server doesn’t always cause these resets intentionally, sometimes they just happen suddenly, so it cannot handle them in a graceful manner and notify player scripts.

     

    Could you can make it callback before resetting gracefully? You can add a big fat banner saying "You might not always get notified!". This helps a lot for memory segments which gets loaded/unloaded on demand.

  • Dev Team

    When I started playing, I thought flags were for short term direct player intervention in creep behavior.

    Right, it is what we had in mind from the start - a tool for visual operations and debugging which is not used permanently (since you don’t debug all the time). It was supposed to use Memory for permanent positions storage, but I admit that we weren’t clear enough with explaining that in these mechanics, so it’s completely understandable why some players started to use them for permanent markup. Memory costs CPU, but flags are free. Not quite fair design, but we have what we have.

    After all though, I think the Room.visual + Memory alternative will work even better. You’ll be able to not only mark positions, but also animate them between ticks, draw lines and shapes, use your own icons, etc. And it will be up to your optimizations skills, how do you manage to implement your positions storage, it’ll be a real competitive advantage over other players. It’s what Screeps is all about.

    Could you can make it callback before resetting gracefully?

    I’m not really sure what do you mean. You can trace it in your scripts on your own using some variable stored in global. And if you mean an asynchronous callback, it cannot be implemented within Screeps architecture, your script is executed synchronously.

  • Culture

    > I’m not really sure what do you mean. You can trace it in your scripts on your own using some variable stored in global. And if you mean an asynchronous callback, it cannot be implemented within Screeps architecture, your script is executed synchronously.

     

    I know I can trace it. The problem is I'd like to save things to memory before global is reset. You could save every X ticks as well, but saving only when needed would be preferable.

  • Dev Team

    What do you have in mind? Could you show some code example of how you'd use such API?

  • Culture 

    module.exports.loop = function() {
     if(doStuff()) {
     markDirty("memorySegment");
     }
     if(Game.time % 5) // Save every 5 ticks
     {
     handleDirtyMemory(); 
     }
    }

    module.exports.beforeGlobalReset = function() { // New method before global resets
     handleDirtyMemory();
    }

    function handleDirtyMemory() {
     var dirtySegments= getDirtyMemoryList();
     for(var i = 0; i < dirtySegments; i++) {
     saveSegment(dirtySegments[i]);
     }
    }
  • Culture

    Something like this could be done.

  • Culture

    I'm still really confused as to how this RawMemory thing is going to work. Are we going to have to manage strings and offsets and stuff, or will that be handled for us?

  • Dev Team

    Something like this could be done.

    It looks like asynchronous callbacks. They are not possible in Screeps architecture. Your script cannot be called at a random point of execution, since it would compromise the entire point of measuring time when the user has control. But a reset is always an asynchronous event.

    I’m still really confused as to how this RawMemory thing is going to work. Are we going to have to manage strings and offsets and stuff, or will that be handled for us?

    Most likely, RawMemory.get/set will work with different raw strings specified by an argument, one of them will be your default Memory, and others can be allocated arbitrarily.


  • Flags currently are about the only means of directly interacting with the screeps in-game, aside from accessing, changing and committing code.
    Maybe we could have some sort of buildings that resemble configurable switches?! That would add some more value of defending/attacking a certain room and could enable us to interact with them screeps more directly. Just true/false like a checkBox or a radioButton. Maybe something more sophisticated later on the RCL path?

    I would love to make 'em do something by a flick of a switch, instead of changing code or "abusing" flags as triggers...
    What do you think?

  • Culture

    Personally I think this game should try to minimize direct human interaction, not provide more ways to do it.


  • @Artem if it helps to think of it this way, a simpler system would be to just set a variable. Game.going_to_reset_after_this_tick could be checked by the player, and if it's true then do whatever needs doing. Then, when you know a reset is coming, you could set that for everyone. Unplanned resets could still happen, but at least *some* resets could be handled gracefully.

  • Culture

    This 100 flag limit is kind of insane, in my opinion. This "room visual" thing doesn't replace what flags were.

    When you introduce this new RawMemory and remove all of the flags will you be increasing the overall amount of memory we get to make up for the change?

  • Dev Team

    This “room visual” thing doesn’t replace what flags were.

    Why?

    When you introduce this new RawMemory and remove all of the flags will you be increasing the overall amount of memory we get to make up for the change?

    Yes, probably.