Game.cpu.generatePixel change
-
@artch said in Game.cpu.generatePixel change:
No, there will be no timeout. The limit is on the execution time, not CPU points. You will be able to continue running your script until your
min(tick_start_bucket, 500)execution time is over, regardless how much extra CPU points you has spent during the tick. All extra will be simply subtracted from the bucket (which can even go negative).Ah, I see. No timeout then, but the different intent cost would be doable?
That's one aspect gone of course, but there are still many good ideas remaining. If there is really no changing your mind about any options other than the two you mentioned then I'm still for the (not quite, to be safe) 10k cost. I think it would be a shame though, as both solutions would generally just lead to players ignoring the change, ignoring the system or switching over to a slave shard (which is basically no effort, much less a challenge).
As this change is supposed to be for the players, however, I do think it's important to invest more time into working out an interesting system that will be a worthwhile change and adds to the players' experience - even if it takes a little more effort to work it out. If you give us more information about the criteria, restrictions etc. the community is very much willing to help out and I think you should take advantage of that. "[A] simple elegant solution" is not something easy to work with when the only two currently accepted solutions are not that at all.
-
@rayderblitz Unfortunately the community can only help in discussing the ideas rather than implementing them. And we lack developer resources to refactor this mechanic currently. Season and Arena are much more important projects than pixel generation. But we may revisit it some day in the future.
-
@artch For the "10000 CPU" cost option, I assume your normal CPU tick limit (max 300) would still be available to use since that 10k is strictly coming from the bucket? If so, this is definitely the best route as it increases the difficulty in farming pixels without causing undesired limitations in other areas. You would still have enough CPU for high priority intents like tanking tower damage during a siege. This lets you farm pixels 100% of the time if you solve the problem where the other route forces you to suspend pixel generation in situations where skipping intents for one tick is not an option.
-
@artch said in Game.cpu.generatePixel change:
@rayderblitz Unfortunately the community can only help in discussing the ideas rather than implementing them. And we lack developer resources to refactor this mechanic currently. Season and Arena are much more important projects than pixel generation. But we may revisit it some day in the future.
Yeah, that I definitely get. Even if the community provides you with fleshed out code you need to verify it does what you want the way you want etc. Though that makes me wonder why you decided to push this change now, given there is so much going on. You guys are working on Seasonal, Arena and other planned content like the other power creeps.
Personally speaking - though I'm certain I may as well speak on behalf of a majority of the community - I would rather see you invest the time you have into those features than time you already don't have into barely to not at all worked out concepts like this currently discussed change. Sometimes no update for a while is better than a forced one - not that that even is the case with everything coming up.
-
@rayderblitz We pushed it now because increasing 5000 to 10000, or adding intents cancelling is a very simple change. And it's long overdue, we discussed it 2 months ago already.
-
generatePixel cost will be changed from 5000 to 10000 CPU on December 10. No other changes to this method will be made.
-
@artch said in Game.cpu.generatePixel change:
generatePixel cost will be changed from 5000 to 10000 CPU on December 10. No other changes to this method will be made.
My exact reaction:
-
I'm much happier with this option that the original proposal of cancelling intents.
If you're good with your CPU management and plan a bit you should be able to handle this no problem. I expect to see more interest in #operatingsystems as a result of this, which is no bad thing.
-
notification 28 hours before deployment...
-
@rhef said in Game.cpu.generatePixel change:
notification 28 hours before deployment...
This has been announced 2 weeks ago for December 7, but got delayed for 3 more days. See this thread from the top post.
-
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)
