I think you're misrepresenting their reasoning.

Screeps Inc thinks they can serve the communities desire for a flavored seasonal server better than ScreepsPlus can. They've been reluctant to try before now because of the effort involved. An official clone of the ScreepsPlus seasonal server wouldn't really be worth it (and possibly risky optics). If they're going to compete with ScreepsPlus's seasonal server they need to make it better. They've defined better as resurrecting the World Review and adding seasonal flavors. They're checking with the community if they're OK with this. Would you pay for a better version of ScreepsPlus's season server?

They've been very consistent in their view on the CPU subs. You buy screeps to get access to the client which gives you access to private servers. If the community 3d clients every stabilize you wouldn't even need to do that. The CPU sub is the player paying for time on the Screeps servers whether that MMO or whatever. However Screeps Arena pricing plays out we will not need another CPU sub.

I think this confusion is partially why they're considering a Screeps Seasonal product. To help everyone grok that we buy the games and server time separately.

My feelings:

ScreepsPlus doesn't do flavors. We totally could. Custom leader boards aren't that hard. We could launch a World Review on ScreepsPlus. But we haven't. Would you bump up ScreepsPlus's patreon a bit if AGS agreed to do these things?

My hopes:

I'd like Screeps to offer services that don't make sense for the entire community but would work at a premium tier. Nickel and Dimeing? Kinda, but kinda ala cart. I'd love an official Logging and Monitoring feature, but few others do.

I'd also hope that Screeps Seasonal would add deeper changes or custom API tweaks eventually. ScreepsPlus could alter constants, or crank up the invader rate, etc. But I'd love something like all Swamps are lava and damage creeps and structures. Or a new FLY bodypart. These would be really hard to do well with mods on ScreepsPlus.

@DroidFreak I've have code to claimed rooms to avoid the upkeep of reserving them. I did it early on, but disabled it due to notification spam. I did it again a year later thinking the spam wasn't that bad. It was.

I have implement this feature twice and disabled it twice due to the notification spam.

@o4kapuk, You're correct. JPS is only for uniform cost grids and is fairly well researched. I've never found a paper about our odd A*/JPS combo.

Was the documentation incorrect or did you change the default heuristicWeight to 1?

While looking for original Heurisitic weight I figured out why heuristicWeight values above 10 act funny. They're capped at 9 in the code. We should update the documentation. (Or remove the cap if it isn't needed).

Most conveyor proposals would kill the processor but you've got something that works, it's intent balanced.

Some considerations:

• Make them decay so that they require energy upkeep. Don't make it obviously more energy efficient to use belts, only different.
• Allow them to also drop resources in a direction and use resources under them. Then it'd be possible to convey a resource without it decaying across a chain of belts.

The belts vs bots works great in Factorio. It might add richness to Screeps as well. Especially if they create a visual artifacts in the map view.

Something like this could easily be mocked up as custom structure on a private server. The difficulty is people would have to build code take advantage of it, (in my case it would enable some interesting base designs), so it might see little adoption until it got accepted into the core Game.

The purist in me wants: invaderGoal = C.INVADERS_ENERGY_GOAL * Math.max(0.35, Math.min(2, 1 + cdf(Math.random())));

A nice normal distribution mean at 100K between 35K and 200K.

Add a title to your post.

The creep being called may have been created via let c = new Creep() or c.id = "something falsey" or you've totally borked up a prototype somewhere.

Object.getOwnPropertyDescriptor might be able to help if it's a prototype problem.

We still need a PathFinder.search specific write up.

Some tidbits I've encountered over time:

• It's not really A*, but jump point search.
  • what does that mean? I don't know, but I blame it every time it has unexpected behavior
• The default heuristic of 1.2 finds non-optimal paths
  • 1 guarantees optimal but costs 50% more cpu.
• Heuristic values above 10 or so screw with the algorithm and searches cost a lot more ops (though not a lot more CPU).
• It will never produce a path that moves laterally on an exit tile
  • this is works well with exit tile teleportation
  • this interacts badly if you're movement constrained and on an exit tile. E.g you try to path a few tiles laterally will consume all ops and still produce an incomplete path.

I'm not on shard3 but want to break it for fun. I can't read your public segments from remote shards could you provide an example INFO segment or two?

As for improving the protocol, I think your protocol would be better if you made more use of Game.market.incomingTransactions and StructureTerminal.send descriptions. This comm channel is limited to 100 characters but it's private. Then you'd only need to use the public segments for large form data like sharing room intel.

You'd still be left with the interesting problem of securing a public segment for use by your allies only.