get attackers details
-
No, there's not much of a point if you feel entitled to the same information as the web UI.
Why bother figuring out using range if you can scrape the web.
-
You can't guess this by range.. there are towers, range attacker/healers and multiple close targets - even with your "fog of war" you should now know many "people" have hit you (and even if you've been hit) and for how much
-
How about adding a `intent` property to every object that can issue intents? This object will contain an array of intents that this object has executed successfully in the previous tick and will work similarily to the current `saying` property of Creep.
Edit: As seen in the server source, there already is an internal `actionLog` property that contains this kind of information.
-
The problem is that the code has absolutely no way to distinguish which creep or even potentially which player just damaged it. If your code gets attacked, If you are in an alliance, and someone betrays you, you have a very real problem. What if two different allies are in range of your creep at the same time? Is your code supposed to flip a coin to decide which ally you must now break the alliance with?
It's not that it's a difficult problem to solve in code currently, it's actually an impossible one. Our code should not be forced to GUESS who just attacked it.
-
the potential forest of attackers that could have attacked you, starting with just ranged attack is 48 creeps, assuming the admittedly unlikely scenario that a veritable swarm of creeps surrounds you. Then you need to consider towers. And whenever Power creeps get added to the mix there will be additional potential damage sources since there is a creep that can buff your range to 4, and there is a sniper who can strike at range 10.
So the total number of potential targets is 54 in a hostile room with towers. If you add in range 4 and snipers from potential future content this number grows to 87. That's 87 tiles that your creep needs to scan for creeps to even begin to try to GUESS who just actually hurt you.
is it really too much to ask for a simple list of who damaged you last tick?
Creep.attackedBy();
OwnedStructure.attackedBy();
returns null, or an Array of entities that damaged your Creep or Structure Last tick. entities could include Towers, Creeps, and in future PowerCreeps.
-
We admit that this missing functionality is important, and it is on our roadmap. However, it seems to be more complicated than you may imagine:
- It cannot be implemented on Creep prototype, since your creep may be already dead by that moment;
- It cannot just contain the attacker's ID, since it may have been killed or left the room as well;
- Storing such amount of redundant info in every room will create a lot of traffic and internal load in the runtime engine.We'll look into possible solutions, but I can't promise that the timeframe will be anytime soon.
-
Personally, i'm ok with the info gone when your creep dies, or pointing to a non-existing ID (creep/structure died as well - we can handle storing all creeps/towers and matching that ID so it shouldn't be an issue), but what does leaving the room has to do with it?
You can store the info when different players' creeps interact which shouldn't be that often or a lot of extra data
-
If a creep leaves the room, it might have probably gone out of your visibility, thus its ID is no longer meaningul for you. And I don't agree that it's OK to lose the data when the creep dies, since one-shot is always a possibility.
-
well, "meaningful" should be handled by our scripts and if the option was to have or not have the data - yeah, i'd like to have it even when the creep dies one-shotted, but the choice is having most of this feature available soon or at an unknown period probably at the end of the year
also, why not store the info in the creep's memory - that way it'll persist even after its death
-
The game engine never touches player's memory since it might be structured in any format, not only the default one.
-
well, then i'm out of quick solutions
-
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.
-
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...
-
Who said anything about temporary?
-
I believe Artem only wanted to make sure it is a durable approach, with few future changes
-
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.
-
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.
-
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)
...
