Draft: room event log


  • Dev Team

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


  • Dev Team

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



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


  • Dev Team

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



  • 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 ^



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


  • YP

    @rurik said in Draft: room event log:

    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?

    The log way will use much more CPU. FIND_HOSTILE_CREEP is quite cheap since it usually contains nothing. For the log you have to pay cpu for the parsing of all events in the room. With find you don't have to keep track of creeps.. you don't have to check if the entering/exiting creep was friend or foe. If a hard reset occurs your track of creeps in the room might be outdated. I don't see the advantage of EVENT_ENTER / EVENT_EXIT, yet.



  • @w4rl0ck said in Draft: room event log:

    I don't see the advantage of EVENT_ENTER / EVENT_EXIT, yet.

    EVENT_EXIT gives you otherwise unknowable information, and that's the primary purpose of the event log, it seems. Lets say my attack creep is hot on the heels of a bandit. I'm bludgening him and soon will get the kill but... oh no! He left the room! There's three exit tiles he could have gone to. How am I going to follow?

    Right now, the answer is to pick an exit and hope. There's a reasonable chance that I'll pick wrong and he'll get away. I should be able to follow him, and EVENT_EXIT would let me do that.

    I don't see the use of EVENT_ENTER. Doesn't tell me anything I wouldn't already know.



  • This is a useful change. 👍



  • I wonder how practical it would be to log all RoomObject creation / destruction?