Posts made by eduter

I'm relieved to see everything is back Not only the channels, I save a lot of snippets and notes on DMs to myself.

@tehfiend I just tried this in the console and it worked fine:

'<span style="background-color:red;color:yellow">foo</span>'

Don't know about emails, though. I never tried to style the notifications.

@tehfiend if you're already using HTML, can't you just set the background color yourself?

While on the subject of unwanted emails... I think it's safe to assume that people don't want emails about their typos in the console.

1 notification received on shard1:
	

SyntaxError: Unexpected token .
    at _console1599257464959_0:1:51
    at _console1599257464959_0:1:60
    at Object.exports.evalCode (<runtime>:15550:71)
    at Object.exports.run (<runtime>:31737:41)

Go to the game

Hasn't that always been the case? I found my commit where I added ticksToLive === undefined ? CREEP_LIFE_TIME : ticksToLive to my bot (exactly because it's undefined on the first tick) and it's from September 2017.

What you described sounds like ZeSwarm, an open source bot that basically just harasses its neighbors, but I'm not sure if that was the case. Getting wiped by other players happens. Possibly many times, in the beginning. It happens even if your neighbors are newbies, writing their code from scratch. All it takes is them focusing more on combat than you. When the novice zone walls drop, there's also a good chance of you getting wiped by much stronger players. But that's ok, you lose you current room(s), but you keep your GCL and, more importantly, you keep your code. Just find another place to spawn and keep working on your code. You can also try to message your neighbors / possible neighbors and ask if it's ok if you spawn close to them. There are many peaceful players out there and even aggressive players that will leave a novice alone, if asked to.

As a workaround, you could create a filter for emails from noreply@screeps.com containing "Upgrade it to prevent losing of this room." or something like that.

@tigga said in Encouraging more combat at high GCL:

I don't believe that any of the changes I've suggested would effect combat at the "basic" level.

Since it would be a special shard, geared towards combat, it could have other differences, things that you would classify as "things that would make the game better from a fresh start", but would piss off a lot of people.

I don't much care for the idea of a new shard as I think we've got enough space as it is.

I think this shard should be much much smaller than the others, so it wouldn't add much space. I also think it should not allow spawning in it and maybe even having restrictions about which creeps can cross (e.g. crossing creeps lose 4000 hits) or having some boosted portal keepers, so you have to earn your place in it. Or maybe portals to it would be short lived and only appear among ruins of Lv 5 strongholds.

Really I just think it's a bit too easy to make an inpenitrable room on the main server right now, and I feel the main server shouldn't be as stale as it is, especially compared to days of old.

Personally, I like the MMO better now, more peaceful.

From time to time, the subject of how to stimulate more PvP combat in MMO comes up, mostly by the same group of players. But, whether this should be a goal is rarely (never?) questioned. Screeps calls itself an "MMO sandbox game for programmers", not a war game. While having more PvP combat would certainly make the game more fun to some, not everybody is interested in more combat. Some people have fun focusing on economy, market, advanced path finding, behavior trees, over engineered operating system architecture, etc. Others would like to get to combat at some point, but are still struggling with the basics. All those players would find the game less fun, if they saw themselves forced to defend themselves all the time, or if they kept getting wiped by big players and couldn't find a quiet place in the MMO for their ant farm, while they work on their code. Maybe the problem is when players who want a good fight, are surrounded by peaceful players, and when peaceful players have aggressive neighbors. What if there was a smaller shard with modifications to stimulate combat and make turtling less effective, with one-way portals coming from other shards? Only people who are interested in combat would claim rooms in that shard. If the promise of good fights is not enough to attract people, there could be modifications that make that shard more inviting. Faster ticks? More resources? Some sort of exclusive rank? Some or all of Tigga's suggestions could be implemented there. Even a cap on total owned rooms (without limiting allocated CPU) could be in place.

When I try to login, it redirects me to http://localhost:8083/api/auth/github/callback?code=...

I think it stopped working after the migration of the production server cluster.

Example for tombstones taken from the docs:

room.find(FIND_TOMBSTONES).forEach(tombstone => {
    if(tombstone.creep.my) {
        console.log(`My creep died with ID=${tombstone.creep.id} ` +
             `and role=${Memory.creeps[tombstone.creep.name].role}`);
    }
});

How I think ruins should look like, for consistency and to make it easier to detect what was destroyed (for rebuilding or clearing relevant cached values):

room.find(FIND_RUINS).forEach(ruin => {
    if(ruin.structure.my) {
        console.log(`My ${ruin.structure.structureType} with ID=${ruin.structure.id} was destroyed`);
    }
});

Cool! Rooms with invisible cloaking. At https://screeps.com/a/#!/history/shard2/W1N31?t=15714625 the invisible cloaking is still on, then on the next tick, it is off.

I like the idea of a unified way of withdrawing / transferring resources, specially with getters that return 0 instead of undefined. I already have something like that in my code. I would have to keep it, though, since mine also supports pickup and drop. I'm not sure this change would benefit me specifically, but I see its value for general purpose code. The only things I don't like about this proposal are including nuker into this, which seems like a stretch and doesn't really add any value, and deprecating the old API. Forcing everybody to change their code, making it slightly more convoluted or it will eventually break, will just make people angry. I see no benefit in that. Keep both and everybody is happy.

I think it would be great to have a map visuals API. Since there isn't one yet, to be able to see the intel my scouts collect, I created this: https://github.com/eduter/render-intel-map

It has 3 out of the box and 2 and 5 would not be difficult to implement, using the callbacks. 1 and 4 would be more difficult, because everything is, currently, rendered per room and those would require visuals starting in one room and ending in another. A PR to fix that would be welcome

@slowmotionghost said in Workflow tips and prioritization for new players?:

I think processing as many resources as your cpu will allow is the best route to growth.

To grow as fast as possible, absolutely. I went for simplicity and low maintenance.

I would be interested if your solution improves as your GCL goes up. It may be that having as many rooms as possible is the most efficient solution so at some point neglecting remotes may be a suitable sacrifice.

Based on my current CPU usage and the assumption that it would scale linearly on the number of rooms, if I had GCL 115 and managed to claim 115 2-sourced rooms, I would be the 1st in the expansion rank. It would take ages for that to happen, though.

@orlet said in Workflow tips and prioritization for new players?:

@eduter I only have 12 rooms, and 11 out of those are at RCL8, so effectively capped at 15e/tick. There's no much way to get past that outside of boosting, and I don't boost RCL8 rooms, it's too expensive.

33 of my rooms are RCL 8 and I don't use boosting either, I just transfer energy to an RCL 6-7 room. I get an average of 16 CP/ tick / room.

But compare the energy harvested numbers, and how much I spend on repairs.

You're using more rooms than I am and harvesting more energy than me and yet, you only get around 1/3 of the control points I get. From my perspective (from how I decided to play Screeps), that's just inefficient. But we're clearly playing in very different ways and with different goals.

My point was only that, for someone creating a fully automated bot, starting from scratch, I wouldn't recommend prioritizing remote mining. They may complicate things and you can do well without them for a long time. Harvesting and hauling is trivial, but automating the defense of remotes and, more specifically, the decision of when to give up on a remote, is a complex problem. The best fully automated bots I've seen, struggle with that.

@orlet looking at your stats for the last 7 days, you've been making ~334K Control Points / GCL / day, while I'm making ~371K. So, I'm making ~11% more than you per GCL, without remotes. Maybe you're focusing on things other than GCL, I don't know. I like to pick one metric and optimize for it. The metric I picked is control points / room used. This way, my bot has a relatively low footprint, so it doesn't become a bad neighbor. Conflicts are expensive.

@deft-code I don't track CPU usage, but watching the CPU indicator in the UI for a while, I think my average must be between 80 and 90.

My bot was always fully automated and I never saw any use for flags, I just use Memory. Its first version only built 5 extensions close to the spawn, mined and upgraded the controller. I'm GCL 35 now and I never did remote mining, nor I intend to. This reduces complexity a lot and you never need to worry about CPU. I highly recommend that you join the next edition of the bot arena. It doesn't matter if your bot doesn't do much and doesn't last long. It's a nice way to benchmark it against other automated bots and get a lot of insights in a short amount of time. Also, you'll see how much headache and inefficiency fighting for remotes adds. One thing I regret is spending too much time with only one owned room, because I had no subscription and didn't want to run into CPU problems. I ended up with some code that was hard to adapt to multiple rooms. One last recommendation is to use sim room to test what you can (speciality auto layout) and a local private server for the rest. In the sim room, you can easily edit the terrain and instantly see how your layout adapts, using room visuals. The private server is not as convenient, but you can directly change the database to create the scenarios you want to test and save a snapshot, by simply copying a file. I don't see a benefit in having it running at all times, so I start it, test what I want, stop it, debug my code, restore snapshot, and repeat.

I agree that that page is not very clear and that are things that I'd expect to find there, but aren't there (like resolution of conflicting move, withdraw and transfer intents). Some of your questions are answered there, if you read very carefully. That diagram shows dependencies between actions, if an action is not there (like move) , it's independent from the others. I find the last line misleading, but if you read the text that follows, it explains (sort of) that, unlike the other lines, a creep can perform one action from each box in it, as long as it carries enough energy for all of them. It will perform the actions, from right to left, until it runs out of energy. AFAIK, the order in which you add the intents doesn't affect how they get resolved (aside from calling the same method for the same creep, which actually just overrides the previous intent).