4. get attackers details

get attackers details


  • I believe Artem only wanted to make sure it is a durable approach, with few future changes

  • Culture

    I guess my point is that if they add a `pvpactions` data structure to the room object there's no real reason to remove it should they add a more complicated system later. I'd imagine the vast majority of players just need to know what players are attacking them, and while adding in the features to also give more information might be nice it's also likely to be complete overkill for most players.

    To be honest if they added this `pvpactions` structure and then later on added a second more complex one I'd probably just ignore the more complex one, as I can get my answers from `pvpactions` with less processing and CPU usage.

  • AYCE

    I don't see a problem with adding a .getAttackers()-function to Creep and Structure-prototypes, that returns the IDs of the things that attacked them the last tick.

    If the creep/structure attacked is dead the next tick, so be it. The information is lost, it even feels a bit natural that the information is lost then.

    I would prefer information about attacktype, creep/structure and player, but anything is better than no info. Even just boolean "attacked last turn" would be better than nothing. I'm notified by mail when I'm attacked, but if I'm overhealing I'm not able to detect it in code.

  • YP

    I think for own damaged creeps the name is enough, even if it is one hitted there still would be the memory of the creep to find out what it was. own damaged structures probably need to be a dictionary because they might have been destroyed.

    The a hostile attacking creep / structure should be an object/dictionary, because it could be no longer available.

    I would prefer to not have it on the room object but more global .. the room might not be available in the next tick.

    It could also be done with some kind of notification system .. a list of message objects that inform the script about stuff that happened. this could also be used for oter stuff ... (like sending other players notifications for example 😉 )


  • If we are killed instantly, I'm perfectly okay with that data being unavailable. Killed too fast to report. No problem. As for the target being killed in the same timeframe, I am also completely okay with this. It can be our responsibility to test for null on Game.getObjectById(); I suggest storing the following data in an array. on any creep or structure. This data should only be available on the very next tick only. i.e. it should ONLY list damage from the previous tick, or nothing. It should be an array because there could be multiple damage sources.

    creep.prototype.damageSources (array)

    .id

    .amount (of damage)

    .owner

    structure.prototype.damageSources (array)

    ...

     


  • Alternatively, if the idea of a dead creep telling no tales is really such a big issue for people. the alternative is to extend it off of Room. If this direction is chosen it should be subject to normal visibility rules. As already suggested, I think an array of damage sources would make sense, but in this case it needs to list both attacker and defender for each event. 


  • Why should it only be PvP? If an Invader or a Source Keeper damages you, you should get that information too.

    Â