Creep death: more than just a delete

artch

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.

Yes.

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

Always create.

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

Yes, FIND_TOMBSTONES and LOOK_TOMBSTONES.

Should this replace the current dropToContainer mechanic NPCs have?

Yes, it should, but I will do it myself.

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

No.

If multiple creeps die at the same RoomPosition, should there be multiple tombstones, one for each creep?

Exactly.

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?

It means Tombstone prototype doesn't have any methods and cannot generate intents. Creep.withdraw against a tombstone is allowed, of course.

Arcath

@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.

artch

@arcath

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...

If a creep dies on a spot with a container, then resources go to the container, and the tombstone is created with empty store.

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

No, tombstones aren't structures.

Should they decay instantly if they reach 0 stored resources?

No.

Hiryus

Should resources in tombstones decay like when on the ground ?

PostCrafter

@hiryus To my understand only the tombstone decays and drops the resources on the ground afterwards, then they'll decay normally.

Hiryus

That's what I understand too. But I raise the question for game balance as resources will now decay slower. In my opinion, the proposed change is fine.

W4rl0ck

so who is designing the nicest tombstone svg ?

Davaned

@artch Excellent, I'm really glad you agree. Very excited to see it appear. The creepId field will be great. Eventually having a kill credit/actions leading to death will be a huge boon but this definitely helps as is.

@PostCrafter Thanks for picking this up! Go get them sub tokens Mind linking your PR here when its ready?

ags131

First part of PRs for Tombstones! https://github.com/screeps/engine/pull/74

Davaned

@artch We should consider adding a .remove() for tombstones (and construction sites). It might be important to allow people to deny vision, and adding a .remove() for cosntruction sites would prevent the extractor site issues.

ags131

ags131

A thought I had, can I add creep name also? On my codebases I don't save creep IDs and instead use names, it would be easier to say, lookup the creep's memory with a name than it would with a non-existant ID.

shedletsky

@artch

It would be awesome to add a killerCreepId and killerCreepOwner field to the tombstone as well.

Tracking this right now is fairly tricky.

W4rl0ck

Not sure if it should be possible to control (remove) tombstones in any way.

As for the visual it could be some icon that does not makes it possible to use it to hide stuff. Maybe it could be a bit colored depending if it was a own or a hostile creep and look different depending if it's empty or not

ags131

Hiryus: Is it possible to add something like killerId for the creep/tower which did the last blow (or all creeps/tower having attacked it the tick it died) ? It is probably hard to do, but I'm asking :).

artch: No, it's out of scope of this functionality. Tracking actions is a whole another story.

@shedletsky Its outside the scope of this feature, tracking something like that in the server is almost as tricky too, maybe in the future though!

MrFaul

Would it be eventually possible to add a hook to the attack function wich returns for example KILL_DAMAGE instead of simply OK? Should be greater than Zero so you could change your code to >= 0 for any successful operation.

This would still not be very precise but a start.

artch

@ags131 Makes sense, let's instead make a tombstone.creep property as a Creep instance which is a stub created similarly to here but without adding to Game.creeps. In order to reconstruct this object, you have to store some creep's properties to the tombstone DB object when it gets killed.

On a sidenote, please take note here, is it implemented?

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

If a creep dies on a spot with a container, then resources go to the container, and the tombstone is created with empty store.

ags131

@ags131 Makes sense, let's instead make a tombstone.creep property as a Creep instance which is a stub created similarly to here but without adding to Game.creeps. In order to reconstruct this object, you have to store some creep's properties to the tombstone DB object when it gets killed.

Added

If a creep dies on a spot with a container, then resources go to the container, and the tombstone is created with empty store.

Is in now.

Hiryus

As they provide vision, should we also add Game.tombestones like for structures and creeps ?

artch

@ags131's pull request got merged to the PTR branch, and he receives 5 Subscription Tokens. Thanks for contribution!