PTR Changelog 2016-10-02
-
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?
-
@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.
-
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.
-
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.
