PTR Changelog 2016-09-29
-
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.
-
Artem, if the flag instantiation is the cost, can you please review and comment on my suggestion posted earlier for re-using the instances across ticks? Thank you.
-
Also, I still think you should *temporarily* raise the bucket cap until the reset storm issue has resolved. It's a simple way that only allows people to use the CPU they've already banked (so overall shouldn't result in you having more load on systems) to get through the increase in global resets that happen then.
Looking over the numbers we've only had 2185 resets in the last 126,134 ticks, but the problem is the clustering of them doesn't give people a time to rebuild the bucket before the next. Raising the bucket seems like a clean solution to that.
-
To me it looks like people use the flags for gameplay design that is missing. Some for the visual aspect, debugging (fast access memory), and planning constructions ahead. Maybe some more structureTypes need to be implemented to solve this. Like custom icon structures, blueprints that can turn into construction sites etc..
-
Here is middle ground proposal.
* Truncate the flag name at 50 characters in 2 weeks.
Even if there are abuse from the consensual pov, nobody is abusing anything as long as they stick to the API.
* extend the memory by 500 kb or better imho make it scale with gcl with e.g. 500kb +[100 kb per GCL.
in 2/3 more weeks. (so 4/5 from now)
But provide us with an API entry point that we can surcharge to optimize the flags implementation.
(And make it per room, not global so we can factor in the room name :p)
-
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.
What do you think is reasonably high?
When you say kb sized names, is that refering to per-flag names or the entire serialized rooms.flags entry?
Per flag, each of them, and thousands of them.
Artem, if the flag instantiation is the cost, can you please review and comment on my suggestion posted earlier for re-using the instances across ticks? Thank you.
Oops, I was sure I answered to that, sorry. The hard part in your solution is that all game objects are linked to the execution scope of the current tick. There will be all sorts of weird issues if we try to cache real object instances across ticks. It’s an option, but hard to implement.
Looking over the numbers we’ve only had 2185 resets in the last 126,134 ticks, but the problem is the clustering of them doesn’t give people a time to rebuild the bucket before the next. Raising the bucket seems like a clean solution to that.
We actually consider setting all players buckets to 10,000 when a reset is detected, it is why I didn’t answer to your post yet, it’s still under consideration.
-
> We actually consider setting all players buckets to 10,000 when a reset is detected, it is why I didn’t answer to your post yet, it’s still under consideration.
This would be amazing.
> What do you think is reasonably high?
If you set it to 1000 flags per GCL I would literally never use them all, and I think it would prevent abuse (especially when coupled with a nerf to the flag name limit). I would not want it to go below 800.
> Per flag, each of them, and thousands of them.
That's horrifying. You've totally got our support to nerf flagname abuse. To be honest I'm pretty sure most of us just assumed there was a limit in place so we never even tried. If you wouldn't mind truncating to 60 instead of 50 though I'd appreciate it.
-
Artem - if I cache object instances in global scope, they persist across my ticks within the same worker node. Would you be able to assign them to our own personal global context as a data container, then when we access flags the parsing cost is offset by anything that's already in our global cache on the worker? I'm not sure if that would be easier than trying to handle it outside of the secure execution context. Does that make things easier?
-
@N00bish this is a highly abusable mechanism..
This would be close to unlimited memory for everyone
-
> Per flag, each of them, and thousands of them.
Please name names and we'll solve your performance problems through ingame means.
> We actually consider setting all players buckets to 10,000 when a reset is detected, it is why I didn’t answer to your post yet, it’s still under consideration.
That sounds amazing. Consider this a vote in favor.
> Not true. Serialization mechanism is like 5% of this performance cost. 95% is
Flagobjects instantiation.Sure, but I can't optimize it in other ways. For example, you're deserializing every flag globally there. I can't override it to just be one room's flags.
Also, I am sure that creating a billion tiny strings with multiple splits is causing GC pressure.
