Posts made by daboross

I can think of several things which wouldn't break with this?

• grabbing Creep.move with var x = Creep.prototype.move.
• grabbing Creep.moveTo with var x = Creep.prototype.moveTo.
• grabbing Creep.moveByPath with var x = Creep.prototype.moveByPath.
• calling c.moveTo() with any arguments
• replacing the Creep move prototype with Creep.prototype.move = x; and having creep movement use the new function
• replacing the Creep moveByPath prototype with Creep.prototype.moveByPath = x; and having creep movement use the new function
• replacing the Creep moveTo prototype with Creep.prototype.moveTo = x; and having creep movement use the new function

The only thing which would break, as far as I can tell, are:

• overwriting Creep.prototype.moveTo = x; and then expecting somePowerCreep.moveTo() to use the new creep moveTo function
• overwriting Creep.prototype.moveByPath = x; and then expecting somePowerCreep.moveByPath() to use the new Creep moveByPath function

Both of these things are breaking only to people who've written PowerCreep code in the time since they've been out, and both have the easily fixable solution of overwriting Moveable.moveTo / Moveable.moveByPath. There's no way this can affect idle users, even if they extensively use the prototype system.

@gankdalf said in Screeps Discord?:

Official Server

• general chat
• official announcements
• webhooks to main project
• FAQ static channel
• Guild/Alliance list static channel
• trading

Guild/Alliance Server

• private channels
• public channel for recruiting
• lots of custom channels

3rd Party Project Server

• support channels
• suggestions
• project github webhooks

If we had a structure like this, discord would make sense. However, Screeps by nature is not very alliance based, and "3rd party projects" account for over 80% of the traffic if that includes shared code relating to the game.

This is a game about programming, and slack's channel structure accommodates that. If we wanted to emphasize the "social network" aspect of the game, or alliances, maybe discord would work for that. But, at the moment, that's not what the community is about.

If we're talking about alternatives, and if at some point we decide slack's history is a killer (which it semi-is right now), I'd agree with SemperRabbit about https://riot.im/. Matrix has the advantages of IRC that @vrs and others have mentioned of being a free protocol, and with riot.im hosting we'd also have scrollback and other features slack provides over IRC.

The one I linked in the original post as an example. It has been admin hidden behind a spoiler warning though, so you will have to click that to see it now.

Ah, cool!

If it has effective channels which can be joined/left and created by users, that solves my main objection.

Side note: I'm going to head to sleep, but I'll be back tomorrow. Hope the discussion goes well till then.

@daboross said in Screeps Discord?:

In discord, these discussions wouldn't be able to exist outside of large all-encompassing channels.

Why exactly? Have you opened the template discord?

In most discord servers I've been in, there have been <10 channels. Any more than ~20 would be uneasonable to manage in the side-bar, with the layout they have.

I don't believe this discussions would exist because they require two or more people with specific, shared interests sharing a channel with low clutter. In #operatingsystems, people talk about implementing operating-system-style screeps AI, for example. However, there are 163 other of these channels, and I know at least ~15 of them are irregularly-active.

If any of those 15 channels were merged, it would be that much harder to find the people who are talking about things you're interested in talking about. I mean, I have 15 that I subscribe to and am interested in, but as previously mentioned there are a ton more out there. If you merge any two channels, you're going to have some people interested in one of them but not the other.

The other point I'd make is that a lot of these discussions happen over the course of hours, or days. In the sparsely-populated channels, people can talk back and forth without things happening in the meantime. If they were always active, this wouldn't be able to happen.

If you merge all 163 into the fewer than 20 that discord would allow, the discussions will be extremely diluted. It wouldn't be possible to find interesting discussions because:

• too many other, possibly uninteresting conversations will have happened between the ones one is interested in
• people who are having these discussions won't be able to meet and talk over a period of days, as they do in slack

Alright, hopefully that clarifies my argument for having tons of different channels. Slack isn't the best, still, because of history, but I find it better than discord's channel situation.

For the "template discord": could you clarify what you mean by this?

@cashewthecat said in Screeps Discord?:

This is probably more of an administration/maintenance thing, but I am part of about a dozen channels, and over the past week exactly 3 of them have had any activity. In several cases I was unsure of which channel to join (screepsmods vs mod-development), and some cases I just have no idea what the channel is for. Again, this isn't a problem specific to Slack.

Just for comparison, I'm a part of 45 channels. 7 of them (#python,#quorum,#screepsplus,#botarena,#cpu-clinic,#operatingsystems,#servers) have regular, active, relevant discussions. The other 38 irregularly have messages, but when they do they're always messages relevant to the topic. I don't see this inactivity as bad, though, it's just a way to get things which are interest when people find them.

One thing that annoyed me when I opened slack was that I was immediately told that I couldn't view the chat logs unless I paid.

Yep, this is definitely a pain. It works when you're only looking at ~24 hours of backlog, but we've gotten to the point that more than that disappears.

I'd mainly like to move to a platform where this is possible. In slack, it used to be, but paid restrictions stopped it. In discord, these discussions wouldn't be able to exist outside of large all-encompassing channels. I agree slack isn't ideal here, but it's better than Discord in terms of finding relevant discussions.

I think unification should be the primary goal, and platform features secondary. Whatever the decision, it should be approached aggressively (that is to say, if Discord is chosen, Slack should be archived and terminated).

Since we're currently unified on slack, I would argue this decision should be primarily feature-based. If its unification only we're looking for, we shouldn't even be considering starting or moving to another platform. However, if we agree on discord being better feature-wise and/or philosophically, aggressive archiving sounds good.

I'm curious about your objection of fragmentation of channels. What kind of topics are you unsure about? I've found most things I want to post or discuss fit well into at least one of the public channels, and slack's ability to have any number of specific channels ensures there's some place any single thing fits in.

I guess it does make broad discussions a bit arbitrary, but there's always #general for that.

If we were to go to discord, sure, we'd have clear channels to put things in. However, those clear channels would be necessarily limited in number, and we wouldn't get to keep track of interesting discussions which happen in side channels.

In slack, I can read the archives of #servers or #operatingsystems and see what people have been talking about specifically about those two things. If we were to limit ourselves to discord, with all channels being open by everyone, I don't think we could sustain the number of unique channels we have today.

https://abe-winter.github.io/plea's/help/2018/02/11/slack.html

This is definitely an interesting article on slack, and I'd be convinced not to use it in a workplace. This seems orthogonal to using it as a game-discussion server, though. We do suffer to an extent from the "search" drawback, but none of the others are relevant to an open discussion board unrelated to a workplace.

My main objection to discord is the lack of optional channels.

In the slack, we have 163 public channels, each with a different discussion topic. In discord, we'd either have to greatly pare down this number, or force everyone to have all 163 channels in their sidebar.

If that were fixed, I would be 100% happy with moving to discord.

Hi, an issue was brought to my attention recently where a player, Kritias, had an edge 10x10 area close "around" their rooms without any warning signs. This is the sector: https://screeps.com/a/#!/map/shard0?pos=95.5,-65.5.

I'm not sure if this is intentional, but it was my belief that all sectors closing, turning into novice zones and turning into respawn zones had system signs put up at least a few days before occurring.

In this case, there were no signs, and the sector was also in active contention (there was a battle between o4kapuk and Kritias occurring before the sector closed). Especially with active contention, closing without warning can give one side a major advantage: in this case, Kritias is now down many mining rooms, and o4kapuk has much more direct access to the more northern rooms through closed-sector portals.

My main intention in creating this post is to bring this issue to the attention of the developers, and to hopefully promote working warning signs on sectors which will close.

@artch Hmm, seems to work now - probably a nightly update?

I didn't see anything in the logs when it was failing before, it just didn't show up. This time the grey screen only showed for a few seconds before it loaded. But it works now, thanks!

Running well in Firefox here. It's broken in FF-nightly, but I imagine that will be fixed on the browser side. If anyone who has more webgl knowledge wants to debug it though...

@tedivm

I definitely agree with keeping the one-world aspect here, but unfortunately I'm not following on how having a base 10cpu will help this. Yes, it would incentivize people to colonize new shards, but only enough for each person to get their free extra 10 CPU. Turning being a multi-sharded empire into an obligation for anyone wanting to use all available resources isn't something I'd support. It would favor codebases which work in small, separate outposts, and giving extra resources to specificly-minded codebases would hurt the aspect of "play the game however you want".

With the battles/response you were mentioning earlier, I don't see how the shard API is a limiter here. One needs CPU to respond to battles in the same shard, why should it be different for inter-shard wars?

@Davaned

Isn't this what the new shard cpu API has?

Each shard has the 10,000 CPU bucket filled initially, so that if it runs it can request more CPU. This seems like more than enough, especially since you'll only need to be requesting more CPU from 0 CPU the first time you're running on the shard.

I would assume the first single creep will always have a relatively low CPU load? Using 5 cpu per tick, even with 2 500-CPU global resets, you'd have 1800 ticks to request more CPU and set things up.

> It can be used only once per day, thus manual usage is not much harder than scripted usage.

I like the once a day limit, but I have a large objection to this statement: this is not about ease of use.

If people wanted an easy game, there wouldn't be GCL1 players who are working on automatically placing buildings before they build remote mining. The appeal of this game, to many, is that a player can give themselves the challenge of doing _everything by script_.

I mean, the point of practically any game is to introduce challenge - that's what's interesting. For some screeps players, those who are newer to the game, to programming, or have less time, the challenge is simply getting a programmed AI to work at all. For the more experienced players, or those who have more time to play the game, the challenge is making an AI which operates and makes all decisions independently.

I think in your analysis of the situation, you are disregarding the second type of player. I'd count this as unwise - even though they do currently represent a minority, it's far more than 1%, and as more players become more experienced, the balance will continue to shift towards more and more players having full automation as the goal.

This is the reason there are so many players objecting to introducing the API after the feature. If you do this, you're essentially telling these players: either give up on the challenge, or you can't use this feature (shards). It's not about how easy it is, it's about allowing for this extra level of the game you created to exist. Letting people choose to challenge themselves more.

Once a day would be definitely fine for me!

I'd also be open to the UI either matching the limits, or not having them. We can assume someone calling via code knows what they want, and thus apply a limit to them. Via the UI could be a new player just experimenting though (if it isn't heavily warned against), and accidentally assign all their CPU to a shard they're not on.

Trying to think of a compromise here.

What would both sides think of a function `setCpuBalance({'shard0': 0.2, 'shard1': 0.8})` that's callable at most every 1000 ticks per server, and takes up to 50 ticks (on the slowest server) to 'activate'?

The timeout/delayed affect could significantly ease the burden of synchronization, and if it came into affect on servers where the limit was lowered *before* it came into affect on servers where the limit was raised, this could also avoid all abuse.

I would also think the delayed nature would set this function apart from regular game functions, and make it clear it's a "meta" capability, not to be used often.

Excellent idea!

One thing I would definitely want if this was added is at least 2 different tower 'strategies' for NPC towers, possibly more. These could either be random depending on the base, or different at different levels, but I think it would be good to have some variety in behaviors and layout so that it is harder to develop one-siqe-fits-all strategies which predict NPC movement and are more like mining SK rooms than raiding a hideout.

I believe that would also have serious implications in the server-side code. Right now, all objects available to the user at all are created beforehand, and used to populate an internal "register" as well as all the find caches / Game.structures / Game.spawns / etc. Game.getObjectById is literally a function `return _register[id];`.

If _all game objects_ were made available, this architecture would definitely have to change - creating one copy of every single game object per user per tick would be, well, very expensive. What the replacement would be, I don't know, but it would probably incur some additional performance costs, both with Game.getObjectById and other functions which use the internal register to validate things.

The solution I would favor would be something like Game.inspectPlayer(player) to get GCL and a list of rooms with RCLs next tick, usable once per tick, as well as a Game.inspectRoom(room) function giving RCL, controller sign, owner, and a 50x50 grid of enemy/road/wall/empty squares (similar to the view on the world map). inspectRoom would also be usable once per tick, and would give results the next tick.

Changing order price every single tick is only a 0.2 CPU per order per tick cost - it would be totally reasonable to manipulate the market using rapidly changing prices if there were no cost associated with creating a higher order (and increasing the prices of an order).

Getting enough credits to create a sell order is relatively easy selling energy and/or minerals to buy orders, I do not believe at all that this is a large barrier to entry. Creating an order selling 1 token for 2.5 million credits only costs 125k credits - while this isn't inconsequential, it is easily reachable through a bit of interaction with the market and selling 625k worth of your average mineral, around 17 harvests.

It's true that the market has some barrier to entry, but it's also true that that barrier is very crossable, and if you are willing to go a tiny bit under market value, fulfilling a buy order does not have any of these disadvantages.

Perhaps this could be done entirely client side - so visuals themselves would never be relayed to the client if they were published on a previous tick, but if the code published visuals every 15 ticks say, the client would retain any visuals received for that number? (specified in code)