Draft: room event log

SteveTrov

My use case for this would be to be able to do something specific when a structure is destroyed, such as trigger safe mode or add a new construction site to replace the destroyed structure.

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

artch

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

SteveTrov

@artch said in Draft: room event log:

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

artch

@stevetrov You don't seem to get the point. I don't mean server-side logic, it's trivial. My point is that this event would look like this:

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

SteveTrov

@artch said in Draft: room event log:

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.

artch

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.

ags131

@stevetrov EVENT_CREEP_DESTROYED is already easy, tombstones already provide that information.

Gankdalf

{
   type: EVENT_DESTROYED,
   structureType: STRUCTURE_SPAWN
}

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.

SteveTrov

@artch said in Draft: room event log:

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.

artch

@stevetrov Although, some rare use cases are still possible, when there are leftovers of another player's structures, and their destruction will likewise trigger these events.

Dissi

@stevetrov said in Draft: room event log:

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.

Dissi

@tigga said in Draft: room event log:

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.

Hiryus

Do you need room vision to access the logs ?

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 ?

W4rl0ck

@hiryus said in Draft: room event log:

Do you need room vision to access the logs ?

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 ?

vision will be necessary... the server has to prepare the data it sends to your program before your code starts.

artch

@dissi Looks too difficult to me, since collisions may be very complex involving more than 2 creeps.

artch

@hiryus Yes, vision is required as usual, since it's a regular property on Room.prototype.

UnFleshedOne

To support move events and other expensive ones, would it make sense technically to provide each user their own logs based on which events were requested on the previous tick. Will be slower than giving each client the same data, but you can charge CPU back to the client, since client can chose not to request data and not be charged?

artch

@unfleshedone It will create a lot more burden on processors, and it can be barely translated to runtime CPU, so it doesn't seem reasonable.

Rurik

It doesn't look like this needs any more support than it already has, but I really like this feature idea. The EVENT_EXIT and especially EVENT_ENTER would be awesome.

Claimed rooms would never have to .find(FIND_HOSTILE_CREEPS) again. The hostile creeps could have their id's recorded when they trigger an EVENT_ENTER and tracked until death or EVENT_EXIT, which could both be handled differently. Granted you'd have to check the log every tick versus perhaps only doing a .find every x ticks. Which method would require more CPU do you think? .finding hostile creeps every tick or checking the log every tick? Either way the log sounds useful.

Also being able to determine when something has taken damage without looping through every single thing and checking the hit sounds great. Especially for things where this is tricky because of decay like containers, roads, and ramparts.

Also will allow something like this:

if (ALLIES[damageDealer]) {
    ALLIES[damageDealer] = false;
    IS_JERK[damageDealer] = true;
}

Which was still probably manageable before, but not quite as simple and nice as this ^

Rurik

@dissi Rubble sounds cool. Would be consistent with the tombstones. The destroyed flag would only work in conjunction with the rubble right? If the structure is destroyed (without rubble) you'd still have the null issue.

@gankdalf said in Draft: room event log:

{
   type: EVENT_DESTROYED,
   structureType: STRUCTURE_SPAWN
}
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.

I also think this would be plenty. Even if it triggered when an old hostile structure was destroyed I think it would still be useful. At the very least it could tell you to .find all of your structures of that type and handle any missing ones, instead of checking like that every tick. If a player handles it incorrectly due to it being a hostile structure that was destroyed, that is the problem of that player to fix.