3. PTR Changelog 2016-10-02

PTR Changelog 2016-10-02


  • @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.

  • Dev Team

    This 100 flag limit is kind of insane, in my opinion.

    This is the amount of flags needed to manually interact with someting, it will be their only purpose, since visual debugging and feedback will be possible through Room.visual. It won’t be supposed to use them all over the empire permanently. They are game objects that are free to create, like construction sites, so it shouldn’t be allowed to create a lot of them.

  • Culture

    So let me see if I got it-

    1. We'll still have the default Memory behavior.

    2. We'll have the option to pull in "memory segments", which are key/value sets of raw memory strings (which we can encode how we see fit).

    3. One of these keys will map to the original memory data (as a raw string).

    4. We will have more memory to work with.

    5. We will have a new visualize function that lets us place some sort of graphic on screen.

     

    Questions-

    1. Can we avoid having to deal with memory offsets and the stuf? The stuff dissi is posting  is scaring me.

    2. Will the json encoding work the same, or will it be a manual process that we deal with?

    3. Is there a coded limit to the number of segments, or will you just be paying attention to storage?

    4. Will the visualizations persist indefinitely, or will they have to be renewed?

    5. The landmark idea seems to have evolved- can you elaborate on your ideas for what that would look like?

    6. Can you confirm there will be no more reductions in flag limits until after memory segments have been out for long enough for us to have come up with a flag replacement?

  • Dev Team

    So let me see if I got it-

    That’s all correct.

    1 . Can we avoid having to deal with memory offsets and the stuf? The stuff dissi is posting is scaring me.

    There will be no offsets at all, you just get different strings from different named memory segments. RawMemory works like a hash map of strings.

    2 . Will the json encoding work the same, or will it be a manual process that we deal with?

    For default Memory it is the same, other segments are up to you.

    3 . Is there a coded limit to the number of segments, or will you just be paying attention to storage?

    Not ready to answer yet. Hopefully, unlimited number with an overall length limit.

    4 . Will the visualizations persist indefinitely, or will they have to be renewed?

    They need to be renewed every tick, but these operations will be with no CPU cost, like console.log or Creep.say.

    5 . The landmark idea seems to have evolved- can you elaborate on your ideas for what that would look like?

    We haven’t put a lot of thought into it yet, too soon to say something concrete.

    6 . Can you confirm there will be no more reductions in flag limits until after memory segments have been out for long enough for us to have come up with a flag replacement?

    Yes, 10,000 limit will be in place for several months after the memory segments are released. By the way, you can come up with your own interface very close to the current Game.flags object, so that this transition should not be a very complicated task.


  •  

     > They need to be renewed every tick, but these operations will be with no CPU cost, like console.log or Creep.say.

    So if I upload code and it breaks, all my visualizations are gone because my code that maintains them didn't run?


  • @Ccomp5950 a lesson to be learned early in screeps development... wrap every separate functional piece of your code in a try/catch block, so that one part breaking won't affect other parts.

  • Culture

    Quick question about the planned RawMemory segments.

    • How many of these segments will we be able to create? ( I can see abuse happening here if you can freely create a shitton of segments, same as with flags )
    • Will the names iterable? ( If yes, see above for concerns )

     


  • So, here's something to consider.

    I use flags to configure things in my code so I don't have to hard code it or manually write stuff in memory. Examples:

    1. Flags to say "don't move into this room"

    2. Flags to say "build N creeps of type M instead of the calculated default"

    3. Flags to say "remote harvest/reserve/repair/build in this room"

    4. Flags to say "improve my walls/harvesters to N in this room"

    And a large variety of other configuration things.

    I don't think I've had more than five flags in a room, but I can see that 100 flags will not be sufficient. We'll need a good UI mechanism to configure the code systems without having to have a huge amount of non-GUI configuration.

  • Dev Team

    Detect a newly placed flag, save its position into memory, create a visual point at this position (optionally), delete the flag. You don't need even 10 flags if you only use them to point to something via GUI.