@Atanner Does anyone use boosts for ongoing tasks? Every time I run the numbers it's clear I'm better off without boosts. Always credit wise, usually intent wise, it only saves spawn time. My only ongoing boost activity is RCL8 controller upgrading.

I agree with @Davaned something would be good, defending a structure without rampart and towers is something that doesn't really exist yet in screeps.

I don't think belts are a good idea (It just trade player intent cost for equally high processor cost). It might be possible to do it efficiently with a pipes where you can't see the resources in transit.

Simplest would be some sort of remote Link.

Another idea would be 10k capacity tesseract structures that are expensive to build but can be built at any RCL. (limit the tesseracts so they only share storage with other tesseracts in the same room).

Remember that the server's goal is to maximize cool-stuff/core not minimize cores/player(1).

Highly efficient code bases have some of cool-stuff tricks. Since they consume less cores they have a great cool-stuff/core ratio. A rebate that encouraged more cool-stuff has a similarly high ratio. I don't think credits as a rebate for CPU would improve the over all cool-stuff/core ratio. Players would mostly just do less or cash in on the otherwise unused CPU and create a new credit source (bad).

Selling bucket has the potential for lots of cool-stuff. First order: active bucket market place, selling a unique resource, anchoring credit value, new credit sink. Second order: Players building 300+ cpu empires, new bucket intensive tactics, creative space for players to create cool-stuff that would be restricted by 10k bucket.

So how much cores does the new cool-stuff cost? A bit. Every core spent here is new cost, as opposed to shifting cost from some other activity. This is slightly offset by the economy effect of giving credits to players who need it to do more cool-stuff.

Subjectively, this seems like a high cost, possibly high reward feature. I've heard rumblings from other players that the disparity between newer players and established players with a 300 cpu empire, is a design problem. Selling bucket makes this disparity greater for better or worse.

Overall, I'm not opposed, but I suspect there better (less risky) features to add.

(1) If cores per player becomes a true issue the devs can always scale the value returned by Game.cpu.getUsed() so that each player consumes less server cores. Also I'm purposely ignoring the game design side of the question of balancing cool-stuff among players and encouraging player subscription.

I really like the idea of creating a battle incentive where loosing doesn't mean a room wipe. I also think combat without towers will create new and interesting puzzles for players to solve.

As for the idea itself, why would I want a static mining facility? Drop mining is already very efficient, most of my intent cost is hauling energy back. Optimal energy haulers have 1600 capacity already. Hauling from a 2000 cap container isn't any less efficient than hauling from a larger capacity structure.

@SemperRabbit It looks like this is branched from main. It should branch from PTR, otherwise this will force all the new Store to code to rebased (merge-hell).

@SemperRabbit No pull request so I'll leave code review comments here.

Use braces on all multi line if statements. That seems to be the style in the rest of the repo.

Consider breaking this up into two PRs. The first one creates the new base-creep type in the existing creep file renaming classes but otherwise not moving code around. The second one moves it all to the new file. This would be far easier to review as the unchanged functions would be nearly diff free. The second one would have tons of diffs but very little new code. The easier the PR is to review the more likely the devs will accept it.

We're still having memory problems with high room counts. I suspect the indexes are to blame. FIND_MOVEABLES is a fine idea but I would discourage a new index just concat the FIND_POWER_CREEPS and FIND_CREEPS calls. For completeness add a FIND_MY_MOVEABLES as well.

Here is a behavior change. Object.getOwnPropertyNames(Creep.prototype) would no longer return move or moveTo.

I assumed it would break more stuff. I was surprised that Creep.prototype.move still worked the same.

I really think this is a good idea. And it fixes the bug of changes to Creep.move affecting PowerCreep.move.

Boosts could even re-use the existing power effects. That would simplify a lot of damage code in the processor.

The "low tier boosts are under used" argument has been brought up a few times. The answer so far has been "but we still see them being used". That is pretty hard to counter since we don't have the numbers, But screeps plus is big enough ags might be able to chip in whether this is true or not. I think Tigga is often cited that the lower tiers are useful as is, (imagine tiggers armed with three times as much tier 1 boosts).

However, I've never heard the lower the compound cost for lower tiers argument. I think this deserves more investigation. Possibly go so far as introduce per compound cost. Then the devs could selectively make some under used boosts cheaper to use without disrupting the whole.

Either way I think it would be wise to let factories land and settle before we advocate tweaking anything that might affect the mineral market.

Those numbers looked pretty bad so I played with it a bit myself. I always set the swamp to 5x the plains and never used a plains cost of more than 40.

The CPU is bit noisy so I ran each test 3 times and looked at the median. I noted that first run of any query was noisier than the rest. If I were going to do this for real I'd run 4 discard the first and take the median.

With normalized cpu the numbers don't look as bad but there is a definite increase in CPU with the greater ops (it's not just an accounting error). I should have been more methodical to get solid numbers but here were my impressions. I played around with short, medium and long paths, both intra-room and inter-room (just 2 rooms).

There is a per room overhead that looks to be about 0.1. I suspect this is the CostMatrix callback. I didn't use a custom callback so the overhead might change.

CPU increased with ops, More complex paths took more ops and more CPU. Roughly I'd guess per op cpu is less than 0.005. For the configurations that blow up ops the CPU cost does increase, but not as much; e.g. the CPU cost of each op during a blow up is much less but non zero.

What I'd like to do craft 2 paths: one short and one long and configure the short one to blow up so that it's ops are equal(ish) to the long one. That should give some solid number on how expensive blow ups are. But ultimately the answer is going to be not much

I want more data now. Can you run this again tracking actual CPU used as well (and print ops/cpu). Also add these tests:

testPath(1, 1, 9)
testPath(9, 9, 1)
testPath(9, 9, 10)
testPath(10, 10, 9)
testPath(20, 20, 9)
testPath(9, 9, 20)

Pathfinder does not use plain A*. Is uses JPS and A* derivative. Plain A* is guaranteed optimal (best path, fewest inspected) for any graph traversal. JPS beats A* when executing on a uniform cost grid. Many screeps rooms are pretty uniform.

My theory is that the ops calculation has a bug it uses a JumpPoint and PathFinder reports inflated ops count. Or a Jump Point allows PathFinder to inspect many nodes for minimal CPU cost, so PathFinder over inspects to avoid the heavier cpu cost of possibly A* inspecting those same nodes. In either case we'd see higher ops cost withou a corresponding jump in cpu cost.

My fear would be that JumpPoint has a hard coded value of 5 in it somewhere and 10 causes it get an elevated rate of out of room positions causing the search to thrash and waste CPU and ops. If this is case I want to know if h triggers this behavior or the cost matrix.