Another alternative is to use the API, set a password using authmod https://server.screepspl.us/web has a change password page, as does any other server running screepsmod-auth and screepsmod-admin-utils.

Then a simple script like this should set the badge (place in empty folder, npm install screeps-api, then run)

const { ScreepsAPI } = require('screeps-api')
ScreepsAPI.fromConfig('splus1').then(async api => {
  const ret = await api.raw.user.badge({ type: 24, color1: '#ff0000', color2: '#ffb400', color3: '#ff6a27', param: 0, flip: false })
  if (ret.ok) console.log('Badge Set')
})

So, two things on this one, first, it looks like the screeps backend-local module hasn't been merged to master and published yet, so system.setTickDuration doesn't exist in the CLI. Second, screepsmod-admin-utils has the wrong help text in it, I'll poke at it tomorrow and fix that text.

As a workaround, for now, you can force an older version of screepsmod-admin-utils to get the tick rate function back.

if using screeps-launcher just add this to your config.yml (keep it in the mods list too)

extraPackages:
  screepsmod-admin-utils: '^1.13.0'

or if using npm directly: npm install --save screepsmod-admin-utils@^1.13.0

I'm having this issue with an uptodate Arch Linux install. I get the error: (nw:1310757): Pango-ERROR **: 15:24:53.582: Harfbuzz version too old (1.4.2)

It appears that newer pango versions have broken it, Plexamp has the same issue: https://forums.plex.tv/t/plexamp-linux-crash-on-launch/444951/38

The current fix seems to be downgrade pango (Not ideal IMO as it breaks other apps like Thunar)

@wtfrank This is now fixed in the latest screepsmod-mongo build, I just deployed it to both S+ servers and confirmed it working

As both a mod developer and player I'm exited about this update, for modding, it was always annoying not being able to iterate over resources in a simple way. As a player, the entire store/carry/energyCapacity/carryCapacity mess was annoying, in some cases, I actually wrapped all those to make them match, very similar to how this is designed. It might seem a bit more clunky for stuff with only one resource, but simplifies more than enough other code to make it worth it.

For those wanting to keep energy/energyCapacity, they can easily do a simple prototype extension in their code. Object.defineProperty(StructureExtension.prototype, 'energy', { get() { return this.store.energy } }) Object.defineProperty(StructureExtension.prototype, 'energyCapacity', { get() { return this.store.capacity } })

There actually is a filter option for that, while it does mention the lodash.filter method, IIRC, its cached and faster. https://docs.screeps.com/api/#Game.market.getAllOrders

I've only quickly looked at it this morning, but the new planner seems much simpler and easier to understand than the old. I do agree with @Gankdalf though, the level lock should probably be more visible than the tiny lock icon.

I don't like the idea of having to pay extra CPU, even if its a small amount, for a feature I won't need or use, an option to disable the 'feature' would be nice. The cost would be much larger if you store many keys in Memory vs if you had few keys. I would likely end up implementing my own parsing just to avoid it.

I'm also curious why the PR was rejected, citing it being an internal property gives us no context or reason on why it couldn't be exposed other than it that it wasn't the intended purpose. I'm not objecting to the PR being closed, in the end, you the devs decide whether stuff gets merged in. We would just like to hear reasons and possibly be able to discuss why they shouldn't be accepted so we can better understand the direction to go with future PRs.

I'm occasionally consulted before some PRs, and usually try to considered a few things before answering, such as what pros and cons are there to them? For this one its fairly simple:

Pros:

• It doesn't break compatibility with anything else either as far as I can tell. It doesn't seem to have any effects other than not submitting a result when processed
• It wouldn't effect the current client at all, hidden would be optional and default to false, thus requiring nothing be updated.
• It gives API users the option of suppressing the empty results in the console, which means people making their own control panels and such can have macros or buttons to trigger console commands without spamming the console with usually empty results.

Cons:

• None, other than requiring what is likely a one line update to your internal backend

Since PTR is still on an older version, it may still have the bug where Tombstone.creep.toString() throws the error too, if you are using console.log or something on Tombstone.creep that can trigger this (This is already fixed in later versions)