[Suggestion] Functions related to vision of entities and visiblity

[AnonymousDonald]

We noticed a lack of functions that allow you to check wheter an entity is being viewed, what the entity can view and team related view-ability.

Currently we have BaseNPC.CanEntityBeSeenByMyTeam(handle hEntity), but this lacks functionality.

We would like to suggest the following functions

• bool CDOTA_BaseNPC:CanBeSeenByTeam( teamID )
• table CDOTA_BaseNPC:GetSeenEntities()
• table CDOTA_BaseNPC:GetEntitiesThatSeeMe()

The first could also replace the already implemented function, since it can be implemented to also provide the functionality "CanEntityBeSeenByMyTeam" provides.

The second function will provide a list of entities that see the specified entity.

The third function will provide a list of entities that this entity can see.

[arhowk]

The first function can be implemented in LUA using CanEntityBeSeenByMyTeam (assuming hEntity is the player entity in the "my" context)

The second function will provide a list of entities that see the specified entity.

Player entities? or just any entity... Keep in mind not every entity has a field of view.

The third function will provide a list of entities that this entity can see.

Not quite sure what you mean by this.. Do you mean entities within this entities field of view?


Considering how long we've waited for the fog of view fix for bigger maps, I doubt we are going to see anything similar to these functions anytime soon

[Daimao]

The first function can be implemented in LUA using CanEntityBeSeenByMyTeam (assuming hEntity is the player entity in the "my" context)

I think you're misunderstanding the use-case of the first suggested function by OP. Using CDOTABaseNPC:CanEntityBeSeenByMyTeam(handle hEntity) implies the programming situation to be that there's two variables (entities) known to the programmer, namely: entity A (source) and entity B (target). In the situation of A:CanEntityBeSeenByMyTeam(B), NPC B is the NPC you want to do the visibility check on and NPC A is the NPC the function gets its team from. You could program a work-around for the first function using this, but a solution built using this method would only work under certain assumptions.

The main gripes here are accessing an NPC A from the team that is supposed to see NPC B and doing this optimally. What if that's not possible in your current programming scope and you just have access team ID (which is always defined)? What if using that workaround leads to an unnecessarily high time complexity? (Ex. finding entities to perform CDOTABaseNPC:CanEntityBeSeenByMyTeam(handle hEntity) from in a thinking context every 0.1 seconds)

Player entities? or just any entity... Keep in mind not every entity has a field of view.

I think it's only logical that a function like this should only return entities if those are actually affected by the fog-of-war system themselves. (NPCs, buildings, trees) Maybe a flag or filter would be needed in this proposed function to filter out specific types of entities? Or something similar qua function structure to the Find-functions in CEntities?

The second suggested function, table CDOTA_BaseNPC:GetSeenEntities(), should be able to be easily implemented using CEntities:FindUnitsInRadius and using CDOTABaseNPC:CanEntityBeSeenByMyTeam(handle hEntity) a few times, but that solution seems to generate an extremely high time complexity to me. In a worst case scenario this would lead to something like this:

--Note: This code is more about the complexity than the actual functionality, so I did not test or profile it.
local npc = self -- The CDOTA_BaseNPC entity that wants to find all entities that it can see
local units =  FindUnitsInRadius(
	        	npc:GetTeam(),
	                npc:GetAbsOrigin(),
	                nil,
	                npc:GetCurrentVisionRange(),
	                DOTA_UNIT_TARGET_TEAM_BOTH,
	                DOTA_UNIT_TARGET_ALL,
	                DOTA_UNIT_TARGET_FLAG_NONE,
	                FIND_ANY_ORDER,
	                false) --O(x) complexity --where 'x' is unknown time-complexity of FindUnitsInRadius
local result = {}
for k,v in pairs(units) do --O(n) * O(y) * O(1) complexity --where 'n' is the size of the table 'units'
     if npc:CanEntityBeSeenByMyTeam(v) then --O(y) complexity --where 'y' is unknown time-complexity of CanEntityBeSeenByMyTeam
          table.insert(result, v) --O(1)
     end
end
return result

This nets you O(x) + O(n) * O(y) time complexity, which could be disastrously inefficient depending on the amount of units in your NPC's sight range and the time complexity of Source's FindUnitsInRadius and CanEntityBeSeenByMyTeam functions.

You could solve function 3 in an even worse way by using a structure similar to the above solution by looping through all the entities and then checking if they see 'npc' and then adding them to the result table if they do. You could optimize it by keeping track of the team IDs that've seen 'npc' and making a check every time you loop through an entity if their team has already seen entity 'npc' and then adding the entity to the result table straight away if the entity's team has already seen 'npc'.

TL;DR:

• bool CDOTA_BaseNPC:CanBeSeenByTeam( teamID ) cannot be solved with existing API functionality. There are workarounds for other similar functions, but those would not work in cases where you only have a team ID, and not an entity, in your programming scope.
• table CDOTA_BaseNPC:GetSeenEntities() can be solved in an inefficient way with existing API functionality.
• table CDOTA_BaseNPC:GetEntitiesThatSeeMe() can be solved in an extremely inefficient way with existing API functionality.

I'd say all these functions are worth it to implement after thinking about some common use-cases of these functions. (ex. Slark ultimate, AoE spell that only hits enemies that are not in fog of war from the caster's perspective, NPC AI, etc.) If not these exact iterations, then at least the functionality they bring to the table.

[AnonymousDonald]

Like Daimao stated, it's not that the goals that we wish to reach are out of scope, but the current API does not allow for it in an efficient and painless way.

Also, I would deem it reasonable that these functions get implemented seeing that a lot of AI related and spell related stuff are tied in directly to field of view.