Game.cpu.generatePixel change
-
@artch I think I understand what you mean, but there are several ways around that problem.
- We could have the function cost a constant amount, similar to how intents already cost .2 CPU (and only allow its usage if there's the required amount's CPU available).
- Or we could have the function affect the next tick by artificially (and temporarily) lowering the player's GCL (possibly to negative values).
Both of these things are malleable, as far as my understanding at least.
Also, what @Davaned said is another way
-
@neyazayah Definitely definitely not by lowering gcl. That's a huge pile of side effects that are 100% not feasible and not correlated directly with cpu anyway as it's decoupled once you reach GCL 28.
Shards already have cpu allocations, we should just use that as the means for handling pixel generation. Decreasing the allocation temporarily (equivalent to allocating a chunk of cpu to another shard/the pixel factory) would lower the barrier to entry for cross-shard play by making related code multipurpose.
-
@davaned Oh, yes! I'm not familiar with the intimate details of the game's programming, so I missed that part.
There could be an "artificial shard" that the player dedicates CPU towards, and that is what generates the pixel? However, what @artch wants is challenge, so maybe there's a cooldown? How else might we make that challenging?
Edit: Or are you simply saying that this is just the mechanism by which CPU is removed, and everything else about the idea remains standing?
-
I still think we need a simple elegant solution here, not a whole lot of new API and inter-tick state data. Currently only two alternatives are on the table: cancelling intents or 10000 CPU cost. Let's discuss them.
-
It seems to me that a next-tick effect is analogous to upgrading a controller or trigger a creep spawn. This tick I perform an action, next tick I see effect and resources are gone. The one informational api would just be a counter.
But if you feel it's unworkable, in that case 10K is preferable to the shadow canceling of all intents. Although if the goal is balancing number of pixels I'd argue for slightly under 10k (9.5k?) to reduce edge cases. I still think the original way will likely result in players ignoring it or handling pixel gen in another shard.
-
high-energy pixel continuum burst
Barely noticed any effect at all when generating. Seems more like an easter egg hunt kind of thing.
@thmsn said in Game.cpu.generatePixel change:
Hi @artch
Could you elaborate some more on the reasoning behind this change? I don't quite get why it should also cancel all other intents? What exactly is high-energy continuum?
Are you trying to make people not generate pixels?
-
I think charging 9500 or so bucket is fine. 10K leaves you with zero bucket. To me the issue with pixels wasn't generating, by the RNG around cashing them in for high tier decorations. If those decorations did something functional then you would also see a HUGE spike in pixel prices.
-
@artch said in Game.cpu.generatePixel change:
@neyazayah said in Game.cpu.generatePixel change:
MOST IMPORTANTLY: If the player uses more than 100 CPU in a tick while using chargePixel, it'll result in premature script cut-off due to going over the limit.
This can't be done. It's not how CPU limits in Screeps work, an in-game call cannot reduce CPU execution limit within the current tick.
You seem to misunderstand the idea, we already have it in the game - intents. The difference would just be that this intent doesn't cost the usual 0.2, but 400 cpu.
While I agree that accusing you of not caring for the community does not help the discussion, you just disregarding any and all propositions that don't fit the idea of change you already have in mind does not help your image here either. I do think it is unfair for you to just disregard genuinely good ideas by only giving pseudo arguments. And while you say you want a simple and elegant solution, the only ones you even consider are the exact opposite of that - unless you mean simple and elegant for you devs to implement, in which case you're right, but that line of thinking just increases the already abysmal chasm between devs and players.
Since everything else - no matter how good, actually elegant and practicable - seems off the table anyway, my vote is on increasing the generation cost. I do however also think that the whole 10k are not a good idea, as they will just cause too many edge cases - a good portion of which the players will presumably not be able to influence -, so somewhere in the 9.5k-9.9k range should make that workable.
-
You seem to misunderstand the idea, we already have it in the game - intents. The difference would just be that this intent doesn't cost the usual 0.2, but 400 cpu.
Intents do not have the ability to do this:
it'll result in premature script cut-off due to going over the limit
Intents operate on your bucket, not on the "active CPU".
-
@artch said in Game.cpu.generatePixel change:
I still think we need a simple elegant solution here, not a whole lot of new API and inter-tick state data. Currently only two alternatives are on the table: cancelling intents or 10000 CPU cost. Let's discuss them.
Definitely.
I would like some clarification on game mechanics though.
My understanding is:
You have 20 + GCL * 10 CPU for the tick
If you go over, you can use up to 500 from the bucket, if available
If you go under, any excess is given to the bucket, which is capped at 10k
So a 10k generate pixel would nuke your bucket, but you'd still have your CPU for that tick?
If so, I think that is the best solution. It introduces interesting challenges around your bucket not always being there.
-
@artch said in Game.cpu.generatePixel change:
Intents do not have the ability to do this:
it'll result in premature script cut-off due to going over the limit
Intents operate on your bucket, not on the "active CPU".
I see, that seems to be a common misconception then. I think for the community to better understand the implications the change entails it is important for this to be cleared up.
So the 0.2 operate on the bucket, does that mean the other cpu used does too? If not, how do those work together for the 500(-ish) cut-off per tick? https://docs.screeps.com/cpu-limit.html only mentions how averaging it out works, but does not mention what to expect when you skirt the edge of this system. According to my current understanding (including these facts you mentioned) the 10k could lead to some problems caused by not the user, but the system.
-
@cribbit This seems correct.
-
@rayderblitz Your script has execution limit that is predefined before it starts. It is always
min(bucket, 500). No in-game calls can change this hard execution limit.Basically, there is no such thing as active / bucket CPU as in your description. It is all the same. All CPU used during the tick decreases your bucket. All intents decrease the bucket too. Every tick your bucket increases. And the limit is just
min(bucket, 500). I can't seem to get what do you mean by active CPU.
-
@artch said in Game.cpu.generatePixel change:
@rayderblitz Your script has execution limit that is predefined before it starts. It is always
min(bucket, 500). No in-game calls can change this hard execution limit.Basically, there is no such thing as active / bucket CPU as in your description. It is all the same. All CPU used during the tick decreases your bucket. All intents decrease the bucket too. Every tick your bucket increases. And the limit is just
min(bucket, 500). I can't seem to get what do you mean by active CPU.Huh, wasnt "active CPU" a term you introduced?
Anyway, since both normal (processing) cpu and intent cpu seem to work with the same pool (a min of 500 and bucket), it seems to me that it's doable. All an intent does is just add an artificial (predetermined) 0.2 cpu to whatever the checks of that intent cost, right? So if you have 250 in normal cpu doing calculations and 256 in intents in a tick, that should give you a timeout as far as my understanding goes, since you go over the 500 limit. The same would apply to 400 in calculations and 105 in intents, 50 in processing and 450 in intents and so on, did I get that right?
Now, the idea is to have generatePixel clone the behavior of intents and replace the 0.2 cost with a 400 cost. Assuming I understood the above correctly, that should be doable. That way we would effectively (but not factually) reduce the available cpu in this tick to 100. In doing so we would then be able to implement many if not all of the ideas proposed by @NeyaZayah and others.
As for the change you currently have in mind, one thing that I'm not yet sure is clear to me but would be critical is how exactly adding the current tick's cpu to the bucket (since it is used as the base for the cpu calculations) works. Is it calculated before the tick with a min(10000, bucket+cpu) or can you have more than 10k (bucket + cpu) during that tick and afterwards it's min'd out? Depending on what is the case here it might lead to the problems the player isn't to blame for I mentioned above. Then there are also issues like Game.cpu.getUsed() sometimes not accurately reporting the up to date cpu usage I and others have observed (assuming that hasn't been fixed in the meantime, haven't noticed it in a while).
-
@rayderblitz said in Game.cpu.generatePixel change:
So if you have 250 in normal cpu doing calculations and 256 in intents in a tick, that should give you a timeout as far as my understanding goes, since you go over the 500 limit. The same would apply to 400 in calculations and 105 in intents, 50 in processing and 450 in intents and so on, did I get that right?
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).
-
@artch said in Game.cpu.generatePixel change:
I still think we need a simple elegant solution here, not a whole lot of new API and inter-tick state data. Currently only two alternatives are on the table: cancelling intents or 10000 CPU cost. Let's discuss them.
If these are the only two options I personally prefer the higher CPU cost.
-
@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.
