@Gankdalf Nice idea.

This is why I loved playing Dawn of War 2 over other RTS'es online. You had to hold strategic points, not build the biggest base.

The issue as always is how do you stop a single high GCL player from hoarding all the Obelisks around them? Some players are spread across multiple sectors and would most likely have multiple obelisks that other players can't attack.

One solution might be to add a CPU cost to having an obelisk. Maybe a creep needs to be constantly at range 1 and running a crypto mining style system. The longer you mine the obelisk the more CPU it costs. The cost would decay over time and be stored for each player. With this, a single high GCL player would be unable to constantly maintain the advantage from all obelisks at the same time but could for a burst.

Nice

Is Tombstone.creep a full creep? I remember reading its basically name, my and id?

Also, the constants are missing from the ptr docs. What are their values (I'm working on the typescript typings for these)

@ags131 said in Auth Tokens:

@arcath node-screeps-api also optionally uses a token directly skipping the /api/auth/signin step. gulp-screeps has already been updated to use a token if supplied.

I'm using tokens if one is supplied and it requires you use a token for screeps.com

It was mentioned by @dissi-mark on slack that grunt-screeps didn't have a rate limit. From looking at grunt-screeps source it appears that POST /api/user/code takes an auth header that isn't rate limited? I'd like to know if this is the case so I can change rollup-plugin-screeps back to requiring a username/password to use that header.

I've had a confusing discussion on Slack around the rate limit on POST /api/user/code.

I updated rollup-plugin-screeps to require a token when pushing to screeps.com which causes its deploys to be rate-limited to 10 per hour.

I've been told that grunt-screeps doesn't get rate limited, but when looking at the code I thought it was because it is still using username/password authentication (https://github.com/screeps/grunt-screeps/blob/master/tasks/screeps.js#L61). Is it not going to need updating?

Unlike node-screeps-api which uses /api/auth/signin to get a token and then uses that token to push code it appears that grunt-screeps uses an auth header to send email:password. Is the header going to stay and not be rate limited?

@postcrafter said in Creep death: more than just a delete:

Should the tombstone be created for creeps that die of old age as well? I think it should and contain the resources the creep was carrying.

That makes sense, maybe it the tombstones lifetime should depend on the creeps TTL at time of death.

Should creeps that suicide() create a tomstone? Maybe add this as an optional parameter (true/false)?

I think suicide() and recycle() should stay as is. Some players move creeps to die on a specific RoomPoisition where they expect resources to drop into a container etc...

Should I add a FIND_TOMBSTONES contant as well? Are there any other ways of how to access tombstones?

FIND_TOMBSTONES would be a good idea. Are they going to show up for FIND_STRUCTURES etc... as well?

Should this replace the current dropToContainer mechanic NPCs have? I think it should but it might break some peoples NPC raids or make them a lot less profitable until adjusting their code to tombstones.

Would make sense. Best to be consistent.

Should room owners be able to remove()/destroy() tombstones before their ticksToDecay reached 0?

If they do the tombstone would need to drop any resources it was holding.

Should it be a creep action? That way a defender can't rip them up the instant they appear.

Should they decay instantly if they reach 0 stored resources?

@artch said in Creep death: more than just a delete:

• No active actions.

What is this supposed to mean? No creep actions against tombstones? I previously thought about allowing Creep#withdraw (see NPC containers above), but this got me thinking. If withdraw isn't allowed it just delays resource decay, does it?

I'd say that like a container the tombstone would have no actions that it can perform.

Its 20 Rooms to the nearest open space so I'd need to do that twice.

This would make inter-shard play something that only players near the middle can do.

I've got a claimer to the nearest room in the next block of 4 but it still faces the same problem as described here: https://screeps.com/forum/topic/2040/shard2-and-future-claimed-corner-rooms

I think something needs to be done regarding inter-shard players getting stuck in the outlying areas.

I claimed a room through an intershard portal to shard2. Since then I've been building it up and am pretty happy with it but it has been quite a while and it's still a lone corner room around the portal.

I've been waiting patiently for the rooms around it to become available with nothing happening.

My big fear now is that those rooms are going to get blocked off in a newbie or worse a respawn zone leaving me stuck outside. If that happens I will lose the energy war and most likely the room.

I have no opportunity to stop this from happening, whereas if a new newbie/respawn zone opened up on shard1/0 I would have a chance to reserve my rooms before it appeared.

This is only a problem for us inter-shard travellers who appear in the far corners of the map.

My solution to this would be to open up the rooms in the same quarter as a travellers claimed room after it has been claimed for X ticks or reached X RCL. I Would add the caveats that:

• This only happens once per player per shard
• Only players who have rooms on another shard can trigger it

This would mean that I at least stood a chance against the respawn area players.

I've never had that much luck.

I use Teamviewer to control my PC from my phone.

I would love to have a screeps viewer app.

If extensions are built whilst you are watching the room it stays at the black circle instead of showing how much energy it has in it.