to be honest ur traceline is very cp heavy due to it being a looping trigger with a bunch of calculations. You should instead be using for every mouse clicked event to start it off. No reason to have a looping traaceline. It has too many vaariables and theirs a much simpler triggering format to get the same and even better effect.
XXXXXXXXXXX
Start with the TPS library traceline, thats where I learned how to make a good traceline. That traceline isn't the best but it will do for now. Some things you'd like to know is that it seraches like from 1 to 100 so there are 100 circles with a fixed radius that seraches units in a line with the direction of the camera from the player's unit. That is the most important thing about that traceline. Then when it finds a target it compares its custom value which is what the creator sets that units height as. Using this he compares it with the function of the angle of tangent with the camera to determine if its within range. if it is its a hit and set the target as that unit.
Basically, its a line which seraches for dots. In an rts stand point, its easier to make a game with dots instead of rag dolls. The rts system places models for these dots which is what you see. But looking inside the game itself, they are all basically flats dots on a flat 2d plane with a radius.
If you still need help we can talk on skype/vent just pm me
Would you care to explain how this idea differs from my traceline? Also once my standard traceline detects a target you can simunlate randomess of the projectile with separate triggers. Also most of what you said is generally incoherent. He would have no idea how to build a traceline from what you said, because even I don't know what you said (except that last paragraph that describes how to make a simple traceline which is an exact replica of mine).
You can make the radius of seach circle along the traceline larger as the distance along the traceline increases with the formula r = X/N * f(z) where f(z) is a function of z. This would counter the perspective problem of a narrowing traceline over distance.
Listen, just look at my traceline, ultimately every non-physics based traceline has to do EXACTLY what I did. There are no shortcuts, all of these calculations must be performed at one time or another no matter what algebraic traceline you decide to make.
If you have any questions about specific parts of the traceline just tell me. Also any modern computer can handle this trigger being executed 16 times per second (16xN checks per seconds). My task manger in Windows doesn't even show a noticeable increase in CPU usage when 12 of these tracelines are running at the same time.
EDIT:
Also if you were really afraid of CPU issues, you could remove all events from the trigger and set the trigger as initially off. Then when an event occurs like a Mouse Click for an attacking you could setup the following:
Run Trigger "Traceline" ignoring conditions and WAIT until it finishes. Then continue as normal since your TraceUnit has been found.
Now let's actually make the trigger. So we're going to start with an integer loop. This will be from 1 to N. This is because we are cutting X into N parts and we need to check at each of the N tick marks.
Once the Integer loop is setup, selection the action "If Then Else." Put the following condition in the IF statement "If UnitFound = false." We do this to make sure that we haven't found a unit at any of the previous tick marks.
Now we're going to put an action in the ELSE (not the THEN) part. Put the action "Break." We do this to make sure that if a unit is found at a previous tick mark, that the trigger itself stops searching for more units.
Now go back to the THEN. Everything that we are going to do from here is contained with this THEN. Set z to the picked integer. This keeps track of which tick mark we are checking for units.
Now we need to create a circular region at our tick mark. To do that we need the horizontal distance of our tick mark from the position of the player's camera. So Knowing that we cut X into N parts, then we also cut "u" into N parts (u is the length of the horizontal leg of the triangle). That means each tick mark is a distance of u/N apart, such that the total distance of a specific tick mark from the player's camera is given by z * (u/N).
Now set the region variable "temp reg" equal to Circle with radius "r" at point "p" with polar offset by (z *(u/N)) at angle THETA (facing of the player's camera).
Now set UG equal to all units inside of temp reg. This gives us a collection of units in the region.
Now we're going to check the heights of each unit in this region to ensure they aren't too far above or below our trajectory line. So set h equal to the height of the tick mark from the ground. This is given by z * (v/N). So h = z*(v/N).
Select the "Pick every unit in unit group" action and select UG as the unit group.
Now under that Pick Every Unit action put an "If then Else" and put the two conditions:
If height of Picked Unit is less than h + r
If height of Picked Unit is greater than h - r
We use +/- r in this conditions in order to give us some "breathing room" because the chances of a unit being having the EXACT height of h are practically zero (a unit with height 13.98 wouldn't' be detected if h was 14, so we need the +/- r to give us a more realistic effect).
In the Then command put
Set TraceUnit = Picked Unit
Set UnitFound = True
Break (this stops the traceline from trying to find more units after it found a unit).
In the else command put NOTHING (leave it blank).
Now create a new action outside the Pick Every Unit action (but still within the integer loop) and select IF THEN ELSE and make the condition If UnitFound= false, then set c = z and leave the ELSE command blank again.
Now finally create a new action OUTSIDE the integer loop and add the following IF THEN ELSE
If c < n
Then (leave blank)
Else Set TraceUnit = No unit.
This last part ensures that if no unit is found along the trajectory that our gun doesn't shoot at a random unit. For instance say you were shooting a unit, but turned your camera 90 degrees to the right and started to shoot at nothing, since no new unit was found in the traceline, your gun would accidentally continue shooting at the target 90 degrees to your left since the TraceUnit target wasn't reset to No Unit!
Also, you may notice there are two breaks in this trigger that activate when a unit is found. The first break is in the Pick Every Unit series of actions. This fires to stop the game from checking other units in the unit group. The game then goes back to the top of the trigger and starts at the next value of z in the integer loop. However the condition UnitFound is now equal to true, so it skips to the ELSE part that says "Break." This second Break stops the integer loop, which in turn prevents it from returning to the Pick Every Unit loop.
If a unit is found before the final integer loop completes, then c will always be less than N and therefore the set TraceUNit = no Unit has no way of ever being fired by accident if a unit is found.
This post will explain the individual use of each variable and the concept of the traceline. This post also explains the basic mathematical operations and usages of sine and cosine. The post after this one contains detailed guide on how to put them all together.
The Traceunit variable is [unit] type variable. It is the global variable that the traceline itself is meant to evaluate. The reason we make it a global variable is so we can communicate the detected Traceline target to other in-game triggers.
Theta is a [real] variable. Theta tells us the direction (like north, south, east or west) that the camera for our player is facing. We get this value by setting it equal to the current camera Yaw of our Player.
Phi is a [real] variable. Phi tells us the inclination of the players camera. For instance is he looking 45 degrees above the horizon his pitch would be NEGATIVE 45. In Starcraft 2 and most computer applications POSITIVE PITCH is below the horizon and NEGATIVE PITCH is above the horizon. In more advanced calculations involving quaternions this system is preferable. However for something simple like a traceline this really f***s with the mind, so we'll set Phi equal to -1 x Current Camera Pitch of Player.
X is a [real] variable. It is simply the range of the weapon, or more technically the length of the traceline.
u is a [real] variable. This variable is the Horizontal range of your weapon. If your camera inclination equals zero (looking at the horizon), then u is equal to X. However, suppose your were looking straight up at the sky. Your weapon is going to shoot targets on the horizon if you are looking at the top of the sky! In fact the when you're looking straight up, the horizontal range of your weapon is ZERO. So how do we calculate the horizontal range of your weapon at any camera inclination (other than 0 degrees and 90 degrees). Well those good old days of Junior High School Trig should show us the way!
The range of your weapon is in fact always the same (X) as you increase your camera inclination. The trajectory of your weapon forms a RIGHT TRIANGLE with the ground. The angle between the adjacent leg (ground/horizontal leg) and the hypotenuse is equal to the inclination of the Player Camera, in other words Phi. So in order to calculate the length of the horizontal leg we multiply X by Cosine(Phi). Remember adjacent/hypotenuse = cosine(PHI), so we can cross multiply to get X * (cosine Phi) = u. Thus u = x * (cosine Phi).
v is a [real] variable. This variable complements u. It calculates the maximum height that your weapon will shoot at. If your pointing at the horizon, your weapon won't shoot very high, but if you're looking straight up, your weapon will shoot very high into the air! In this case we are trying to calculate the opposite leg of the right triangle. Opposite/Hypotenuse = sin(Phi) such that v = X * sin(Phi).
N is an [integer] variable. This is an interesting number that controls the accuracy of the traceline. This will control how often we check for the presence of a unit in your line of fire, starting from the position of the player and ending at end of the trajectory of your gun. Basically it takes the length of the trajectory and cuts it into N equal pieces.
Imagine that we put a tick mark (like on a ruler) at each of these points that we "cut" the trajectory line. We are going to create a circular region at each of these points and check to see if there's a unit inside of them. We will start at the first tick mark located next to the player's controlled unit. If we don't find a unit in this circle we move on to the next tick mark and see if there's a unit located in that region. If not, we move on again until we find a unit within a circle around one of the tick marks. If we never find a unit at the end of the trajectory (the circle around the last tick mark) it means that their is no unit in the line of fire.
Ok so how do we do this? Read on!
temp region is a [region] variable. This variable will be used as the circular region that we are temporarily checking for units around a specific tick mark.
r is a [real] variable. This determines the radius of the circle Temp region. We want the circles from one tick mark to the next to overlap for accuracy. So if X is divided into N segments, by setting the radius of each circle to X/N we ensure the the edge of each circle makes contact with the center of the previous circle.
z is an [integer] variable. z will be used to keep track of which Tick Mark we are at.
UG is a [unit group] variable. This variable will be set to the collection of units inside our temp region while checking a specific tick mark.
h is a [real] variable. h determines the height of a tick mark along the trajectory (relative to the ground). If we're shooting at a target in the air, we need to make sure that when we detect a unit in the circular region, that the unit isn't too high or too far below the trajectory line in 3D space. In actuality, when we create circular regions on the ground, we are actually creating 3D cylinders with an infinite height. Thus we need to ignore units that are above or below the trajectory height at the specific Tick Mark we are checking.
To do this we need to calculate the height of the tick mark itself. Thankfully we can use the fact that similar triangles are proportional to each other. We know that X has been cut into N parts, so the height difference between each tick mark is v/N. Thus the height at any particular tick mark (z) is equal to z * (v/N). So h = z * (v/N).
UnitFound is a [boolean] variable. Boolean variables are either True or False. If a unit is found in any of the Checks, we want to set this variable equal to True. This will allow us to STOP the trigger so that it doesn't continue. Once a unit is found, we don't want it to find more units!
c is an [integer] variable. This variable is used if NO UNITS ARE FOUND at the END of the trigger. Basically if c = N at the end of the trigger, then no units were found. In that case we set TraceUnit = No Unit (default. value). Another way of looking at it c is that it records how many failed attempts occurred. After N failed attempts we know there is no unit in the traceline.
I'll give you the general guideline of how to make a 3D traceline. I made a 12-player 3D Traceline function about a year ago with very simple commands (a single trigger that calculated 12 different tracelines per game loop). I'll explain each section BELOW the trigger. It is expected that you have a good conceptual understanding of trigonometry.
Event: Every 0.0625 seconds of game time.
Conditions: None
Global Variables: TraceUnit (unit) = No Unit.
Local Variables:
Theta (real) = current camera Yaw of player
Phi (real) = -1 * Current camera Pitch of Player
X (real) = [Maximum range of gun]
u (real) = X * Cosine(Phi)
v (real) = X * Sin (Phi)
N (integer) = Number of Checks per loop
p (point) = position of player's unit
r (real) = Radius of Check Circle
temp reg (region) = No region
z (integer) = 0
UG (unit group) = [empty unit group]
h (real) = 0
c (integer) = 0
UnitFound (boolean) = false
Actions:
----------Pick Each Integer from 1 to N and do the following:
If UnitFound = false
then do the following chain of actions:
Set z = picked integer
Set temp reg = Circular Region with radius r at Point P with polar offset z * (u / N) at angle THETA.
Set UG = All units in Temp Reg.
Set h = z * (v / N)
-----------------Pick Each Unit in UG and do the following (this is within the integer loop itself)
---If/Then/Else (within the UG loop that is still within the integer loop).
If Height of the Picked Unit > h - r
If Height of the Picked Unit < h + r
Then set TraceUnit = Picked Unit.
Then set UnitFound=True
Break Loop Unit Group Loop.
Else - Do nothing
If Unit Found = false
Then set c = z
else do nothing
------------
Else
Break Integer Loop:
If c < N
then Do nothing
else Set Traceunit = No Unit.
I'm interested in this subject as well, since I need much more than 256x256 for a WWII flight simulation (dogfight) map in a futuristic era! I was thinking of being able to land on your carrier and buy parts/restock ammo/get medical attention and fight the baddies boarding your carrier in a FPS/TPS mode by loading another map. Like you said, there's just not enough space on even a 256x256 map.
EDIT: The portrait on these forums is on of the rooms inside of my "Carrier Ship." The Carrier is currently grounded. You can see some mutalisks outside the window in a Window Transparency test (needless to say the test succeed).
Theres a bug in the editor and i have no idea how to fix it, ive uninstalled / reinstalled multiple times, but to no avail. Every time i move around in the editor, random blakc bars show up on my editorxs terrain, and sometimes turn everthing black for no reason. If anyone knows how to fix this, please tell me, its getting quite annoying.
Trying uninstalling ALL of starcraft, downloading a fresh copy from the Blizzard website and then reinstalling (you can also pre-download a new copy of Starcraft and wait to uninstall your current version until the fresh copy is done downloading). I am assuming it's on your rend since it cannot be replicated no matter how strangely I move around the terrain editor.
So I take it that the other 16 people that viewed the post were able to replicate this bug (it could be a corrupt version of the Starcraft Editor on my part).
Also, I'd definitely prefer if Blizzard avoided making tutorials on how things interact. If the tutorials are strictly technical in that they describe HOW things work, people like me can easily make tutorials explaining how to put the parts together to make cool stuff.
I was impressed with the missile mover tutorials. If you guys want more documentation I would go to the Blizzard forums on that tutorial and thank them personally with a reply so they know we care.
It seems that the action "Set Camera Object Rotation equal to X" does not work when X is greater than 90 or less than -90. Also the function cannot read negative values, so the range of the domain is the function is actually restricted to " 0 < X < 90" and "270< X <360"
EDIT: I also put the following on the Blizzard forums
The domain of the function is BUGGED.
F(x) - Set Camera Object Rotation to x.
0 < x < 90 and 270 < x < 360
It doesn't not accept any negative values, including negative values that when reduced modulo 360 fall within the accepted range. For instance -45 = 335 mod 360, but -45 is not a valid input even though it falls within the 270 < x < 360 congruency.
Currently I'm working on version 3 of my Tech Demo Map and I'm taking on a complete "WoW" style WASD movement with mouse camera control and all. I'm running into a bug which has put a stop this portion of version 3.
The bug: If you adjust the Angle of Attack of a Camera to say, 10, it adjusts the pitch perfectly fine. However if you change the AoA to a number from a VARIABLE it all of a sudden decides it wants to turn Angle of Attack into Roll. Why it does this I have no idea but it's pretty annoying. As you can see in the screenshot below the values are identical from the initial 3rd person view activation shot and the post-mouse control shot. However in the post-most control shot the camera is rolled about 5 degrees.
I'm honored that the creator of my favorite Starcraft 2 custom game replied to my post. I've talked with you in the mafia channel a few times, my name is Solomon.
As a general rule from the Old Warcraft 3 Editor (memory leaks were huge back then), I always remove the unit from the unit group then kill the unit. Sometimes I'll clear a unit group with a periodic trigger such as "Pick every unit and unit Group and remove unit from unit group), mainly because I am afraid of memory leaks, which I believe you are as well.
0
@EdwardSolomon: Go
No one can confirm this bug independently?
0
Would you care to explain how this idea differs from my traceline? Also once my standard traceline detects a target you can simunlate randomess of the projectile with separate triggers. Also most of what you said is generally incoherent. He would have no idea how to build a traceline from what you said, because even I don't know what you said (except that last paragraph that describes how to make a simple traceline which is an exact replica of mine).
You can make the radius of seach circle along the traceline larger as the distance along the traceline increases with the formula r = X/N * f(z) where f(z) is a function of z. This would counter the perspective problem of a narrowing traceline over distance.
Listen, just look at my traceline, ultimately every non-physics based traceline has to do EXACTLY what I did. There are no shortcuts, all of these calculations must be performed at one time or another no matter what algebraic traceline you decide to make.
If you have any questions about specific parts of the traceline just tell me. Also any modern computer can handle this trigger being executed 16 times per second (16xN checks per seconds). My task manger in Windows doesn't even show a noticeable increase in CPU usage when 12 of these tracelines are running at the same time.
EDIT: Also if you were really afraid of CPU issues, you could remove all events from the trigger and set the trigger as initially off. Then when an event occurs like a Mouse Click for an attacking you could setup the following: Run Trigger "Traceline" ignoring conditions and WAIT until it finishes. Then continue as normal since your TraceUnit has been found.
0
Now let's actually make the trigger. So we're going to start with an integer loop. This will be from 1 to N. This is because we are cutting X into N parts and we need to check at each of the N tick marks.
Once the Integer loop is setup, selection the action "If Then Else." Put the following condition in the IF statement "If UnitFound = false." We do this to make sure that we haven't found a unit at any of the previous tick marks.
Now we're going to put an action in the ELSE (not the THEN) part. Put the action "Break." We do this to make sure that if a unit is found at a previous tick mark, that the trigger itself stops searching for more units.
Now go back to the THEN. Everything that we are going to do from here is contained with this THEN. Set z to the picked integer. This keeps track of which tick mark we are checking for units.
Now we need to create a circular region at our tick mark. To do that we need the horizontal distance of our tick mark from the position of the player's camera. So Knowing that we cut X into N parts, then we also cut "u" into N parts (u is the length of the horizontal leg of the triangle). That means each tick mark is a distance of u/N apart, such that the total distance of a specific tick mark from the player's camera is given by z * (u/N).
Now set the region variable "temp reg" equal to Circle with radius "r" at point "p" with polar offset by (z *(u/N)) at angle THETA (facing of the player's camera).
Now set UG equal to all units inside of temp reg. This gives us a collection of units in the region.
Now we're going to check the heights of each unit in this region to ensure they aren't too far above or below our trajectory line. So set h equal to the height of the tick mark from the ground. This is given by z * (v/N). So h = z*(v/N).
Select the "Pick every unit in unit group" action and select UG as the unit group.
Now under that Pick Every Unit action put an "If then Else" and put the two conditions:
If height of Picked Unit is less than h + r
If height of Picked Unit is greater than h - r
We use +/- r in this conditions in order to give us some "breathing room" because the chances of a unit being having the EXACT height of h are practically zero (a unit with height 13.98 wouldn't' be detected if h was 14, so we need the +/- r to give us a more realistic effect).
In the Then command put
Set TraceUnit = Picked Unit
Set UnitFound = True
Break (this stops the traceline from trying to find more units after it found a unit).
In the else command put NOTHING (leave it blank).
Now create a new action outside the Pick Every Unit action (but still within the integer loop) and select IF THEN ELSE and make the condition If UnitFound= false, then set c = z and leave the ELSE command blank again.
Now finally create a new action OUTSIDE the integer loop and add the following IF THEN ELSE
If c < n
Then (leave blank)
Else Set TraceUnit = No unit.
This last part ensures that if no unit is found along the trajectory that our gun doesn't shoot at a random unit. For instance say you were shooting a unit, but turned your camera 90 degrees to the right and started to shoot at nothing, since no new unit was found in the traceline, your gun would accidentally continue shooting at the target 90 degrees to your left since the TraceUnit target wasn't reset to No Unit!
Also, you may notice there are two breaks in this trigger that activate when a unit is found. The first break is in the Pick Every Unit series of actions. This fires to stop the game from checking other units in the unit group. The game then goes back to the top of the trigger and starts at the next value of z in the integer loop. However the condition UnitFound is now equal to true, so it skips to the ELSE part that says "Break." This second Break stops the integer loop, which in turn prevents it from returning to the Pick Every Unit loop.
If a unit is found before the final integer loop completes, then c will always be less than N and therefore the set TraceUNit = no Unit has no way of ever being fired by accident if a unit is found.
0
This post will explain the individual use of each variable and the concept of the traceline. This post also explains the basic mathematical operations and usages of sine and cosine. The post after this one contains detailed guide on how to put them all together.
The Traceunit variable is [unit] type variable. It is the global variable that the traceline itself is meant to evaluate. The reason we make it a global variable is so we can communicate the detected Traceline target to other in-game triggers.
Theta is a [real] variable. Theta tells us the direction (like north, south, east or west) that the camera for our player is facing. We get this value by setting it equal to the current camera Yaw of our Player.
Phi is a [real] variable. Phi tells us the inclination of the players camera. For instance is he looking 45 degrees above the horizon his pitch would be NEGATIVE 45. In Starcraft 2 and most computer applications POSITIVE PITCH is below the horizon and NEGATIVE PITCH is above the horizon. In more advanced calculations involving quaternions this system is preferable. However for something simple like a traceline this really f***s with the mind, so we'll set Phi equal to -1 x Current Camera Pitch of Player.
X is a [real] variable. It is simply the range of the weapon, or more technically the length of the traceline.
u is a [real] variable. This variable is the Horizontal range of your weapon. If your camera inclination equals zero (looking at the horizon), then u is equal to X. However, suppose your were looking straight up at the sky. Your weapon is going to shoot targets on the horizon if you are looking at the top of the sky! In fact the when you're looking straight up, the horizontal range of your weapon is ZERO. So how do we calculate the horizontal range of your weapon at any camera inclination (other than 0 degrees and 90 degrees). Well those good old days of Junior High School Trig should show us the way!
The range of your weapon is in fact always the same (X) as you increase your camera inclination. The trajectory of your weapon forms a RIGHT TRIANGLE with the ground. The angle between the adjacent leg (ground/horizontal leg) and the hypotenuse is equal to the inclination of the Player Camera, in other words Phi. So in order to calculate the length of the horizontal leg we multiply X by Cosine(Phi). Remember adjacent/hypotenuse = cosine(PHI), so we can cross multiply to get X * (cosine Phi) = u. Thus u = x * (cosine Phi).
v is a [real] variable. This variable complements u. It calculates the maximum height that your weapon will shoot at. If your pointing at the horizon, your weapon won't shoot very high, but if you're looking straight up, your weapon will shoot very high into the air! In this case we are trying to calculate the opposite leg of the right triangle. Opposite/Hypotenuse = sin(Phi) such that v = X * sin(Phi).
N is an [integer] variable. This is an interesting number that controls the accuracy of the traceline. This will control how often we check for the presence of a unit in your line of fire, starting from the position of the player and ending at end of the trajectory of your gun. Basically it takes the length of the trajectory and cuts it into N equal pieces.
Imagine that we put a tick mark (like on a ruler) at each of these points that we "cut" the trajectory line. We are going to create a circular region at each of these points and check to see if there's a unit inside of them. We will start at the first tick mark located next to the player's controlled unit. If we don't find a unit in this circle we move on to the next tick mark and see if there's a unit located in that region. If not, we move on again until we find a unit within a circle around one of the tick marks. If we never find a unit at the end of the trajectory (the circle around the last tick mark) it means that their is no unit in the line of fire.
Ok so how do we do this? Read on!
temp region is a [region] variable. This variable will be used as the circular region that we are temporarily checking for units around a specific tick mark.
r is a [real] variable. This determines the radius of the circle Temp region. We want the circles from one tick mark to the next to overlap for accuracy. So if X is divided into N segments, by setting the radius of each circle to X/N we ensure the the edge of each circle makes contact with the center of the previous circle.
z is an [integer] variable. z will be used to keep track of which Tick Mark we are at.
UG is a [unit group] variable. This variable will be set to the collection of units inside our temp region while checking a specific tick mark.
h is a [real] variable. h determines the height of a tick mark along the trajectory (relative to the ground). If we're shooting at a target in the air, we need to make sure that when we detect a unit in the circular region, that the unit isn't too high or too far below the trajectory line in 3D space. In actuality, when we create circular regions on the ground, we are actually creating 3D cylinders with an infinite height. Thus we need to ignore units that are above or below the trajectory height at the specific Tick Mark we are checking.
To do this we need to calculate the height of the tick mark itself. Thankfully we can use the fact that similar triangles are proportional to each other. We know that X has been cut into N parts, so the height difference between each tick mark is v/N. Thus the height at any particular tick mark (z) is equal to z * (v/N). So h = z * (v/N).
UnitFound is a [boolean] variable. Boolean variables are either True or False. If a unit is found in any of the Checks, we want to set this variable equal to True. This will allow us to STOP the trigger so that it doesn't continue. Once a unit is found, we don't want it to find more units!
c is an [integer] variable. This variable is used if NO UNITS ARE FOUND at the END of the trigger. Basically if c = N at the end of the trigger, then no units were found. In that case we set TraceUnit = No Unit (default. value). Another way of looking at it c is that it records how many failed attempts occurred. After N failed attempts we know there is no unit in the traceline.
0
@AtikLYar
I'll give you the general guideline of how to make a 3D traceline. I made a 12-player 3D Traceline function about a year ago with very simple commands (a single trigger that calculated 12 different tracelines per game loop). I'll explain each section BELOW the trigger. It is expected that you have a good conceptual understanding of trigonometry.
Event: Every 0.0625 seconds of game time.
Conditions: None
Global Variables: TraceUnit (unit) = No Unit.
Local Variables:
Theta (real) = current camera Yaw of player
Phi (real) = -1 * Current camera Pitch of Player
X (real) = [Maximum range of gun]
u (real) = X * Cosine(Phi)
v (real) = X * Sin (Phi)
N (integer) = Number of Checks per loop
p (point) = position of player's unit
r (real) = Radius of Check Circle
temp reg (region) = No region
z (integer) = 0
UG (unit group) = [empty unit group]
h (real) = 0
c (integer) = 0
UnitFound (boolean) = false
Actions:
----------Pick Each Integer from 1 to N and do the following:
If UnitFound = false
then do the following chain of actions:
Set z = picked integer
Set temp reg = Circular Region with radius r at Point P with polar offset z * (u / N) at angle THETA.
Set UG = All units in Temp Reg.
Set h = z * (v / N)
-----------------Pick Each Unit in UG and do the following (this is within the integer loop itself)
---If/Then/Else (within the UG loop that is still within the integer loop).
If Height of the Picked Unit > h - r
If Height of the Picked Unit < h + r
Then set TraceUnit = Picked Unit.
Then set UnitFound=True
Break Loop Unit Group Loop.
Else - Do nothing
If Unit Found = false
Then set c = z
else do nothing
------------
Else
Break Integer Loop:
If c < N
then Do nothing
else Set Traceunit = No Unit.
0
@Terhonator: Go
I'm interested in this subject as well, since I need much more than 256x256 for a WWII flight simulation (dogfight) map in a futuristic era! I was thinking of being able to land on your carrier and buy parts/restock ammo/get medical attention and fight the baddies boarding your carrier in a FPS/TPS mode by loading another map. Like you said, there's just not enough space on even a 256x256 map.
EDIT: The portrait on these forums is on of the rooms inside of my "Carrier Ship." The Carrier is currently grounded. You can see some mutalisks outside the window in a Window Transparency test (needless to say the test succeed).
0
Trying uninstalling ALL of starcraft, downloading a fresh copy from the Blizzard website and then reinstalling (you can also pre-download a new copy of Starcraft and wait to uninstall your current version until the fresh copy is done downloading). I am assuming it's on your rend since it cannot be replicated no matter how strangely I move around the terrain editor.
0
So I take it that the other 16 people that viewed the post were able to replicate this bug (it could be a corrupt version of the Starcraft Editor on my part).
0
I agree with this.
0
@Tolkfan: Go
I was impressed with the missile mover tutorials. If you guys want more documentation I would go to the Blizzard forums on that tutorial and thank them personally with a reply so they know we care.
0
It seems that the action "Set Camera Object Rotation equal to X" does not work when X is greater than 90 or less than -90. Also the function cannot read negative values, so the range of the domain is the function is actually restricted to " 0 < X < 90" and "270< X <360"
EDIT: I also put the following on the Blizzard forums
The domain of the function is BUGGED.
F(x) - Set Camera Object Rotation to x.
0 < x < 90 and 270 < x < 360
It doesn't not accept any negative values, including negative values that when reduced modulo 360 fall within the accepted range. For instance -45 = 335 mod 360, but -45 is not a valid input even though it falls within the 270 < x < 360 congruency.
0
I now confirm this bug (how I came across it)
0
@DarkRevenantX: Go
I'm honored that the creator of my favorite Starcraft 2 custom game replied to my post. I've talked with you in the mafia channel a few times, my name is Solomon.
0
@zeldarules28: Go
As a general rule from the Old Warcraft 3 Editor (memory leaks were huge back then), I always remove the unit from the unit group then kill the unit. Sometimes I'll clear a unit group with a periodic trigger such as "Pick every unit and unit Group and remove unit from unit group), mainly because I am afraid of memory leaks, which I believe you are as well.
0
@Kueken531: Go
Precisely what I needed. Here's the demo of what I made.