Vision of flying units

[SwedishChef]

Hi! How do I change the vision type of the flying units so that they see like ground units? Flying have on standard unobstructed vision so they see everything undependant of the trees and such. Basically I just want them not to be able to see past my Line of sight blockers.

 

[mapguy]

try this.

set the vision of all flying units to 0.
for each flying unit created you create a dummy with the vision you want. then you create a periodic dummy that is always moved to the position of flying units.

 

[SwedishChef]

try this.

set the vision of all flying units to 0.
for each flying unit created you create a dummy with the vision you want. then you create a periodic dummy that is always moved to the position of flying units.

Too advanced there is an easier way and I know it. It is an setting on the unit.

 

[Accname]

you cannot change the "vision type" of units. flying units can see above any obstacles.
what you can do is make them ground units however thence they cannot fly, too bad. you could for example make them ground units but toggle their collision off but they might fly out of the map bounds then i guess.

what mapguy said is plainly bad, it would cause tremendous lag for many flying units, what is unnecessary.

if you dont want them to see into a specific region and not in general you can use visibility modifiers like setting black mask across the area you like.

 

[the_ideal]

try this.

set the vision of all flying units to 0.
for each flying unit created you create a dummy with the vision you want. then you create a periodic dummy that is always moved to the position of flying units.

To the naysayers in this thread: the quoted suggestion DOES work. I used the opposite in my map: I wanted ground units to have flying sight, so I periodically moved flying dummy units with vision to the positions of my heroes. It did not cause lag, and I do not have a cutting edge computer.

The only problem with the above suggestion is that if a flying unit went over ground that is unpathable for ground units, the dummy units wouldn't be able to get there.

But the trigger actually isn't hard at all. This is what I used in my map. You'll have to tweak it a little.

• Flyer Vision
  • Events
    • Time - Every 1.00 seconds of game time
  • Conditions
  • Actions
    • For each (Integer B) from 1 to 10, do (Actions)
      • Loop - Actions
        • Set point1 = (Position of Hero[(Integer B)])
        • Unit - Create 1 Flying Vision Dummy for (Player((Integer B))) at point1 facing Default building facing degrees
        • Custom script: call RemoveLocation (udg_point1)
        • Unit - Add a 1.00 second Generic expiration timer to (Last created unit)

*Note: you're not going to be able to use the integer loop. You'll need to pick every flying unit. If you need help doing that, just post again and I (or someone else) will help you.

 

[Moridin]

To the naysayers in this thread: the quoted suggestion DOES work. I used the opposite in my map: I wanted ground units to have flying sight, so I periodically moved flying dummy units with vision to the positions of my heroes. It did not cause lag, and I do not have a cutting edge computer.

The only problem with the above suggestion is that if a flying unit went over ground that is unpathable for ground units, the dummy units wouldn't be able to get there.

But the trigger actually isn't hard at all. This is what I used in my map. You'll have to tweak it a little.

Trigger:

* Flyer Vision
o Events
+ Time - Every 1.00 seconds of game time
o Conditions
o Actions
+ For each (Integer B) from 1 to 10, do (Actions)
# Loop - Actions
* Set point1 = (Position of Hero[(Integer B)])
* Unit - Create 1 Flying Vision Dummy for (Player((Integer B))) at point1 facing Default building facing degrees
* Custom script: call RemoveLocation (udg_point1)
* Unit - Add a 1.00 second Generic expiration timer to (Last created unit)


*Note: you're not going to be able to use the integer loop. You'll need to pick every flying unit. If you need help doing that, just post again and I (or someone else) will help you.

Accname didn't say it doesn't work. It just causes tons of lag if you want it to accurately slide the sight dummies along with the flying unit's position.

For example, your trigger has an event of Time - Every 1.00 second of game time. This is a little too long for accurate vision, seeing as a unit (especially a flying unit) can move a whole lot in a single second.

As you pointed out, if a flying unit moved over deep water or other unwalkable terrain, the dummies would get displaced.

Finally, the trigger you use would create 1 unit per flying unit per second. Creating units takes a lot more processing than moving them, so I would suggest creating them once and then periodically shifting their position.

 

[Moridin]

Lag double post -_-.

 

[Azylaminaz]

Occlusion Height is the field that controls how "high" something is in terms of flying units. If you set the Occlusion Height to something higher than the flying unit, they won't be able to see over it.

Seeing over cliffs, though, is another story. It is natively always possible to see over cliffs if you are a flying unit. A wonderful thing about cliffs, though, is that they never change. This means you can put LoS (Line of Sight) blockers around cliffs. Problem here, though, is that they aren't two way. IE, you won't be able to see down cliffs, then....

Cliffs are the problem... Occlusion height fixes many things (hell, technically, if you wanted, you can even make super high destructs via triggers on some things if you don't want to be able to see through buildings).

An occlusion height of zero means ground units can see past it.

Only destructables have occlusion height fields, BtW.



Edit (apparently

---

isn't a BBC?):
You can use JASS to make it so ground units can be placed anywhere, including on cliffs or in water (even if land is a millimeter away).

• Actions
  • Custom script: call SetUnitX(<your unit>, <x coordinate>)
  • Custom script: call SetUnitY(<your unit>, <x coordinate>)

 

[SwedishChef]

Occlusion Height is the field that controls how "high" something is in terms of flying units. If you set the Occlusion Height to something higher than the flying unit, they won't be able to see over it.

Seeing over cliffs, though, is another story. It is natively always possible to see over cliffs if you are a flying unit. A wonderful thing about cliffs, though, is that they never change. This means you can put LoS (Line of Sight) blockers around cliffs. Problem here, though, is that they aren't two way. IE, you won't be able to see down cliffs, then....

Cliffs are the problem... Occlusion height fixes many things (hell, technically, if you wanted, you can even make super high destructs via triggers on some things if you don't want to be able to see through buildings).

An occlusion height of zero means ground units can see past it.

Only destructables have occlusion height fields, BtW.



Edit (apparently

---

isn't a BBC?):
You can use JASS to make it so ground units can be placed anywhere, including on cliffs or in water (even if land is a millimeter away).

• Actions
  • Custom script: call SetUnitX(<your unit>, <x coordinate>)
  • Custom script: call SetUnitY(<your unit>, <x coordinate>)

---

Good post! Thing is that I have line of sight blockers but still flying units see over them.

 

[Moridin]

Open the object editor. Under Destructible -> Pathing Blockers -> Line of sight blocker there is a field called:

Art - Occlusion Height

Try changing that to a very high number, (something higher than the flying height of your units. That should stop them from seeing over it.

Edit: Tested it, doesn't work .

 

[Accname]

@swedishchef: if possible try just using regions and visibility modifiers. that would be an easy and fast way to do it.

 

[mapguy]

easy to put a ground dummy in a non-ground place

remove collision from dummy[841]
move dummy[841] to x

 

[Accname]

easy to put a ground dummy in a non-ground place

remove collision from dummy[841]
move dummy[841] to x

as Azylaminaz posted this:

• Custom script: call SetUnitX(<your unit>, <x coordinate>)
  • Custom script: call SetUnitY(<your unit>, <x coordinate>)

is way better and performs perfectly fine.

 

[mapguy]

as Azylaminaz posted this:

• Custom script: call SetUnitX(<your unit>, <x coordinate>)
  • Custom script: call SetUnitY(<your unit>, <x coordinate>)

is way better and performs perfectly fine.

I didn`t see his post...
sorry