How to filter units (with angles)?

[bowser499]

See the image.

 

[Accname]

the difference between the angle from the casters position towards the position of the target and the facing angle of the caster got to be less then or equal to X whereas X can be defined as you like.

 

[bowser499]

57.295827 * Atan2(targy - casty,targx - castx) > (what?) and 57.295827 * Atan2(targy - casty,targx - castx) < (what?)

 

[Accname]

Edit:
Nevermind, i made a mistake.

 

[NeuroToxin]

Maybe you get get all units in an angle, you just gotta figure out the angle from the start of one white point to the end

 

[Ashlebede]

[GUI]

http://www.thehelper.net/forums/showthread.php?t=154267

It's basically comparing the angles between the picked unit and the casting unit and comparing it to the way it's facing (or the angle between the casting unit and the target point).

[ljass]if difference<=Angle/2 or difference>=-Angle/2 then[/ljass]
[ljass] //! if actions[/ljass]
[ljass]endif[/ljass]

This doesn't seem to work correctly for angles too near 180 (don't ask me why, I thought it wouldn't work for 0... anyways). There is a workaround, though. See before-before-last post.

 

[Bogrim]

This is what I came up with:

• Breath of Fire
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to Breath of Fire
  • Actions
    • Set Temp_Point[0] = (Position of (Triggering unit))
    • Set Temp_Point[1] = (Temp_Point[0] offset by 187.50 towards (Facing of (Triggering unit)) degrees)
    • Set Temp_Group = (Units within 375.00 of Temp_Point[0] matching (((Matching unit) belongs to an enemy of (Owner of (Triggering unit))) Equal to True))
    • Unit Group - Pick every unit in Temp_Group and do (Actions)
      • Loop - Actions
        • Set Temp_Point[2] = (Position of (Picked unit))
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • Or - Any (Conditions) are true
              • Conditions
                • And - All (Conditions) are true
                  • Conditions
                    • ((Angle from Temp_Point[0] to Temp_Point[1]) - (Angle from Temp_Point[0] to Temp_Point[2])) Less than or equal to 75.00
                    • ((Angle from Temp_Point[0] to Temp_Point[2]) - (Angle from Temp_Point[0] to Temp_Point[1])) Less than or equal to 0.00
                • And - All (Conditions) are true
                  • Conditions
                    • ((Angle from Temp_Point[0] to Temp_Point[2]) - (Angle from Temp_Point[0] to Temp_Point[1])) Less than or equal to 75.00
                    • ((Angle from Temp_Point[0] to Temp_Point[1]) - (Angle from Temp_Point[0] to Temp_Point[2])) Less than or equal to 0.00
          • Then - Actions
            • Unit - Cause (Triggering unit) to damage (Picked unit), dealing 65.00 damage of attack type Spells and damage type Magic
            • Special Effect - Create a special effect attached to the chest of (Picked unit) using Abilities\Spells\Items\AIfb\AIfbSpecialArt.mdl
            • Special Effect - Destroy (Last created special effect)
          • Else - Actions
        • Custom script: call RemoveLocation( udg_Temp_Point[2] )
    • Custom script: call RemoveLocation( udg_Temp_Point[0] )
    • Custom script: call RemoveLocation( udg_Temp_Point[1] )
    • Custom script: call DestroyGroup( udg_Temp_Group )

Maybe there's a better method, but I'm not a mathematic expert. I compared the off-set angle from the point of the picked unit to the triggering unit's facing angle to create a range in form of a cone.

 

[Ashlebede]

Isn't using arrays for this the purest form possible of a waste of RAM? After all, there are 8192 members in an array. That means there are 8192-3=8189 unused variables. That means you lose 8192*(size of a handle) bytes of RAM. I think the size of a handle is 2, maybe it's 4.

Anyways, using Temp_Point0, Temp_Point1 and Temp_Point2 insteand of Temp_Point[0], Temp_Point[1] and Temp_Point[2] can save loads of RAM without altering performance. And isn't saving RAM the point of using those anti-leak variables, after all?

 

[Bogrim]

An array doesn't start out with 8192 members unless you specifically increase the starting size of the array in the variable editor. Instead, the array is automatically expanded as new indexes are set in the array.

 

[Ashlebede]

The 8192 may be undefined, but they are still existant. The only difference the array size specified in the Variable Editor makes is how many values will have a custom initial value. If you look only at the global definition, an array with a max size of 1 has the same definition as one with a max size of 1000. The difference is in the loop that initializes them.

 

[Bogrim]

That's just not how Warcraft works. It's true that large arrays take more RAM and if you have too many arrays of maximum capacity your map initialization triggers will fail to load as result of this. But the size of the array depends on the capacity set when creating the array - that is the function’s purpose.

Remember that Warcraft is an old game and you are trying to argue with theory against well known fact.

 

[Ashlebede]

[ http://world-editor-tutorials.thehelper.net/cat_usersubmit.php?view=20023 ]
Size
Arrays in JASS all have the same max index of 8192. This means that the 'size' field for arrays in the WE is useless (to my knowledge). In this sense arrays are more like hash-tables, as you will not recieve an 'index out of bounds' error. But it also means that every array you make will occupy a certain amount of space no matter how much or little data is put into it.

[ http://jass.sourceforge.net/doc/types.shtml ]

Array variables are initialized to "empty" values (e.g., 0 for integer arrays, and null for handle arrays) and have a fixed size. Each index in an array holds a value of its declared type and is referenced with the standard bracket notation. For example, my_array[10] refers to the 11th element of my_array.

[ http://www.thehelper.net/forums/showthread.php?t=137090 ]

Arrays require an index whenever they are used. The index is accessed using brackets [ ]. Arrays may contain indexes from 0 to 8191. Keep in mind that the 8191 and 0 indexex are buggy as they will not work when loading a saved game. It is safest to use 1 thru 8190. If you don't plan on saved games, then use 0 and 8191 to your heart's content. Keep in mind that the 8192 number comes from an array size of 8kb.

Although the "0 indexex is buggy", which makes that source questionable... I have to admit I never tried using it with a saved game... oh, well...

 

[Bogrim]

What Laika means by the field size being "useless" is that the array size automatically increases when you set new entries in the array and there’s no need to actually increase the size of the array beforehand in the variable editor. However, there are some variable types which do not behave this way and require you to “manually” increase the array’s size to create new indexes (such as timers).

What Laika means by arrays taking up a certain amount of space is that an array will occupy (presumably) more space than a normal variable regardless of the number of indexes in the array. However, it does not mean that an array with 10 indexes is as large as an array with 8192 indexes.

There are several JASS systems built around how arrays work such as AIDS. Your original point was that an array left at least 8191 unused variables. If that statement was true, map editors would have to limit the amount of arrays and such indexing systems wouldn't be viable.

If you need further proof of this, create two different maps and run an action in the map initialization. In the first map, create 100 arrays with the size of 1. In the second map, create 20 arrays with maximum capacity. The second map will fail to run the map initialization.

 

[Ashlebede]

The 20 arrays with max capacity has nothing to do with RAM, which is what I'm talking about. Arrays are initialized in a function that can be overloaded if too many actions are in it. It has nothing to do with how the array works internally, and your RAM can take 160KB, anyways.

What Laika means by arrays taking up a certain amount of space is that an array will occupy (presumably) more space than a normal variable regardless of the number of indexes in the array. However, it does not mean that an array with 10 indexes is as large as an array with 8192 indexes.

That is my point. Although I may not have been completely right in my other post, the main point is that array take up more space than non-array variables. Therefore, if arrays aren't significantly easier to use than non-arrays and aren't more efficient, there is no reason to use arrays, as it would still use up more RAM.

 

[Bogrim]

Arrays are initialized in a function that can be overloaded if too many actions are in it. It has nothing to do with how the array works internally, and your RAM can take 160KB, anyways.

You just acknowledged that the size of the array is relevant to the game's performance.

That is my point. Although I may not have been completely right in my other post, the main point is that array take up more space than non-array variables. Therefore, if arrays aren't significantly easier to use than non-arrays and aren't more efficient, there is no reason to use arrays, as it would still use up more RAM.

Except that a temporary variable is re-used through most of your triggers and therefore the difference in size doesn't really matter since we are only talking about one array, which also includes triggers in which an array may be necessary. Even an extreme minimalist could not make out a difference in the game's performance.

Ash, this debate has been off-topic. Next time you want to question the work methods of another helper, start a new thread or use private messages.