get attackers details
-
Agreed. The data is available in client view & creep actionLog so it makes sense to make it available to scripts as well.
If the point of automation is to limit human input, then it doesn't make sense to me that humans can see more data/
-
On the contrary, I think that limited creep visibility is part of the "fog of war" you should be dealing with as an AI dev.
Imagine the added challenge when you have a military action intruded on by a 3rd party - you have to deduce based on their position and potential actions whether or not they are coming to your aid or to the aid of your opponent.
-
Except it's visible in the UI. A person paying attention can easily figure this out, so it should be possible for scripts as well.
-
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.
