Help Create Trigger: Reveal Circle Around Unit?

[Gnuoy]

I'm sure someone has an idea for a good way to do this. Figured I would ask before a spend several hours making something overly complicated.

Pretty much I want to reveal a really large area, preferably in a circle, like 5000 units, I think Object Editor caps sight at 1800?

Outline idea:
-Structure type finishes construction
-Sets points in a circle or creates a circular region. Maybe some trigonometric function could be used here.
-Reveals the circle (a bit unsure how to do circles in WE). Was thinking it would reveal for the "leader" of this team so if someone leaves the team, the visibility won't go with them. (perhaps unimportant detail)
-If Structure is killed then it turns off this visibility modifier and perhaps disposes of the region/points.
-could be used for several of these types of structures without bugs (this is the part that makes me hesitant to attempt to do this on my own).

Any input is appreciated even if it's not a fleshed out trigger. Thank you.

 

[Nichilus]

I think what you want is essentially this:

• Visibility - Create an initially Enabled visibility modifier for Player 1 (Red) emitting Visibility from (Center of (Playable map area)) to a radius of 512.00.

Basically, you would create X of those modifiers (one for each relevant player) after the structure has been finished, store them in array and destroy them when the structure has been destroyed

 

[Gnuoy]

Oh that's much more simple than I expected.

What would be the concept if players could build multiple of these reveal structures?

 

[Nichilus]

I can think of two ways:

1. Use unit group to keep track of the structures + hashtable to keep track of the visibility modifiers
2. Use an indexing technique and two arrays - one for keeping track of structures, the other for tracking the modifiers

Ad 1
Store visibility modifiers in hashtable, where parent key is the handle id of the structure and the child key is player's number who the visibility modifier belongs to.
The unit group is optional as you can probably get all your structures ad-hoc via "Pick every unit" action, but I would say it's easier with the unit group.
The below is a simplified example of how I meant the storing of the visibility modifier:

• Set VariableSet TheStructure = Your_Unit
• Custom script: set udg_HandleId = GetHandleId(udg_TheStructure)
• Visibility - Create an initially Enabled visibility modifier for Your_Player emitting Visibility from some_location to a radius of some_number.
• Hashtable - Save Handle Of(Last created visibility modifier) as (Player number of Your_Player) of HandleId in VisibilityModifiersHashtable.

When you want to remove this modifier, you know for which building and which player, so you basically have both the parent and child keys under which the visibility modifier is stored in hashtable.

Ad 2
You need two arrays here - first one is 'unit' array in which you will store the structures. Use indexing to store each structure under unique index in that array.
The second array will be used for storing the visibility modifiers. This array will be split into 'buckets' where each bucket is of size 24 (the total number of players). Each bucket has size 24 so that you can use again the player's number as the index in the bucket.

Those buckets are only logical splits, in reality you still have a single visibility modifier array. So to calculate the index range of the bucket, you need to calculate the bucket's offset from starting index:

(structure's_index - 1) * bucket_size => (structure's_index - 1) * 24

first example:

• Structure is stored under index 1 in the unit array
• bucket_offset: (structure's_index - 1) * bucket_size = (1-1)*24 = 0
• bucket range: [ (bucket_offset + 1) .. (bucket_offset + bucket_size)] = [ (0 + 1) .. (0 + 24)] = [1, 24]
• index of player 2 blue's visibility modifier for this structure: offset + player's number => 0+2 = 2

second example:

• Structure is stored under index 3 in the unit array
• bucket_offset: (structure's_index - 1) * bucket_size = (3-1)*24 = 2*24 = 48
• bucket range: [ (bucket_offset + 1) .. (bucket_offset + bucket_size)] = [ (48 + 1) .. (48 + 24)] = [49, 72]
• index of player 2 blue's visibility modifier for this structure: offset + player's number => 48+2 = 50

It would look something like this:

• Set VariableSet StructureIndex = (StructureIndex + 1)
• Set VariableSet StructureArray[StructureIndex] = Your_Unit
• Set VariableSet IndexOffset = ((StructureIndex - 1) x 24)
• Visibility - Create an initially Enabled visibility modifier for Your_Player emitting Visibility from some_location to a radius of some_number.
• Set VariableSet VisibilityModifierArray[(IndexOffset + (Player number of Your_Player))] = (Last created visibility modifier)

To remove player's visibility modifier, you need to first find out under which index the structure is stored in the unit array, then calculate the offset and finally add to the offset the player's number.
The other thing is that if your structure is destroyed, you should deindex it, which means deindexing not only the unit array, but the visibility modifier array as well.

 

[Uncle]

Unit Indexer comes to mind.

Create visibility modifier -> Link to unit's custom value

Then if the unit dies you simply get it's custom value and destroy the associated modifier

 

[Gnuoy]

Unit Indexer and Hashtable seems too complicated for me. Like I get hashtable is pretty my an X, Y grid but it just confuses me.

Uncle's method seems more agreeable to me not wanting to grow new neurons in my brain to figure this out

Anyway so for Uncle's proposal,
udg_unit[custom_value]
like the integer = custom value, then that goes in the array brackets?
then i destroy it and the visibility modifier, and it would eventually break once we run out of integers.

 

[Uncle]

• Events
  • Unit - A unit finishes construction
• Conditions
  • (Unit-type of (Triggering unit)) Equal to YourStructure
• Actions
  • Set Variable Point = (Position of (Triggering unit))
  • Visibility - Create an initially Enabled visibility modifier for (Owner of (Triggering unit)) emitting Visibility from Point to a radius of 5000.00.
  • Set Variable VM[Custom value of (Triggering unit)] = Last created visibility modifier
  • Custom script: call RemoveLocation( udg_Point )

• Events
  • Unit - A unit dies
• Conditions
  • (Unit-type of (Triggering unit)) Equal to YourStructure
• Actions
  • Visibility - Destroy VM[Custom value of (Triggering unit)]

You'd need 32,768 of these Structures active at one time to "run out of integers". In other words, ain't gonna happen.

GUI Unit Indexer 1.4.0.0

Why Unit Indexing is Important For those not familiar with unit indexers such as UnitIndexingUtils, AutoIndex, Perfect Unit Indexing (PUI), Advanced Indexing and Data Storage (AIDS) or Unit Indexer, this can give you a bit of a crash-course. You definitely want to make your spell MUI. To do...

www.hiveworkshop.com

 

[Gnuoy]

This will only work 256 times (array limit)? That should be more than enough but just for my/later readers' understanding.

 

[Uncle]

This will only work 256 times (array limit)? That should be more than enough but just for my/later readers' understanding.

Hashtables have a 256 creation limit.

You can create as many Array variables as you'd like, you just can't put an integer > 32,768 in the [index] of an Array. A Unit Indexer assigns each unit a unique Custom Value starting at 1 and working it's way up. It will recycle unused Custom Values as well so unless you have 32,768 units on your map all sharing an Array then you don't need to worry about it. That really shouldn't ever happen.

 

[Gnuoy]

Spoiler