New property is proposed: Room.eventLog. It is an array containing event items that describe most actions that have taken place in this room on the last tick:

[{
  type: EVENT_ATTACK,
  objectId: '54bff72ab32a10f73a57d017',
  data: {
    targetId: '54bff74fb32a10f73a57d018',
    attackType: 'attack',  // attack | rangedAttack | rangedMassAttack | dismantle | nuke
    damage: 20
  }
},
{
  type: EVENT_HEAL,
  objectId: '54bff72ab32a10f73a57d017',
  data: {
    targetId: '54bff72ab32a10f73a57d017',
    healed: 10
  }
},
{
  type: EVENT_HARVEST,
  objectId: '54bff72ab32a10f73a57d017',
  data: {
    targetId: '54bff74fb32a10f73a57d018',
    harvested: 50
  }
},
{
  type: EVENT_REPAIR,
  objectId: '54bff72ab32a10f73a57d017',
  data: {
    targetId: '54bff74fb32a10f73a57d018',
    repaired: 1000,
    energySpent: 10
  }
},
{
  type: EVENT_UPGRADE_CONTROLLER,
  objectId: '54bff72ab32a10f73a57d017',
  data: {
    targetId: '54bff74fb32a10f73a57d018',
    upgraded: 10,
    energySpent: 5
  }
},
{
  type: EVENT_TRANSFER,
  objectId: '54bff72ab32a10f73a57d017',
  data: {
    targetId: '54bff74fb32a10f73a57d018',
    resourceType: RESOURCE_ENERGY,
    amount: 200
  }
}]

Events last only one tick, so if you need to track event logs for a longer period, you have to store them on your own. Every room has its own Room.eventLog array. You can track events performed by a particular creep like this:

_.filter(creep.room.actionLog, {objectId: creep.id});

Or you can find all hostile actions against your creeps and structures:

_.forEach(Game.rooms, room => {
  let attackEvents = _.filter(room.eventLog, {type: EVENT_ATTACK});
  attackEvents.forEach(event => {
    let target = Game.getObjectById(event.targetId);
    if(target && target.my) {
      console.log(event);
    }
  });
});

Even when the creep object is gone (being killed or leaving the room), the attacking event is still recorded to the log, so you are able to reason on what's happened.

Not only hostile actions are recorded, but you can also use the events log to track effectiveness of your harvest, upgrade and repair operations.

Since these JSON arrays can become quite big, they are stored and fetched by the engine as raw strings, and deserialized using JSON.parse when you access the Room.eventLog property for the first time similar to Memory parsing. Thus, if you opt-in to use this feature, it will incur some CPU cost depending on the number of actions in this particular room in the given tick.

By default, no filtering is applied, but after calling this method, all other events are ommitted from the log(and thus also save cpu cycles server side when serializing it).

Parse times seem like they should be small. I'd guess <0.1 CPU for most late game rooms.

RMA is going to create a lot of events, but I guess it's rare so that's not going to be much of CPU hit in general.

The only other event I can think of is EVENT_DIE, but this maybe covered by the new tombstone functionality.

I would be happy to have a flag in EVENT_ATTACK to say whether or not the object was destroyed by the attack.

@stevetrov I mean, how do you get rid of storing and comparing in Memory, if you only have targetId in the event data, and Game.getObjectById(targetId) === null?

The difference with server side code is that it is already processing the intents that caused the damage.

Although thinking about it, IIRC destruction is not determined at the time damage is applied, its determined after the heal is applied. So an object EVENT_DESTROY would make more sense.

Is there a reason you cant create the EVENT_DESTORY object at the same time that you detect the creep / structure is dead server side?

{
  type: EVENT_DESTROYED,
  objectId: '54bff72ab32a10f73a57d017'
}

You have to store your structures info in Memory in order to do something useful with this objectId. But if you're storing your structures in memory already, it's trivial to check Game.structures[id], and it's easier than looking for EVENT_DESTROYED events every tick.

Ah i c your point now

How about:

{ type: EVENT_STRUCTURE_DESTROYED, objectId: '54bff72ab32a10f73a57d017' structureType: STRUCTURE_RAMPART, pos: { x :23, y: 35, roomName: "E1N1" } }

And for creeps we could have

{ type: EVENT_CREEP_DESTROYED, name: "MyAwesomeCreep", deathReason: <oldAge|suicide|murdered> }

The later would provide an alternative to comparing Game.creeps & Memory.creeps every tick.

would be enough for me. I don't care where it was destroyed, or what it used to be, but if an important structure goes down, I need to look at creating a new one and/or starting safe mode.

Keep in mind events are not user-specific, they are exposed to all users with an access to the given room in exactly the same form, so you cannot distinguish your creeps/structures from another player's this way. And we cannot add username property here for technical reasons.

Sounds like the EVENT_CREEP_DESTROYED functionality is covered by tombstones, so EVENT_STRUCTURE_DESTROYED should suffice and doesn't reveal any user specific information.

Sounds like the EVENT_CREEP_DESTROYED functionality is covered by tombstones, so EVENT_STRUCTURE_DESTROYED should suffice and doesn't reveal any user specific information

Which reminds me, It would be nice to have a pile of rubble for some ticks when a building is destroyed. This way you'd have tombstones for structures.

EVENT_STRUCTURE_DESTROYED seems overkill.
I think the event EVENT_ATTACK would cover most of the issues here. Maybe add destroyed: true|false could be added so you won't do a Game.getObjectById(data.targetId) and get null back.

There's no EVENT_MOVE in the example, is that also going to be an event

What about a EVENT_COLLISION @artch? This way when 2 creeps move to one location we can easily determine which one was the loser.

• On the plus side, it would be handy for solo structures being killed in remote room.
• But on the other side, reading events can give a lot of information without any risk (harvests, attacks, repairs, upgrades...). Which a good algorithm, you could probably know everything in the room (structures, positions, controller level, etc.).
• ... which is something you can see manually with the client anyway.

Any thoughts or decision ?