Posts made by Atavus

@artch @o4kapuk that was it! Thanks for the assist.

@artch

more interesting logs appear in processor:

Error processing room W9N6: TypeError: Cannot read property 'energy' of undefined
    at module.exports (/home/screeps/world/node_modules/@screeps/engine/dist/processor/intents/spawns/tick.js:51:87)
    at /home/screeps/world/node_modules/@screeps/engine/dist/processor.js:423:83
    at /home/screeps/world/node_modules/lodash/index.js:3073:15
    at baseForOwn (/home/screeps/world/node_modules/lodash/index.js:2046:14)
    at /home/screeps/world/node_modules/lodash/index.js:3043:18
    at Function.<anonymous> (/home/screeps/world/node_modules/lodash/index.js:3346:13)
    at /home/screeps/world/node_modules/@screeps/engine/dist/processor.js:410:11
    at _fulfilled (/home/screeps/world/node_modules/q/q.js:854:54)
    at /home/screeps/world/node_modules/q/q.js:883:30
    at Promise.promise.promiseDispatch (/home/screeps/world/node_modules/q/q.js:816:13)

@artch

Not much in there:

Loading mods from "/home/screeps/world/mods.json"
 - /home/screeps/world/node_modules/screepsmod-auth/index.js
 - /home/screeps/world/node_modules/screepsmod-mongo/index.js
 - /home/screeps/world/node_modules/screepsmod-admin-utils/index.js
 - /home/screeps/world/node_modules/screepsmod-features/index.js
Starting storage server
Storage listening on storage.sock

@o4kapuk so this is not a common occurrence?

I simply had v3 installed before and upgraded to v4.

The only other interesting thing is that I'm using an AWS EC2 A1 instance.

Dear Screeps,

Since updating to v4 of the screeps server, there seem to be some strange issues abound.

Receiving an error in the console:
TypeError: Cannot read property 'energy' of undefined
at makeGameObject (:17067:77)
at Object.init (:17239:49)
at :16435:22
at ()
at make (/home/screeps/world/node_modules/@screeps/driver/lib/runtime/make.js:142:34)
at processTicksAndRejections (internal/process/task_queues.js:93:5)

The world doesn't seem to have initialized correctly. Is this a known issue?

Here's how connecting via the client looks like:

Assistance would be welcome.

Kind regards,
Atavus

I think the correct approach is to take a step back and look at the original problem.

You wish to know that a room is in Novice/Respawn so you can use this information in pathfinding.

Why do you need to use this in pathfinding? Because those rooms are walled off.

But the question then is, how does your AI handle trying to go to a normal room that is behind other walled off rooms?

I get the feeling Novice/Respawn is just a more frequent instance of having an area blocked off by walls. You probably should teach your AI to handle that case in pathfinding logic and then you won't need the Novice/Respawn flag.

@duckymirror oh! That's an interesting suggestion.

I like that.

It would maintain the map as dynamic and would smooth out the advantage/disadvantage of being on the edge.

Just a throw-in, but be aware that for terminal transfer costs, the map already behaves this way.

Perhaps relevant for @keenathar.

Agreed.

There's been a fair number of ideas bouncing around, but we don't seem to be converging on a clear solution yet.

There's enough going on with all the other changes and initiatives.

I'm similar to wtfrank.

Each room has a centre position which is calculated once and cached. All structures are offset from that position. For me the cost to calculate this is not so expensive because of how simple(good) and inflexible(bad) the design is.

Normally I check a room only when it has gone up/down in RCL or the cache key(owned structure count) is invalid.

In practice, my architecture (name of the operation in charge of core structures) CPU costs are negligible, but my design is really basic.

To whom it may concern,

the next round of #botarena will start on 14th of September. This marks the one year anniversary since the tournament started.

Botarena is a championship for fully automated AIs. The console is disabled from start and, after the first 24h, code update is also disabled.

Further details can be read here: https://goo.gl/5hYJUQ.

To make this round extra interesting, the following prizes will be awarded:

• 1st place - 1 000k (aka 1m) credits
• 2nd place - 500k credits
• 3rd to 5th place - 100k credits

If you would like to participate or observe, you are welcome to join us on #botarena slack.

Regards,
Your inactive warlord
Atavus

PS: Anyone willing to write an article on the championship outcome will get a reward of up to 500k(depending on quality) from me.

Just to add some of my opinions to this discussion.

As others have mentioned, I feel power creeps are super creeps. That avenue is not worth exploring imho.

The idea of super structures has been proposed and discussed over time. I have a few comments, some high level and some on the specific proposed structures.

First, I'm not a big fan of super structures because they either centralize empires (if 1-2 structures of a type per player) and/or add another advantage to entrenched players.

I'm against centralized empires because it limits the style of play. Currently it is perfectly feasible to run a decentralized empire across multiple shards and locations. Once you add unique per empire structures, there's a need to build around that location to better protect it.

The other issue is that I'm in favor of veteran players having the advantage of better developed code bases (already a huge advantage), providing veterans with more and more options to "invest" their resources besides GCL and Power creates an ever wider rift between old and new.

Second, regarding some of the practical suggestions:

1. I'm strongly against teleport or similar structures. The "local" nature of the screeps world is an absolutely essential aspect of it. Portals and frog hopping already provide players with plenty of options to get to a specific locations if they wish to. We do not need extra mobility or power projection.

2. Temple. Why cancel out the current game challenge of bypassing the 15 cap? It's a good, healthy coding challenge for players.

3. Super terminal - centralizes empire (see above) - partially covered by power creeps already.

4. Missile silo. This one is funny. I personally treat my military creeps as missiles. It's not clear what "problem" this is attempting to solve and feels like a bitch to balance.

@Tigga I wouldn't call them boring. Perhaps we can term the subject under developed.

The game is definitely better for having them as is evidenced by this newbie's excitement.

It adds a nice layer to the world's individuality.

I do agree, that the concept can be developed further. I'm personally a fan of the NPC stronghold subject.

@oriet a long time ago, someone made a ui client hack that gave you buttons to literally order creeps around like an rts.

So technically the option is there.

Interesting. My vote is capping it at 125 per part.

This is definitely an interesting proposal.

There's also precedent with the upgrade and build boosts which both effectively create energy out of nothing.

I'd also mirror @Jacudibu and suggest that it should start with lower impact and be increased if it proves too low.

My personal opinion on boosts and economy is that boosts should be useful only in "niche" circumstances and not an omnipresent aspect. It should not be worth it to boost everything all the time. It should require your AI (or yourself) to decide in which cases it is warranted.

The extra energy from the harvest boost would come in handy when you're building up a new room and can benefit from extra local energy. I can see quite a number of tactics coming in handy from a harvest boost that increases the effective local energy.

Excellent proposal.

I must reinforce o4kapuk's point. I myself rely on carry boosts in a number of combat scenarios.

I use carry boosts for:

1. transports into (potentially quite far) forts deep into enemy territory
2. fully boosted wall builders in defense/siege scenarios
3. "thief" units to quickly drain a storage/terminal that has been exposed
4. micro transport units to save spawn time when the room of origin is scheduled to spawn a large offensive operation

Those scenarios are just off the top of my head. To be honest, on my personal list of boost rankings, carry is actually pretty far up. Harvest remains the most useless boost imho, followed by attack boost (not currently in my meta).

I'm with wtfrank on this one (doesn't happen that often ).

Sounds like you have some grievance with NPCs. Be aware that there's a lot of us vets out there who have been hunting NPCs. There's probably some around your area.

Just drop on slack and ask for help if you feel your circumstances are unfair.

The general consensus regarding NPCs has been that it should not be banned because the community self regulates. All you gotta do is reach out.

@wtfrank all good points. The issue was touched on briefly earlier in the thread.

Technically it's 600 squares (Claim lifetime was increased about a year ago).

I actually am not bothered by the case you describe where player A knocks down 100m and then player B comes in. In most PVP, it's called a kill steal. Of course, nothing is stopping player A from then hunting down player B.

You are correct that this is not an ideal metric, but it is a simple place to start and we won't be able to define or identify an ideal metric to measure warfare. You can spend the next year debating the "right" formula and creating exceptions on top of exceptions to cover every case and you will end up with something not usable. The advantage of this formula is that it builds into an easily identifiable and quantifiable mechanic of the game that is present now.

The fact that attacking controllers is currently a small subset of warfare does not mean it would remain so if such a ranking is introduced. It's likely that people would build various strategies around the limitation of creep claim. I can certainly imagine someone building a small forward base with the exclusive purpose of spawning necessary claim parts to stake their claim to killed rooms in an area. Warfare is likely to evolve around the established "reward".