Posts made by ags131

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)

I also want to say: Thank you! CPU usage is much more stable and predictable, hopefully this is also helping server side too. Looking forward to being able to push it up to S+ once it leaves beta

Syncing the server to steam cloud might not work so well, you could sync db.json, but beyond that it could have issues. However, you can also host the server on a vm or cloud provider to have a central place for it.

I've actually had a system like this working at one point, except it was using TCP rather than stdio, it would be a massive project to properly sandbox it, likely requiring containers for each user, which would be difficult to manage automatically. As @artch mentioned, CodingGaming is a completely different setup, they do a onetime container for each run, and unlike screeps, its not time sensitive so doesn't have to respond as quickly.

@stevetrov EVENT_CREEP_DESTROYED is already easy, tombstones already provide that information.

@w4rl0ck Mobile app support is definitely important, I have both discord and slack on my phone, although slack is far easier to use on mobile for me.

I would probably end up creating a slack just for ScreepsPlus and possibly stuff like #screepsmods, many of us use the github integration to watch for updates for mods, tools, even the private server itself.

ScreepsPlus also uses a slack webhook to offer Grafana alerts through slack, usually via a direct DM to a player or private channel, discord would make that impractical even with their webhook support.

I agree with @daboross on his posts, trimming the channels down to the amount viable for discord would not be pleasant. I keep #general muted and rarely poke in because of the sheer number of messages all the time. I'm in a few discord servers, but rarely bother trying to participate due to way too much traffic. I don't have time to scroll through every channel to find out if anything is relevent when those channels have activity all day. In slack, the channels being spread out makes it much easier. I can see at a glance if I need to check in on something, for example, if #screepsplus or #screepsplus-support has unread, I will check them first to make sure theres no issues, others like #botarena or #swc I may ignore depending on if I'm busy or not. With discord this becomes much more annoying since so many conversations would end up merged.

I for one, would be much less active if we did move to discord, as others have mentioned they do, I work as a programmer, so have slack open anyway, during slow periods I'll check slack and chime in. I'm also afraid that if we did goto discord, it would end up fragmenting portions of the community, as alliances would be forced to create their own discord/slack/whatever server.

I also agree with @Knightshade here,

We're considering only two options. Seriously. We're taking a considerable hit to organization, group unity, etc. by moving regardless. The last thing I want is six months after a discord move to start hearing people talk about how ... is so much better and we need to move to that instead.

if we are considering moving, we should also consider and evaluate other platforms too, rather than just debating slack vs discord. (I know there are several slack clones out there, don't recall their names though)

I had a similar issue a few days ago, autopayment failed and no notification or emails were received. I caught it before my empire could suffer from low CPU, but its still annoying.

@artch Game.shard is undefined again in PTR.

@artch Ah, I completely forgot about that line