PTR Changelog 2016-09-29

tedivm

YOU WON'T EVEN COPY THIS OVER TO PTR FOR US? JESUS CHRIST HOW DO YOU EXPECT US TO TEST THE GOD DAMN WRENCH YOU"RE THROWING INTO OUR SYSTEMS?

Maybe you should try actually playing this game so you realize how badly you're fucking your customers.

tedivm

You aren't even attempting to use your god damn brains on this one.

How about making us a Game.rooms[].flags so we don't have to parse EVERY DAMN FLAG just for one rooms flags?

This is just another half assed barely thought out change that is going to screw everyone over.

stybbe

Calm your tits mate, it isn't as bad as it look. The expected cost will be around 1 cpu for every 100th flag and it should mostly affect the players who has been using the flag objects as their memory object.

If you just use the flag to mark locations you just need to remove them when you done.

Dissi

>> But if you manage to make some benchmarks and prove that your method is a lot faster, then it should not be a big issue to switch to a new format

I don't want to share that code, I can make things fast, which gives me an edge over other players. That's the whole point of the game right? I get my edge by being more efficient than others. This makes me play this game, but currently that's taken away from me, bit by bit.

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.

anisoptera

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?

I'm not going to disagree that flags should cost something to parse. Storing things in flags instead of memory is obviously just offloading data from something I pay for to something I don't, and the solution to that is clearly for me to have to pay for both.

That said, it's essentially impossible to avoid triggering flag parsing somewhere in your code, because all Room.look methods (even, it would appear, if I call LOOK_TERRAIN) will trigger this. So the only option is to use flags sparingly.

I don't have as extensive use of flags as some others but I have about 3000 flags right now, because there was absolutely no hint that this wasn't "intended usage", and no hint that they were going to be hit so hard with the nerf bat. I have to fix my code, or it will essentially stop working entirely in 14 days.

Did it ever occur to you that hitting the players with nerf after nerf is extremely demoralizing? Again, at my actual job I get massive notice before changes like these, huge amounts of opportunity to bring code up to standard, and these types of changes are few and far between. And I get paid to deal with that. It’s the opposite situation with this game. I pay you.

A suggestion: If we are going to pay the CPU cost for this, something that was previously taken on by the server, perhaps an increase to our CPU is in order? Something like 2 CPU per GCL increase. Right now this change is entirely a nerf. Built anything in your code that uses flags? Congratulations, your code is now less performant! I have to do a non-trivial amount of work just to get back to where I am now. That does not feel good at all. At least if we got a CPU buff along with this, there would be some carrot with the stick: here’s the CPU you were using, if you optimize your code you can actually get more CPU than before the change - and perhaps this would also mitigate the damage and allow a bit more time to change code.

I am supposed to enjoy playing your game. I am not supposed to wake up to posts about a game that tell me I have to spend hours of work to continue using the code I’ve invested, conservatively, hundreds of hours in, and I have a deadline to do this. What if I left on vacation? I’d come back to a dead empire, because my code couldn’t even get past initialization.

I used to unequivocally think that I would love the chance to buy a lifetime sub, say in the next indiegogo campaign. This is the first change that has made me waver on that thought. I am seriously reconsidering spending so much time on this game right now.

tedivm

stybbe- they never once said there would be a limit like this. They even made changes to make flags perform better and commented about how a lot of people use them. From my perspective they encouraged their use- find me ONE document from the devs that say we shouldn't be using flags to define where we want things placed, or even that they should be limited in us.

I'm also confused by this "using it as a replacement for memory" nonsense. Flags are basically one-player structures that can be used to mark locations. It's not like people are (as far as I know) attempting to bitsmash to save data in flags, and if they are focus on that *that* problem.

Instead they're retroactively changing the rules. Not only that, but they're refusing to give us a proper platform to test these changes, forcing us to do so in production. And we're only getting us two weeks to do this.

The devs have made so many changes lately that the game has stopped being fun. I'm sick of having to rewrite or rework my code just to get back to where it was because the devs are literally changing the rules of the game.

Seriously, this game needs something like EVEs "council" of gamers.

anisoptera

> Calm your tits mate, it isn't as bad as it look. The expected cost will be around 1 cpu for every 100th flag and it should mostly affect the players who has been using the flag objects as their memory object.

I'm in his boat:

> Object.keys(Game.flags).length
< 2932

I, too, only use flags to mark locations: buildings and roads. Honestly I don't know how I ended up with so many, maybe it's the roads. But the point is that I now have to completely rework my building code to deal with this change. 1 cpu per 100 flags means I'm paying 29 cpu per tick. tedivm is even worse off.

I have to spend hours to write a bunch of code just to keep my current codebase running and I haven't seen anything but nerfs for months. I wrote a bunch of code for boosts: now boosts are really hard to make. I wrote a bunch of code for the market: now no one uses it because minerals are too precious. I wrote a bunch of code for automatic layout: now the mechanism I used to store my layout is going to cost me half my CPU/tick.

It's not fun. Games are supposed to be fun.

tedivm

Honestly, in the last month it felt they they were just screwing with us.

1. Market requires 10cpu to 25cpu if you want to read the orders in it.

2. Pushed a no-notice upgrade where they didn't bother checking to see if they killed anyones code, and took my empire out for six hours. Had I been on vacation it would have been the end of the game for me.

3. Nerfed minerals, forcing people to rebalance.

4. Removed real testing on PTR by no longer copying empires over (you now have to rebuild it from scratch with 10+ second ticks).

5. Nerfed flags.

Honestly, I wish the devs would spend some time working on the open source server instead of spending all this time ruining their game.

tedivm

Hell, half the reason people use flags so much is because of how memory used to get corrupted. So you built this situation you're now punishing people for.

Dissi

This years nerf/buff report so far, this is in no way the vision of the community, it's purely based at my own personal experience with the game so far.

tedivm

Dissi, you really should put the retirement of PTR as a testing server in there. Now that they don't copy the empires over it's basically useless.

Dissi

There hasn't been a big change which required me to use PTR (I test in PROD a lot, I'm a monster). I've voiced my concerns for the /PTR not being equal to /A in this thread. I can't make changes to my flag system without PTR, it's too risky.

tedivm

Exactly. It's impossible to test the scenario they're proposing here.

tedivm

The current theory on slack (shared by dissi, nhahno, myself and others) is that you're purposefully pushing out the older/bigger players to make rooms for the new ones. That's how bad we feel this community has been managed in the last few months.

Dissi

I agree with what tedivm said, it does feel like "being big" is severely being punished lately

ags131

As a smaller player who has barely managed to gain 3 rooms so far, these recent updates have sucked quite a bit, I'm already struggling to stay within my CPU limit at times, much less during the ~3 hour reset storms. Adding even more CPU cost just makes it even harder. I don't always have the time to spend to optimize my code, and refactoring to where optimizing and improving is easier is that much harder due to sudden changes. I use flags to both mark future building locations as a visual tool, and to mark rooms for claiming, parking spots for idle creeps, etc. But judging by these changes, flags should only be used for debugging! This makes them virtually useless to me as just having them causes massive increase in CPU. For someone as small as me and low GCL, 1-2 CPU can make all the difference when thats 2-4% of my total CPU.

tedivm

The fact that you guys have time to do this but won't even respond to my request for a larger bucket (due to the massive increase in global resets, plus the garbage collection costs) is disconcerting. I don't even know how we're supposed to handle power creeps on top of this.

Seriously something needs to be done to get more community involvement going here.

Entity

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.

n00bish

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?

daboross

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;
    }
}