PTR Changelog 2016-09-29
-
That's the problem, though, Artem. I was certain it was GC and thank you for confirming that, but the GC cost is something that is not necessarily related to our code, but could also come from the game engine, previous players code, or elsewhere - yet we have to pay for it on our own ticks and our own cpu time. I know that's a hard problem to solve, and my complaint isn't with having to pay it, it's with the inconsistent timing of *everything* when GC hits. Adding another parsing step to our cpu costs will cause ticks to vary even more wildly than current, and if you have a "bad" tick you can hit the tick limit before you finish processing your code. Isn't there a way to record aggregate flag parsing cost for each tick, then average it? You can take that number, add 20%, and call that the new "constant" for per-flag parse time. You could even make it a moving average - I just think it's unfair to have a 4x difference in CPU cost between ticks and expect us to be able to code around that. I'm not looking for cheap / free flags again - hell, make the parsing cost a full CONST 0.2 for all I care, but please work with us to find a way to make it consistent.
-
GC spikes are the reason why all players have the bucket and 500 CPU tick limit. It affects all players exactly the same eventually.
Anyway, let's just wait and see what it will look like on the live server. If it's too inconsistent, then we'll consider other options.
-
Is it possible to hook up user-methods which should return flag objects?
If we could somehow return an array of Flag[] to the game engine
ScreepsEngine.hook('loadFlags', someFunctionWhichLoadsFlagsFromMemoryOfPlayer)
ScreepsEngine.hook('loadRoomFlags', sameAsAboveButFilteredForRoom)If one of the function fails to reply as according to spec, flags should just be ignored, or a runtime error should occur. Examle:
engine requests flags for W12N1 , user code responds with W12N2, engine throws error.
Just like PathFinder.use() you can choose to use it or not.
Obviously this requires the engine to check the validity, but as you said: "Iterating is an order of magnitude less expensive than parsing" on which I agree wholeheartedly.
We were already discussing different ways of storing them in memory in an efficient, single-string way:
X [ 6 bits ] 0-63
Y [ 6 bits ] 0-63
W/E [ 1 bit ] W or E
[NUM 15 bits] 0 to 32767 (allows for expanding to a world which goes from W0-32767 E0-32767)
N/S [ 1 bit ] N or S
[NUM 15 bits] 0 to 32767 (allows for expanding to a world which goes from W0-32767 E0-32767)
COL1 [ 7 bit] 127 colors!
COL2 [ 7 bit] 127 colors!
Length [NUM 6 bits] 0 to 63 - length of string
NAME [remainder]This should speed up parsing by a lot. Not needing to do splits saves a shitton of memory. This would even fit in the diplomacy module we got going.
-
Only reason I use flags, is as you said, because I want to see my operation going: http://i.imgur.com/STJPhGX.png
I could change this now and everything would still work the same.
If we can get beacon for displaying what happens, that would be amazing to. No name, just a position + icon?
-
We were already discussing different ways of storing them in memory in an efficient, single-string way: This should speed up parsing by a lot.
We tried to do it this way and didn’t see any considerable performance benefit in comparison to simple
splitcalls. String operations are very fast in V8,Flagobjects instantiation is the bottleneck here.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.
Is it possible to hook up user-methods which should return flag objects?
If we can get beacon for displaying what happens, that would be amazing to. No name, just a position + icon?
Yeah, such features would be cool. Probably, in the future.
-
Artem, what about having flags not be fully instantiated every tick on the server? You could instantiate them once, then cache the resulting objects at the end of each tick and apply the data changes to the existing objects and add updated flags to Game.flags for the player, and discard the cached list. This would reduce instantiation cost as the objects would already exist, and you'd instead be iterating over the flags to synchronize the data with the properties. Is this feasible at all?
In short, promote on write - here's the basic idea:
// Tick ends
_gameCache.flags[playername] = Game.flags
// Tick start
_.forEach(flagroomData, f => {
// Split, etc
if(_gameCache.flags[playername][parsedName]) {
// Update properties directly
_gameCache.flags[playername][parsedname].color = COLOR_RAINBOW;
Game.flags[parsedname] = _gameCache.flags[playername][parsedname];
} else {
Game.flags[parsedname] = new Flag(..parsedinfo);
}
}
// Clear cache, references to flags that already exist are now in Game.flags for the player
// and will be copied back out on tick end
_gameCache.flags[playername] = {}
-
The reason most people use flags is to have a pointer to memory which they can quickly click:
They want to display some piece of data by choosing a color and an easy way to open te memory viewer.
I think if we can emit events for the game to display:
Game.rooms['someRoom'].displayIcon(SomeRoomPosition, COLOR_BLUE, COLOR_RED, "path.to.memory") // Maybe public/private? vision required!
A lot of people would be happy. Of course you can still choose to use the flags, but at a cost.
-
We could also impose a GCL cap on flags.
-
If you make this change I will quit the game. This is bullshit- my entire program is going to have to be rewritten for scratch!!!!
-
For the record I'm mostly using flags to place buildings. I'm not trying to cheat to use less memory, I'm literally using flags to mark locations of things.
-
I know you don't give a shit about my opinion because I have a lifetime license, but I supported this game from the beginning and brought in dozens of players. I started the open source projects.
And now your bullshit is making me rage quit.
GOOD FUCKING JOB WITH COMMUNITY MANAGEMENT GUYS.
-
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.
-
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.
-
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.
-
>> 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.
-
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.
-
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.
-
> 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
< 2932I, 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.
-
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.
-
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.
