PTR Changelog 2016-10-02
-
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.
-
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.
-
> 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.
-
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.
-
> 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.
-
What do you have in mind? Could you show some code example of how you'd use such API?
-
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]);
}
}
-
Something like this could be done.
-
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?
-
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/setwill work with different raw strings specified by an argument, one of them will be your defaultMemory, 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?
-
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.
-
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?
-
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.
-
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.
-
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?
-
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.
RawMemoryworks 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.logorCreep.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.flagsobject, 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.logorCreep.say.
So if I upload code and it breaks, all my visualizations are gone because my code that maintains them didn't run?
