Posts made by anisoptera

I like this idea. There's something to fight over in unowned rooms with this - you can't just retreat and recycle the creeps and wait for me to go away; if you do that, you'll lose a structure that cost a lot of CPU and energy to build.

Burning ops is neat too - give another use besides PCs for that resource.

I'm very happy about this change. It brings information into the game that was previously only in the UI. Even scanning the market and keeping history data yourself couldn't tell you volume and price paid.

There's also still value in scanning and keeping some of your own history, though, so anyone who already has that code isn't sad to have it.

Also, I'm looking forward to getting the million credits or so back for my legendary energy order on shard0.

Slack.

First, I'm not really a fan of the way the OP in this thread was worded. It seems clear you knew we have a Slack already, and went on to imply that it was just ridiculous that we don't use Discord. Well, we have a lot of reasons for using Slack, some good, some neutral, but mainly we already use Slack so you should have to give justification why we switch.

All new features start at -100 points. The entire community is on Slack right now - you want us all to move so you don't have to download a new app? The points in "favor" of Discord, apart from history (and history isn't exactly awesome on Discord) seem to be more like feature-parity. "Well, you can do $thing_you_like on Discord, too, except worse, with a bot, or a shitty interface (or both)." What are the advantages to moving? Because I don't see any. History is like +20 points, so you're still at -80.

I don't see why this is even a discussion. Slack has worked fine for years. We've had our share of malicious users - about one every couple months, from what I hear - and we just ban them. It hasn't been an issue. The user privileges on Discord are worse - you have to be a member of every public channel on the server, you can't create new public channels as a user, and if you want a channel that people aren't autojoined to (thinking of something like #exception-thrown on Slack) you have to write a bot to add/remove roles from people.

Finally, and in conclusion, Screeps is a land of contrasts.

No, but seriously, I do have one final point. There are many programming communities that use Slack - I'm a member of a couple of them. There are no programming communities that use Discord. Screeps is a game about programming. The sort of person that would play Screeps, but doesn't know how to use Slack and is unwilling to, seems like the kind of person that won't like Screeps for very long anyway. Or, if they do get into it, they'll learn to write code ... and then they'll probably join a slack community ... and now they have Slack open anyway.

Don't uproot an entire community (or stir everything up) because one guy is whining about having to open a second app. What the actual hell.

I wasn't able to renew it when I tried during the sale, mostly because I hit the window where credit cards weren't processing.

But also, I wanted to buy 6 months, and it looks like that's impossible because right now I'm on the 3-month plan. I didn't want to cancel the auto-renew and then forget to re-enable it. It'd be nice to be able to switch without having to go to a separate screen.

+1 for sub token bug bounties. I would write engine code for sub tokens.

@artch I mean, you wouldn't be forced to in the sense that you have to or you're crippled. But there would be resources that you'll get "for free" by taking the effort, similarly to how you can ignore memory segments, but if your code takes advantage of them, you get 10MB more memory "for free".

You don't get that additional CPU today at all; if you don't go intershard nothing changes. But if you are extremely high GCL, you'd get a little bonus if you do.

Do you think you'll ever let us have more than 300 CPU per-account?

Like, if the 300 CPU cap were made per-shard, and you continued to gain CPU from GCL after 27, that would be a cool compromise. Eventually we can have a few extra CPU levels that force us to become intershard to use them.

After discussion with doctorzuber I have to agree.

I've long lamented the fact that I can't write a 10cpu codebase, because of the rules against multi accounting. This would give me that chance: I'd be able to run a different codebase on a shard that I've only allocated 10CPU to, and bam, I get to enjoy that challenge.

Right now it's possible to do this to some extent through some require magic - but it would be nicer to be able to set a branch and upload to it, I think.

What he said

I was excited to jump in on day 1, but I think this is a better option for you. You get time to write the API, and breathing room for new players. Great plan.

I think we'd love a simple explanation of what's going on with the segment, like by what process it gets replicated between shards and how conflicts are reconciled, so we might better solve the coding challenge.

Whether you want to give us that, or leave it as a mystery for us to work out through experimentation, is totally up to you.

Thanks for listening to the feedback. I'm super excited about this feature now!

I would be fine with once a day (though as tedivm says I would prefer a _little_ more often than that). It's not like I need to do it very often, so most days I probably wouldn't change it. It'd be a strategic resource, kind of like safe mode. If I need more CPU in a shard because I'm under attack, and I reallocate, and then the enemy forks their attack to another shard that I pulled CPU from, tough cookies for me!

I don't agree with adding a resource requirement unless it is a requirement no matter how you call the API, though. Smells too much like an explicit advantage to manual play.

e: sounds like everyone else thinks that too. Cool, sounds good to me. 

@ags131: what @kotarou was asking is, if I send a creep over to the other shard, do I need CPU allocated there to be able to control it?

I can't imagine it working any other way. Which is my point. I can't send a creep through a portal I just discovered. I have to wait until my caretaker allocates CPU (or GCL) to that shard. And I don't have any way to know when that has happened (at least, no in-game method - of course my caretaker could have written some values to memory.)

Something I just thought of.

If our code doesn't know which shards have CPU allocated to them, how can my AI know which portals it should send creeps through? Should I just blindly send CLAIMers through portals hoping that my caretaker has allocated the appropriate amount of CPU to the other side? Am I (as the caretaker) supposed to manually poke values into memory indicating which shards I've allocated memory to?

Am I going to have to literally write an out of game tool that scrapes the web UI for CPU allocation, pokes the values into memory, and then occasionally reads some segment of memory and pushes the desired allocation back to the UI? Because it's impossible to stop that from happening, and sufficiently motivated players will build this tool - and now you've just done two things:

- Forced me to implement an out of game solution to an in-game problem

- Put this feature out of reach of people who aren't able or willing to do the same

To be clear, because I've been pretty hostile in this thread, I am blown away that you guys already have a working shard implementation at all. I'm just extremely frustrated that you are making it more difficult to write code that controls this programming game.

Honestly, imagine if the market had been released in the opposite state as it was. Instead of there being no user-facing UI to place orders, that's the only way that we can place orders. Code can only look at the orders on the market, in order to actually buy from an order you'd have to go to the UI.

After all, the market doesn't affect gameplay. Credits exist outside of gameplay, they're tied to your account. Having more or less credits doesn't affect your AI in any way, so it can't even see them. All your AI can do is look at the market and send you an email going "Hey, it'd be pretty cool if you bought X from this order", or "Hey, could you put up these excess resources as a sell order?"

We'd have called you insane, and rightly so. That obviously isn't what we want out of a game that's about automation.

That is exactly what is going on here.

> Shards resources (not just CPU, but also GCL, Power Levels, Pixels, etc) are entities of higher order than those that your scripts are operating with. Giving an ability to allocate shard resources using the game API is similar to providing an ability of, say, changing your badge or email via the API. It is related to your account and should be set up by user, not by user’s script through an in-game mechanic. The shard itself knows nothing about the multi-shard environment it exists in, similarly to how it knows nothing about other user metadata like emails.

I don't know how to say this less aggressively, so sorry for this, but: how can you be so wrong about your own game?

Let's start with this:

> Giving an ability to allocate shard resources using the game API is similar to providing an ability of, say, changing your badge or email via the API.

No. My code can't see my email or badge at all. They do not affect my code's gameplay in the least. No matter what my badge looks like, or my email is set to, it has no effect whatsoever on the game. Allocating shard resources heavily affects the game.

>  It is related to your account and should be set up by user, not by user’s script through an in-game mechanic. 

No, it is related to my AI. My AI already knows about the amount of CPU allocated to it (currently, 100%, of course) and its own GCL.

> The shard itself knows nothing about the multi-shard environment it exists in, similarly to how it knows nothing about other user metadata like emails.

The shard itself is the server I'm playing on. It's not my AI. After the shattering, my AI will be a distributed system. It will exist on multiple shards. Crucially, it will be able to communicate between those other instances of itself using the shared segment. From here it is utterly trivial to compile a list of the shards I am running on - all I need is for a list of shards to be in the segment, and every tick my AI reads the list, checks its own shard name, and if it's not on the list, adds that shard to the list. Now I have a list of shards I'm running on. I know quite a bit about the multi-shard environment I exist in.

I still don't know anything about emails, of course, because emails aren't related to the game in any way.

I also can learn about new shards that I'm not running on simply by scouting portals. And that brings me to my main point:

If you don't let us dynamically allocate CPU to different shards, then claiming a room on a new shard will always involve user intervention. If my code encounters a portal to a new shard, and it would like to expand across to the new shard, without an API the best my code can do is literally send me an email so I can log into a web UI and alter allocations. This is utterly ridiculous. It's completely against the spirit of this game. You have just caused emails to actually be a gameplay mechanic! My code has no way to get into a new shard without emailing me!

A similar argument applies to power creeps, of course, but this is even more ridiculous. You give me a single segment to write to and manage mutexes in, claiming that it makes your AI code more interesting - essentially handing me a distsys problem to solve on a platter - but then you decide that I shouldn't be able to manage the distributed system that is my AI programmatically? What?

I hope you reconsider. There is a significant difference between "Of course people who babysit the game will have an advantage, it's just a law of physics" and "We are specifically coding this in such a way that people who babysit the game will have an advantage because we will make it impossible to use this feature any other way."

I am with the people who got a massive performance boost from the change. I saw an 80% increase in number of processes my kernel runs per tick (and the lower priority processes are the ones which generally consume much more CPU)

I think a lot of the negative reactions stemmed from the surprise nature of this change. At the same time I'm very disappointed that we didn't have a long enough test to really see how things shook out. I understand that we have to do this on live server because we don't have any way to really test this against actual code that players are using, so I might suggest a different test methodology for the next iteration...

Declare a day to be an "alternate timeline" day. Back up the world state, then upgrade to node 8. Give everyone a free day sub extension (this is the most painful part, of course). Let it run for a day. Then roll back everything and ask everyone to weigh in.

I also feel like I am probably getting hard resets more often than I would expect, especially since I don't have a common history of soft resets.

> FYI anisoptera my interpretation is that the last to bullets in the main part are still not allowed. No multiboxing, no multi registration.

But Artem said:

> You can even register multiple accounts

Clarification on whether he was just talking about an internal process is probably a good thing to get, but, it sure sounds to me like multi registration is allowed.