4. get attackers details

get attackers details


  • well, then i'm out of quick solutions 😄

  • Culture

    Honestly I think the proposals are overthinking (or overcomplicating) this.

    room.pvpactions = {
      player1: [player2, player3],
      player2: [player1],
      player3: [player1]
    }

    An object like that would solve 95% of people's problems. 

    Knowing exactly which creeps attacked what other creeps and structures would of course be nice, and I wouldn't object to it in the long term, but this seems like it would be easier and it would certainly make me happy.

  • Dev Team

    Creating a temporary API that is going to be replaced soon is not an option, especially considering numerous private servers support.


  • How about a simple array of damage objects?

    room.damage = [{dealingPlayer, dealingCreepId, takingPlayer, takingObjectId, damageAmount}]

    I understand your concerns regarding a temporary API. But it also wouldn't need to be 100% perfect. I think something like the above would be suitable for most szenarios.

    If "my" script can't handle a leaving hostile creep (into an other room out of my sight), it shouldn't be your fault, right? At least it wasn't before this topic. If that damage dealing creep is dead already, why should I care about it, but I still know the player.

    The above approach could also simply be extended with further metadata about the attacker, like dealingCreepPos, if that is required, or any other future requirement. Or you can make it even more generic using dealingObjectId and dealingObjectType instead of dealingCreepId, to support nuke or power bank damage...

  • Culture

    Who said anything about temporary?


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

    Â