Game.cpu.generatePixel change
-
I guess it depends on what you mean by "this".
A tweet on Nov 23 announced that a different change (cancelling intents) is going to be deployed at a different date (December 7), requiring different changes to our codes.
A forum post on Dec 8 (20:32 CET) announced the actual change on a forum post (not even a new thread) that would happen on Dec 10. This was then reposted by o4kapuk on slack 3 minutes later. It never actually made it to twitter and the first time a lot of people (those who have not read the forum thread since Dec
found out about it was a little over a day before it was actually deployed... if they read slack during the week, that is - because I for instance mostly have time for screeps during weekends and finding out that a breaking change forcing workarounds in my code to not break it was "announced" and deployed during the same week is just making me sad. There was no deadline - the revised design could have been announced through the proper channels with proper vacatio legis and deployed a week later, but it was not.I'm just pointing out that the communication about that new design of the pixel change was not 100% perfect and I hope that we can all use that opportunity to draw conclusions and learn from it so that it is better in the future.
-
@rhef But why is it a breaking change? What does it break? The only possible negative effect may be a low-bucket situation, but this situation is normal (e.g. after runtime resets), and your code must be able to handle it properly. If it cannot handle it, then you miss a lot of ticks anyway, and 1 more missed tick doesn't make much difference to call it "breaking change".
In real breaking cases (when players are expected to change their code) we always test it on the PTR, announce it months in advance, and discuss drafts of the API with the community again and again. Since you're new to Screeps, you may have not seen these discussions, so just one example of such schedule:
- The new
StoreAPI has been proposed for discussion on April 26, 2019. - The PTR implementation was available to test on June 24, 2019.
- It has been released to production on October 14, 2019.
- The new
-
You can see the impact it had on #announcements-any slack, people started hitting global resets a lot when pixel generation ate their entire bucket unexpectedely. You can probably see a clear trend of it on a server-side chart of global resets per tick, if you are monitoring it.
My code never had to worry about bucket being at much less than 4k. I have an expensive room planner figuring out whether some new buildings or roads need to be done, sometimes it runs on the same tick as a creep scheduler - now they can burst through the limit, cause a reset, which will then on the next tick try to run pathfinder-heavy room planners for all rooms (as those set some room properties that are used by other systems to optimize the work for a small/medium/large room), which causes another reset until the server-side mechanism triggers when it sees that I'm skipping multiple ticks in a row, freezes my code completely to fill up the buffer and then brings my code back online in hope that it can plan all rooms before it bleeds out.
-
@rhef So you seem to treat persistent global as some documented guaranteed behavior, but it's not. We don't guarantee that you will have the same global each tick. Global reset is a normal situation, many reasons can cause it, including automatic runners recalibration within the cluster. Your code should not rely on it that much, and if you do rely on it, you're using undocumented behavior - which is fine and acceptable, but can't be referred to as a breaking change.
A breaking change is when you're forced to change API usage or game objects behavior, not some internal optimizations of your code.
-
Yup, this last minute change in decision broke my logic and caused me to lose a room due to script execution timeout (in the middle of a battle). I had written the code out anticipating the intents being canceled.
-
@crazydubc Sorry to hear that. To be fair, the 10000 CPU alternative has been discussed since November 25, so it's not really that "last minute". The top post has been updated long time ago as well.
-
To be fair, it was discussed for a while, but then officially announced less than two days before deployment without proper communication, in the middle of a week.
@artch are you trying to say that the announcement and delivery of this change has been executed perfectly and so nothing shall be improved in the future, if a similar change is going to be deployed one day?
Or maybe there is some room for improvement, we'll remember this situation and use this it as a lesson to improve our ways?
-
This post is deleted!
-
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”So I finally found this after having unexpected behaviour for the past few days. @artch top post still says 5000 cpu and cancelling intents, and the Nov 25 post about it makes it sound like a suggestion not the planned update. When are we getting a bigger bucket to accommodate this change?
-
PIXEL_CPU_COST still returning 5000.
Screeps Documentation still lists PIXEL_CPU_COST as 5000.
While this isn't fixed you are breaking people's... trust in you!
(and also incidentally their code)
-
@rhef There is always room for improvement for everything, that's sophistry. What I'm saying is that we always treat breaking changes seriously, and non-breaking changes less seriously. Because we don't have enough resources to run full-scale communication procedure for every tiny change. We only have 4 people in our entire team for both World and Arena, and the community manager is also the game engine developer. Hence the more communication, the less development. We did our best in this case, and I think it was good enough, given how tiny this change was in comparison to the initial intents cancelling idea.
Please don't judge us how you judge big companies with a lot of staff and resources. We're a small indie team, and we cannot follow all the same procedures you got used to in other places. Especially given that it's a game, not a banking system.
-
@tdxtor Oh wow, and this is the real issue here, unlike communication. Sorry for that, fixed now. It should have been deployed together, but somehow got overlooked.
-
@artch said in Game.cpu.generatePixel change:
@tdxtor Oh wow, and this is the real issue here, unlike communication. Sorry for that, fixed now. It should have been deployed together, but somehow got overlooked.
Screeps documentation still lists PIXEL_CPU_COST as 5000.
The communication is a real issue here, you are insulting us by dismissing it over and over again so flippantly. Your SEO is garbage. Google "screeps patch notes" and tell me where you see this thread or a link to this forum. I see links to people asking where to find patch notes, but no patch notes. I see no links to screeps' twitter or slack or discord or forums or whatever on page one of search results.
"Top post still says 5000 cpu and cancelling intents, and the Nov 25 post about it makes it sound like a suggestion not the planned update." You still hadn't decided which tact you would take with the update here https://screeps.com/forum/post/15881 and you only actually announced the change 5 days ago here https://screeps.com/forum/post/15895 but you have lied about it in several posts since.
You failed to communicate this.
Take a deep breath, admit it, then make sure to do better next time.
Because of how badly you did communicating this, people are asking "hey, are you going to do a better job in the future?" and you are just blowing them off when we need a real answer. Also, maybe you should have a tip pop up to let players know this is where they need to be looking for critical update news so they find out 2 days before a change happens, instead of 2 days after.
Next and perhaps more importantly, you used to have a system to buy back your cpu for a fake currency, now you largely don't. What used to be in people's "if(Game.cpu.bucket>9500){" used to be "give the devs compute back in exchange for fake currency so that game ticks can be faster" but now we have to go back to "while(Game.cpu.getUsed()<400){}" so that we are getting our cpu's worth. This slows the game down, make the game less fun for subscribers, and devalues all cpu subscriptions since they will work for fewer ticks (which will cost screeps real money as people unsub).
-
@tdxtor wow on https://status.screeps.com/ you can see some people have already gotten wise and are making ticks longer. Just wait until the devs actually communicate this update to the players.
-
@tdxtor We are definitely going to do a better job in the future, when we become an enterprise-grade service with dedicated QA, SEO, SMM, community management teams, and dozens of full-time employees!
Until then, we're sorry for any inconvenience and thank you for understanding. And don't forget it's just a small niche game for enthusiasts.
-
Also @tdxtor, indiscriminately spamming several negative emoji on each and every my post is not conducive to constructive discussion really. Especially like this middle finger one:
Consider it final warning. One more such offensive action, and you will be banned on the forum.
I'm closing this thread for now.
-
Since there is still some misunderstanding, and it continues to pop up in Slack, I'd like to clarify some of my points posted before.
I said that we want to make generating pixels more challenging. Some players misunderstood it (or I misspoke it, sorry for the language barrier) in a way that we want to make it more interesting, and it contradicts the initial statement of a simple balancing change (i.e. a nerf). The misunderstanding was even to the extent calling it a misinformation and lie.
Actually what I meant by more challenging is more difficult, requires more difficult code, a higher entry barrier. It does not contradict a nerf, it is a nerf: the entry barrier was lower, and it should be higher. If we happen to make it more interesting at the same time, it's fine and good, but it's secondary, it's not the initial purpose, and is much less of a priority (at least for now).
The important point regarding this nerf is that we wanted it to be qualitative rather than purely quantitative. If we raised the CPU cost to 9000, or raised decoration pixelization price, it would only change the market value. This is not our intention. Yes, we wanted to increase the value, but indirectly - not by means of increasing some numeric constant, but by means of raising the difficulty level. It should be a complex difficulty nerf rather than a simplistic value nerf (the former though indirectly triggers the latter as well). Even 9900 CPU cost would not achieve this effect. Only exactly 10000 CPU (similar to cancelling intents) poses a new challenge. This change is qualitative.
And the number of players declining generating pixels because of this change just proves this point. It shows how easy it was for everyone to start generating pixels. Because everyone has free CPU leftovers that don't have any value. Lefovers are simply wasted otherwise, they are never used. Generating free income from such no-value freebies is not what pixels are for. Now players are forced to either code to cover low-bucket situation (a higher entry barrier), or consciously dedicate CPU to generate pixels (which is not free and has real value).
I hope this explanation will resolve some misunderstanding that has appeared in the community. Sorry for being not able to explain this earlier. Such discussions and explanations take time (this post took me 1.5 hours to formulate and write) which I didn't have by that moment.
-
@bogden said in Should generatePixel now generate 2 pixels, since it costs 10k CPU?:
So now that people are declining to generate pixels because they don't want to code around the empty bucket case, can we increase the reward to match the previous CPU/pixel generation rate for the people who are willing to code for it?
This is a very interesting idea, we will consider it.
It makes
generatePixelsemantic a bit non-consistent though, since it is supposed to be singular, one single pixel.
-
@Bogden Personally, it would drive me nuts if they did that, especially if the total number of pixels in existence when they did that was an odd number. Knowing there would be an odd pixel out there that could never be redeemed would be aggravating lol.
-
Since emotions are settled down finally, I'm opening the thread again, and moving some relevant posts here to keep it in one place. Please remember to be respectful and stick to the constructive discussion without getting personal, offending and accusations.
