@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?

@artch I think I understand what you mean, but there are several ways around that problem.

1. 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).
2. 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

@artch The challenge comes from the implications, not the directly-written-code. "Simply wait until your bucket is full" is already the state of affairs for all proposed solutions so far; what makes my idea different is how consecutive calls costing active CPU instead of bucket CPU is in how it limits the player's longterm CPU consumption.

Consider the following:

1. A player can use, at most, 500 active CPU per tick.
2. A player (assuming GCL 30) can produce, at most, 300 active CPU per tick.
3. chargePixel exclusively consumes CPU from the active production.

In the following example: chargePixel could be set to consume 400 CPU for 30 ticks.

1. This limits the player to 100 active CPU per tick <- this is down from 300, and certainly down from the highest-at 500.
2. This draws 100 CPU from the bucket per tick.
3. This removes 6000 CPU from the system overall.
4. 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.

In order to make the above work, there'd have to be a rule "generatePixel can only be used if it's the very first intent, otherwise it's ignored" to prevent going around the fourth point. Hopefully, this clarifies where the challenge comes from -> It's about committing to having sustainably higher efficiency code. That is the challenge

@nobodysnightmare Let's not turn this into a contest of egos thing; we're just trying to find a solution to a problem And it seems like we've found one by simply increasing the bucket cost of generatePixel to 10 000 -> The simplest solutions are often the best for situations like these.

@artch For as much detail as I put in the post, I apparently didn't put enough if you thought that It's okay though; thank you for seeing the community's concerns seriously and for the patience you've shown in the face of such hostility

I think that the overwhelmingly negative replies to this idea should be taken as a sign that the wrong decision is being made here, even if the intention is pure. And I think it might help to break down the properties of generatePixel as it is now and as it will be if the scheduled change occurs:

AS IT IS NOW:

1. This is a super boring solution and virtually the only interaction people have with the system -> if(Game.cpu.bucket>9700) Game.cpu.generatePixel();
2. Hard to balance <- With a bucket limit of only 10 000, the CPU consumed by generatePixel cannot be higher than that.
3. Economic woes <- It's trivially easy to turn unused CPU into money, thereby flooding the market with both pixels and credits.
4. CPU woes <- It's trivially easy to stack large amounts of unused CPU.

AS IT WILL BE:

1. This is a super boring solution and virtually the only interaction people have with the system -> if(Game.shard===ONE_I_DONT_USE) return Game.cpu.generatePixle();
2. Hard to balance <- With a bucket limit of only 10 000, the CPU consumed by generatePixel cannot be higher than that.
3. Economic okay? <- Pixels will be far less common, so this is mostly* fixed <- *Not fixed for people with barely-utilized alt-shards; economy isn't actually fixed.
4. CPU woes <- It's trivially easy to stack large amounts of unused CPU.

It's easy to whine and complain that something isn't how we'd like it, but I think it'll be a lot better for both the players and the game if we explore alternatives; otherwise, this is going to 1) Not actually do what's intended and 2) Become an underutilized feature. I've read through all of @artch's replies to the complaints so far, and I think I've come up with an idea adjacent to what he intends that could actually be interesting for players?

Game.cpu.chargePixel();

It's similar to generatePixel in that it consumes CPU, but different in the following ways:

1. Consumes X active CPU when called (far less than 5 000; think 100-490; this number counts against "CPU used this tick").
2. Must be called Y times IN A ROW (X=200 cpu & Y=25 ticks would equal 5 000 CPU consumed total).
3. Has a Z percent chance that, at the end of the call-series, a pixel is generated (Z=1 would be as it is now; this is your knob for economic balance!).

This function does not create any additional world-objects. X, Y, and Z are variables that can be tweaked for balance or dynamically adjusted to hit a performance goal on the server.

1. Variable X provides a challenge to the player: Can you operate at -100 CPU per tick for an extended period?
2. Variable Y provides a CPU-sink for the server: How big this number is will determine how much CPU is removed from the game.
3. Variable Z provides an economic knob: Too many pixels/credits? Lower the percentage! Too few? Raise it!

Optional extras:

4. Stun the creeps in a room provided by Game.cpu.chargePixel(roomName) at the end of the call-series? 4.1) Must be a controlled room? 4.2) Number of creeps adjusts the chance of Z? 4.3) Stun the creeps in adjacent rooms? 4.4) Generate extra fatigue for affected creeps during the call-series?
5. Creeps in a room provided by Game.cpu.chargePixel(roomName) "poop out" pixels with a random chance of variable W? It drops on the floor, and you have to be quick before it decays! <- This could potentially cause some chaos in a person's logistics network that they might be challenged to overcome 5.1) Pixels that exist physically have a timeToDecay of variable V EVEN IF carried by a creep; get it to a terminal/controller fast!
6. Variable Z could compound with each successive call-series-loop to encourage LONG TERM pixel generation (e.g. it starts at 10% and adds 1% for each call-series, resetting after a time of disuse).
7. Probably a bunch of other things I'm not thinking of that could make this fun.

In summary: There's a better way to approach this problem that's more fun AND better addresses the economic, cpu, and player-challenge problems posed by the current (and proposed) solutions