PTR Changelog 2016-09-29
-
Artem, this type of game attracts the creative minds. You impose limits, we merely see obstacles. If you kick people back down every time they come up with creative solutions for a problem, then it's going to alienate those players that are actually passionate about the game. One would think that's the sort of player you want to actually keep around.
I'm only here for 2 weeks but in that time I've seen a lot of goalposts being moved already. Some for the better, some questionable.
For example, being a new player, I now feel quite disadvantaged by the recent changes to resource harvesting, and the pending powercreep requirement for remote mining, when the veteran players are entrenched due to their existing wealth of resources and power.
This flag issue doesn't seem to be handled too well either.
Perhaps instead of heavyhanded nerfing and kneejerk reactions to people using the toys in your sandbox for something you didn't expect them to (something you should expect given the nature of the game), work with the community to address problems in a way that doesn't repeatedly invalidate the work of those that spend countless hours and their money on your game.
-
For the record, i have about 7000 flags. I use them primarily to mark locations of buildings, with a focus on planning and enforcement of buildings. What that means to me is that a certain flag marks a location where a structure should exist, pending a RCL precondition, and then should permanently exist thereafter. This allows me to place structures "in advance" and then build or rebuild them later by marking the location and using the color code of the flag as information for my management. I also use flags as spawning demand "tickets", where a flag is used to request a creep to come "do something" at a location.
The flags documentation states
Flags can be used to mark particular spots in a room.
Having thought this over more, I'm not sure what it is I am doing wrong with flags that I would need to incur a 30++ cpu penalty in the next two weeks. I am marking locations in my empire for things to be built, locations of interest that allow me to navigate between rooms, and I am marking locations for creeps to go do work. If the Flag object is too expensive on the server, provide me with a drop-in alternative, or allow me to build the flag objects myself. I'll implement the cache I suggested for myself, if you let me. That will both reduce load on the server, and I can keep my flags. You've had multiple suggestions from a few people, including myself, on how to reduce server. Can you please address those suggestions even as stop-gap solutions until there are alternative or better options in place?
-
Since this is separate from Memory, would it be possible to write the server end to use a more efficient method for storing flags?
I can't exactly profile the current JSON-serialization for the flags since it's PTR, but if, say, Protocol Buffers were used instead of the custom string serialization for storing flags, I'm pretty sure it'd take both less CPU and less memory to process them. In the past when I've worked with data sets with very defined formats (like name,x,y,roomName as opposed to the open-ended Memory), Protocol Buffers has greatly sped up serializing and deserializing, as well as disk usage by data sets because of the structure of the data format. Using this, or another bit-crunching serialization method would certainly still give the CPU benefit of using flags over memory that there has been in the past, and wouldn't tax the servers as much with memory or CPU either.
Since flags are such a nice way to store script information in a directly-editable way, having them as viable as possible to use would be nice, for both the Screeps team, and screeps users.
In protobuf, something as simple as this could be used for storing flags - in a way fast to access, and deserializable by both the server and the user interface:
syntax = "proto2";
enum Color {
RED = 1;
PURPLE = 2;
BLUE = 3;
CYAN = 4;
GREEN = 5;
YELLOW = 6;
ORANGE = 7;
BROWN = 8;
GREY = 9;
WHITE = 10;
}
message Flag {
required string name = 1;
required Color color = 2;
required uint32 x = 3;
required unit32 y = 4;
required uint32 room_x = 5;
required uint32 room_y = 6;
}
message UserFlags {
repeated Flag flags = 1;
}The binary representation would be much more compressed, and in Protocol Buffers the deserialization code (pre-compiled using protoc for each message) knows exactly when each field starts/stops, and can just read the message directly without needing to separate a string in any place, or allocate anything but the final result in the middle of parsing. Something like the following could be used to parse it. I'll try and do profiling on this along with the code you posted, because I feel that something like this could really benefit the server.
let flags = require('proto_flags');
function serializeFlags(flagsObject) {
let flags = _.values(flagsObject);
let outputMessage = new flags.UserFlags();
for (let i = 0; i < flags.length; i++) {
let inputFlag = flags[i];
let outputFlag = outputMessage.addFlag();
outputFlag.setName(inputFlag.name);
outputFlag.setColor(inputFlag.color);
outputFlag.setSecondarycolor(inputFlag.secondaryColor);
outputFlag.setRoom(inputFlag.pos.roomName);
outputFlag.setX(inputFlag.pos.x);
outputFlag.setY(inputFlag.pos.y);
}
return outputMessage.serializeBinary()
}
function deserializeFlags(inputBinary) {
let flags = {};
let roomFlags = {};
let input = flags.UserFlags.deserializeBinary(inputBinary).getFlagList();
for (let i = 0; i < input.length; i++) {
let inputFlag = input[i];
let flag = new Flag(
inputFlag.getName(),
inputFlag.getColor(),
inputFlag.getSecondarycolor(),
new RoomPosition(inputFlag.getX(), inputFlag.getY(), inputFlag.getRoom()),
);
let room = inputFlag.getRoom();
if (room in roomFlags) {
roomFlags[room].push(flag);
} else {
roomFlags[room] = [flag];
}
flags[inputFlag.getName()] = flag;
}
}
-
Wall of text incoming.
As I previously stated I consider flags(as it is now) to be a mechanism that can be abused at the expense of the whole community.
So it MUST be nerfed one way or another. E.G. my previous example, a 'free' 10 cpu user could fuck the tick time for everyone by covering ALL the rooms in the world with flags.This being said, here is a couple of suggestions:
* About PTR: It should be possible for anybody to test code in PTR.
Proposal: Anybody should be able to register for a session of 12 hours on ptr every 48 hours. (Reduce that time if you fear overcrowding)
On activation the state of all the game objects of the player should be copied on ptr.
(structures, creeps, flags, memory)
Two players could then also test combat strategy there, but with a slower pace.* About flags:
a) Make it part of the Memory with a default implementation that we can surcharge so we benefits from our own optimization.
And make the memory scale with GCL with an higher limit.
something like 500k + 100k per GCL.b) Alternatively, keep it free but make the amount of flags scale per GCL.
E.G. 100 or 200 per GCL.c) Even better replace that with an api for graphical hint with a default implementation that we can surcharge
but then make the memory scaling proposed in a)
(as proposed by Dissi)* Optimize your engine.
This may look pedantic, but if your engine is written mostly in js and with a programming scheme similar to what we can see by looking at prototypes in the console there are a LOT of potential for optimization.
I would be in favor of replacing big parts of the server side logic by native code, but hell, even in js, there a lot of hanging fruits.
Don't get me wrong, I don't intend to criticize nor underestimate your coding capabilities.
I feel like you are hitting some scaling wall and just didn't have time to do this.
And my theory is that some of the current rebalance are also CPU sink of some sort in order to help with that.
Hopefully the OSS will allow us to help you with that. Assuming you'll reintegrate PR in the main code
@tedivm
Please cool down a bit, you are an important part of the community, and your opinion matter a lot to us. (at least to me)
It doesn't help to go all UPPERCASE on the devs, I completely understand that in your particular position (and N00bish and Anisoptera) this is a VERY hard pill to swallow, but consider that as the devs already proved, the proposal on PTR is usually not definitive.
So stay constructive, we will find a way
(PS: If you leave, can I use your avatar ?)
-
I just want to ask all of you to offer some alternative solution when you criticize what we offer.
The current situation with flags is very dangerous because of the reasons which not only we can foresee, here are some players telling the same in this thread. Free-to-use flags are ruining the spirit of this game, where you are supposed to optimize. And this is very abusable, you can actually break the game completely if you wish by generating dozens of thousands of flags. The current game engine will not be able to parse them witin 3 seconds tick. Offer the alternative how to solve this issue, we're open to listen, really.
As to "nobody uses flags as memory" - if it was like that, we were not doing this change. Currently there are flags with names kilobytes in length.
Can’t we get any buffs in CPU or anything? We’re just expected to “deal with this increase in cpu, you got 2 weeks”. It took about 4 weeks to reduce my CPU by 20. Now 50% of that goes back to flags, I’d like to influence how they’re made.
This game has more breaking changes pushed per month than my actual job that I get paid for, and I get more notice of those changes and more opportunity to fix my code to comply with the changes. Two weeks? Are you serious?
We can extend this period if needed, it’s not a problem.
Not only that, but they’re refusing to give us a proper platform to test these changes, forcing us to do so in production.
You can use PTR to measure your flags usage, it seems to be enough here. Anyway, we can try to copy the world again, but ticks will be more like 2-3 minutes instead of 10 seconds.
-
Voronoi-
Honestly, I may have just hit a breaking point with the amount of crap that's been shovelled on us lately. It really hurt that they broke my code for hours because of a bug fix they didn't test, and that they had no real solution to making sure that didn't happen in the future. It upped the stress level of this game significantly knowing that at any point my code can break and there is nothing I can do to prevent this. The game is now a 24/7 on call game which is not what it was supposed to be.
Then on top of that they keep making decisions that basically screw people who have been playing for awhile. Their documentation says that flags can be used in this way, and they know that people have. So they break PTR and then announce changes that are going to destroy the work that people have been putting, in at least my case, over a year of work on. Oh, and we have two weeks to deal with that.
They are failing at working with the community. They keep announcing what appears to be knee jerk reactionary changes, they refuse to share data about why they're making those changes (because sharing that data would take time), they're delaying things like the open source server (which would actually help them, in the sense that others would be able to help work on the game with them)- but more importantly *they keep breaking the game*.
For context, which I think a lot of people are missing, a lot of people who play this game want to play an automated game. We enjoy the challenge of things like automated building placement, and in general want to automate everything we can. Flags are an amazing tool for this- not just because we're trying to offset memory usage, but because they were literally designed to let us tie information and location together. Further, the devs seemed to encourage this- I've posted pictures of my automated flag programs before, and the devs seemed to notice people were using them this way and added the ability to choose multiple colors with flags (allowing subcategorization).
So they're literally destroying an entire way of playing this game that many people have gathered around. They're doing it with two weeks notice. They're doing it even though their documentation never said anything about our methods being wrong, and despite the fact that they have to have known we were doing this.
On top of that they're doing it with a shitty implementation. They're making us pay for accessing every flag in every room, even if we only need one. Thats horrible. If they want to introduce these limits they should at least do it in a sane way- allow us to lazy load specific flags we need for instance, or only load flags from rooms where the programs is looking for flags. This would probably take work though, and so they're instead dumping this shitty implementation on us and forcing us to work around it.
While I can see something like putting a limit on flags in place, it will greatly limit the game. That being said I'd be willing to swallow it if it was tied to GCL, reasonably high (I currently use 600ish flags per room for planning) and we had like six months notice.
What I can't do is keep playing a game where the goalposts move, where our code can be broken on us at any time without notice, and where the devs will make massive game breaking changes with nothing even resembling reasonable notice or input from the community.
-
You’ve had multiple suggestions from a few people, including myself, on how to reduce server.
I would be in favor of replacing big parts of the server side logic by native code, but hell, even in js, there a lot of hanging fruits.
It is not about server side logic. Your game script should be provided with real Flag objects, it is what API conventions promise. In order to provide you with a bazillion of flags (which are free), it has to create a bazillion of Javascript objects.
the proposal on PTR is usually not definitive.
Exactly, proposals is what the PTR forum is for.
-
Art, I'm not arguing against putting a limit on the names of flags. I'm arguing about you dumping the CPU usage on us.
I did a quick check and I don't think i have anything higher than 55 characters in any of my flag names, so that change should not have any affect on me.
-
For the case with flag names being several KB, restricting the length would help that. (I would say 50characters should be plenty, at least for my uses)
For PTR, maybe have an option where it imports the user's rooms when the user activates PTR? That way the entire world doesn't need to be cloned.
-
To bring some ideas from chatting in slack about it:
1. Something is needed to make the transition smoother. As it is PTR cannot reliably be used for it as it's a major pain in the ass, for multiple reasons. One suggestion that surfaced is that maybe, way before deployment of this patch, provide us with a call that will give us a number of how much fill current flags cost under the new system. Something like Game.future.flagsWillCost() that returns the amount of CPU used to parse the flags with the new way.
2. We still want some way to visualise code and memory on the grid in an easy way, but without the cost. I love the idea that dissi suggested around the first page for icons which player creates themselves and most likely has to recreate them every tick so they won't be again used as free memory storage.
3. In CPU fairness, there should also be, very soon, implemented a way to stop players from paying for reset-storms. This is something we don't control, and yet is affecting our CPU and buckets on a regular basis, sometimes to the brink of shutting people down if they don't have code to handle that unexplained surge in CPU usage. Right now we are getting more and more cost thrown at us, fair enough, but can we in exchange have the costs we are not responsible for removed? It's fair that we pay for healthy-server reindexing, but it's not that we pay for server issues.
-
> Currently there are flags with names kilobytes in length.
I don't think anyone is protesting the name limit. I think the 50-char limit is completely reasonable.
I also understand where you're coming from with the fact that it's super abusable. I'm not suggesting that it isn't! But you have to give us more time, and you have to offer some carrot here. Right now I'm storing 3000 room positions with a couple of bits of data (the colors) for "free" because you essentially gave me that facility. Now you're saying I have to pay for it, and from the code you showed, I have to pay through a terribly inefficient method that I have no hope of optimizing.
If I have to pay for it then I want a CPU boost to help me pay for it. Maybe not enough to completely mitigate it - but it's going to cost me something now, as opposed to the "nothing" I was previously paying. This also makes it feel better to me - now, I'm not just being punished, but rather I am optimizing to gain some bonus. If I got 2 cpu/GCL, that would be 16 at my current GCL, which is half what I would be paying in flag parse cost. If I then find a way to cut my flag parse cost significantly, I might come out ahead on the deal, making the hours of work I put into cutting that cost feel more "worth it" and less like I'm just doing some unpaid dev work.
In the end, though, here's what you need to do if you want to optimize your server code. Release it. I will be so much happier to chase .5ms/call performance improvements in server code which affects every player, including me than I currently am to chase the same improvements in my own code.
Stop telling us you can't make improvements to the game that we want until you release the open source server and actually release it. The performance problems will go away on their own once you do that.
-
I’m arguing about you dumping the CPU usage on us.
Please offer an alternative then.
-
Stop telling us you can’t make improvements to the game that we want until you release the open source server and actually release it. The performance problems will go away on their own once you do that.
I’d be happy to do that right now. But there are immediate issues with this flag problem also, and they are urgent. You talk about “reset storms” - so you should know that some of these storms are caused by flags abusing as well.
-
Also, here's an idea for a staged rollout. Given that you will give us a CPU boost when you do this, let me toggle it on global reset. I want to be able to say, "For this reset, I want manual control of my flags: give me the increased CPU and charge me for flag parse time.", or "Use the old model of flag parsing, and I don't get the increased CPU."
That way I can test my code and migrate over to the new model, say, for a month or 6 weeks - and then you can force everyone over to the new model.
e: and just turn on the 50 char limit today, for all that goes. It won't affect me in the least, and if you store multiple KB in your flag names I feel like you deserve what you get. That was never a stated use of flags.
-
You just apologized for being hostile yet are continuing to show hostility.
Here's the alternative- don't be an ass? You made this game, how about you put the effort into running it and managing it such a way that you don't drive all the people off of it?
-
Define "abuse". What is "flag abuse".
We all agree that kilobyte names are abuse. How much of the problem is caused by that? Can we start with that fix and see what happens afterwords?
-
We all agree that kilobyte names are abuse. How much of the problem is caused by that? Can we start with that fix and see what happens afterwords?
Yeah, I’m inclining to agree with that. 50 KB limit is more important than the CPU cost in short term, since it’s causing more problems. We cannot fix it today, as some players rely on this undocumented feature, it will break their code, so they have two weeks.
But in long term, we have to think out the solution to free flags cost as well. Someone has 100 flags, another has 1000 flags, you have 7000 flags, and potentially someone can create 100000 flags. All of them should face their consequences, it’s just fair.
And when I say "offer an alternative", I mean that you might be interested in joining this search for solution. If you're not, then criticizing won't help much.
-
I have 5k flags, not 7k. I average 625 per "planned" room (claimed room that I will build up).
Rather than a CPU hit I think a GCL flag limit makes more sense- as long as it's high (but reasonable), and we get enough time to actually work out this change (I'm not kidding when I say you should give us like 6 months notice here). If you're trying to prevent abuse giving people even 1000 flags per GCL should prevent the "make 100k flag" issue from ever occurring.
-
You seem to be talking about 50KB overall for all flags, the limit we were refering to is 50 characters for flagname. (Which would be anywhere from 1 to 50000 flags at 50KB depending on name length)
When you say kb sized names, is that refering to per-flag names or the entire serialized rooms.flags entry?
-
and from the code you showed, I have to pay through a terribly inefficient method that I have no hope of optimizing.
Not true. Serialization mechanism is like 5% of this performance cost. 95% is
Flagobjects instantiation.
