Skybox support (per player). Right now I have 20 different triggers using GAx3 mod in order to make skyboxes. I have to set teh farclip to outrageous numbers to see the sky box without scaling the skybox model down.

First... I knew exactly what i was talking about and when someone is trying to help you, you dont insult them, unless you come from trash that is very rude.

Second... The actor is called Power Duplicate it twice and one go to the events and do this

Behavior.(Your First range behavior).Start Create

Behavior.(Your First Range Power behavior).Destory Destroy

on the second Behavior.(Your Second range behavior).Start Create

Behavior.(Your 2nd Range Power behavior).Destory Destroy

on your third. Behavior.(Your Third range behavior).Start Create

Behavior.(Your Third Range Power behavior).Destory Destroy

.. There ya go... since you wanna play stupid, but dont wanna take the advice given.

No, some of you SC2 mapster people act like assholes, even though you do it by accident ... unintentionally ... I share the OP's sentiment. I also thought the same thing when I read that response of yours.

There are some member's that I visually ignore, no matter what they type.

Today I will show you how to make a memory efficient traceline function (as efficient as a traceline can be in SC2). Not only is it efficient, but it uses a quadratic regression function in order to greatly increase it's accuracy. So let's get started! We'll start with the theory behind this traceline (before memory optimization).

First of all, conventional traceline algorithms should NEVER be used in SC2. A conventional traceline would check a small region for units in the camera's direction, many many times. The reason why this fails in SC2 is because each time you check a region for units, SC2 goes through EVERY unit in the game to see whether or not it is in that region. So if you have 1000 units in the game, and you check 50 regions sequentially (over a 1/16 second time period), your computer now does a total of 50,000 checks in 1/16th a second, disregarding every other part of the traceline function.

As a result of this, many SC2 map makers have run far away from tracelines, and rightfully so. However, so times it would be really nice to just have a damn traceline for many things, instead of making a different workaround for each weapon/spell/ability/etc.

So our mission is to make a traceline function, that could easily handle 1000 enemy units on the map, performing no more than 2000 checks.

First, we create Unit Group A equal to "All units on map belonging to player K." We are assuming that player K is the enemy player/computer.

Next, we severely reduce the size of this group with a *range* check to the position of the player's camera. We do NOT want to use the square root function. Number one, it's really memory inefficient; number two, the square root doesn't work well with quadratic regression later on. So here's how we do this.

Let R be the maximum range of the weapon. PointP = Position of Player's Camera, Let PX = X of P, Let PY = Y of P.
Then "For each Unit in Unit Group A, Set PointQ = Position of Picked Unit, QX = X of Q, QY = Y of Q"
Then " If (QX - PX)^2 + (QY-PY)^2 < R^2, then Add Picked Unit to Unit Group B, else [blank/do nothing]

Assuming an even distribution of units about the map, you just reduced the size of Group A by (Area of map/R^2). So if I had 256x256 map and R = 30, then I just reduced the size of Group A by a factor of 23, which is now Group B. So now we're only looking at (1000/23) units or 43 units on average in Group B.

See Diagram B

Next, we want to take Group B, which consists of all enemy units in a circular region centered at PointP, and eliminate them by comparing their 2D angle to PointP to the Camera Yaw of the player. This is the crucial step where quadratic regression is included to increase accuracy' however, I'll add it in in the appendix after the general theory is presented. So the next part:

Pick each Unit in Unit Group B and:
Set PointQ = position of picked Unit
Set Theta = angle between PointP and PointQ
If (Absolute value[Camera Yaw of Player - Theta] < AngleCheck
Then Add Picked Unit Group to Unit Group C, else blank/do nothing

In the above, angle check is an arbitrary number that you choose for the accuracy. So if angle check = 10 degrees, then Unit Group C will consist of all units from Unit Group B that were in a +/- 10 degrees wedge (total of 20 degrees) from the yaw of the camera.

See Diagram C

By doing this, you reduce the size of Unit Group B by a factor of (360/(2*AngleCheck)) on average. So if AngleCheck = 3 degrees, I just reduced the size of Group B by (360/(2*3)) = 60. So the size of B was 43, now it's 3/4 a unit. This means if we spun our camera wildly, there's only a 75% chance that there's even a single unit in our +/- 3 wedge within a circle of radius 30 (assuming even unit distribution about the map). In reality, our player is probably pointing his camera at a group of units, however, even in realistic scenarios, I rarely get more than 10 units in Unit Group C.

Now we want to reduce Unit Group C even more, we're going to eliminate units by comparing their inclination to the inclination of our camera. However, we must be wary, as we must obtain the ABSOLUTE HEIGHT of units when doing this, and then further adjust for the height of our camera and the graphical height of the actors of the enemy units.

First off, what is the absolute height of a unit? It's the Ground Height of where the ground unit is located + the height of the unit OR the Air Height of where the air unit is located + the height of the unit.

Why is absolute height important? Because you cannot compare the heights of two units directly, by simply looking at their unit heights (unless your ENTIRE map is flat and they are all ground units, which would be a very boring map). So, when we check the inclinations of units in Group C, we need to do it in respect to absolute heights. Here is how we proceed with inclination check:

Pick each unit in Unit Group C:
Set PointQ = Position of Picked unit
Set D = distance between PointP and PointQ (we don't care about square root function anymore, since it's sparingly used at this stage)
Set G = [Ground Height at PointP + Camera Height Offset of Player]
If Picked unit can be targeted as Ground then set M = Ground Height at PointQ, else set M = Air Height at PointQ
Set H = [M + Height of Picked Unit + K] where K is your own fudge factor, to be safe set K = 1.5 (more info below on K)
If D not equal to zero then Set Rho = Arctan { (H-G)/D },
else [ If H - G > 0, then set Rho = 90, else set Rho = -90 ]
If (Absolute Value (Camera Pitch of Player - Rho) < Angle Check
Then Add Picked Unit to Unit Group D, else blank/do nothing.

K simply raises the actual height of your unit from the ground a little bit to get the visually perceived height. For instance, an ultralisk is a big unit, about two starcraft distance units tall. However, if you're looking at it's midriff, your traceline probably won't pick it up, because the traceline will calculate it's inclination using the absolute height at the Ultralisk's feet, not its torso. So we add a fudge factor of 1.5 to make up for this. I personally use a Custom Unit Value (depending of type of unit) for this fudge factor. So ultralisks get 1.5 for their K, for marines only get 0.5.

So now we've just taken all the units in Unit Group C, and reduced them further, by an average factor of (180/(2*AngleCheck)). This factor comes from the fact that Pitch is bounded from -90 to 90, or a total range of 180, of which only a range of +/- AngleCheck degrees are valid. So if angle check = 3, then we just reduced the size of Unit Group C by a factor of 30, with a 1000 units on the map, this gives us a only a 2.5% chance of having a unit in our sights if we spin the camera randomly.

See Diagram D

We're now ready to get our Trace Target. Here we go (although we need to calculate how many units are in Unit Group D first):

Add the integer variable named Size to your local variable list.
Pick Each Unit in Unit Group D and
Set Size = Size + 1

Great, now we have the size of Unit Group D (cardinality). Let's move on to getting our trace target:

If Size is NOT equal to zero,
then Set TraceTarget = Nearest Unit in Unit Group D to PointP.
else Set Trace Target = No Unit

You're done! Personally, when Size = 0, I set Trace Target to an invisible dummy unit located at the end of my view range at the pitch/yaw of my camera. You'll be able to see this result in the version I copy and paste here. -----------------------

APPENDIX:
So, what is quadratic regression? It's a quadratic equation that approximates a sequential set of points. how if this relevant to a traceline function? Well, remember our Angle Check? Suppose we have an angle check of 5 degrees. However, there is a unit VERY close to our camera, nearly taking up half the screen. If I shoot at the sides of this unit (not the center), my traceline will not pick it up, causing me to miss, even though I'm clearly shooting the damn unit. This means I should probably increase my AngleCheck limit for units that are VERY close to me.

However, consider the reverse situation: There's a unit very far away, only a pinprick on my screen, but when I shoot near him (but not directly 100% at him), my traceline still picks him up, almost acting like an aim assist. I guess this means I should decrease my AngleCheck limit for units that are Very far from me.

So now we have to account for three scenarios: 1 the Unit is CLOSE, the unit is FAR, or the unit is in between those extremes. According to where he is, we need to adjust our AngleCheck value. Let's set our BASE value for AngleCheck to 3 degrees. With some experimentation, assuming a maximum range of 50 (instead of 30 like earlier) we notice the following:

For units VERY CLOSE to us, we want Angle Check to be approximately 9 degrees, which is 3 times larger.

For units Very Far from us, we want Angle Check to be approximately 0.7 degrees

But in general, any AngleCheck from 2 to 5 degrees is generally ok for most distances. We will define "Very Far" as 50, and Very Near as 0. However, we're going to use the square of our distance, so "Very Far" squared is 2500. Below are the results we are trying to achieve:

We set a value for which we want AngleCheck(modified) to equal 3. It's best to choose your (MaxRange/2)^2, which equals 625 in this case. We're also, for the sake of simplicity, going to want our desired result at 2500 to be 0 degrees, instead of 0.7

Ok, if we run a quadratic regression from a calculator, we get a pretty crappy result, so we make this plot symmetrical over x = 2500 by adding two more values:

Always has the regression formula
(2x)/(R^4) - 4x/(R^2) + 2.2

I like to factor the first two terms, to get this cleaner result:

y = (2x/R^2) * (x/R^2 - 2) + 2.2

So what does this regression formula mean for our traceline? Well, when we're comparing a unit in Unit Group B to our AngleCheck, before moving it into to Unit Group C, we're going to modify the limit of the angle check by a factor of (2x/R^2) * (x/R^2 - 2) + 2.2, where x = square of distance between PointP and PointQ.

This has the advantage of avoiding the square root to begin with, and simultaneously producing a more accurate traceline than a linear regression. The reason quadratic regression is perfect, is because each time the distance between you and a unit is doubled, it's 2D image on the screen has both it's dimensions halved, meaning it's area decrease by 1/4. So in other words, as a unit becomes farther away, it's area of its image decreases by the inverse square, thus making the quadratic model superior to the linear model.

This trigger works alongside another periodic trigger which simply cycles an integer variable through modulus 4 and updates Alpha Group (global variable) once every second (once per four quarter seconds):

This allows me to create dummy units that remain in the game long enough for my traceline to shoot at, while also allowing me to remove them from the game in staggered cycles, in order to not clutter the game).

If you see any areas of code that could be optimized further, please reply below.

Also, if you find alternate regression models to achieve different accuracy results, please share them!

EDIT:

I tested CPU usage using this traceline function vs a conventional traceline.

With AMD Phenom II x4 955 3.20 Ghz (normal clocking) using a well air cooling system and only one NVIDIA 560gtx (average gaming computer), the CPU temps averaged 41 Celsius with a conventional traceline function. Using my function instead the temperature averaged at 39 Celsius.

When running 12 of these tracelines at a same (for 12 players) we get 45 Celsius vs 40 Celsius, looks like a good deal to me!

Also, in the multiplayer test, the square root function in Unit Group D to TraceTarget was replaced by sorting algorithm to determine the nearest unit using the square of their distances instead of the actual distance. Also, instead of creating Unit Group A twelve times (one for each player), since Unit Group A contains All units on the map belonging to some player K, it is only created once, and the same Unit Group A is used for determining the respective Unit Group B for each player.

If you want a very simple Terrain Collision check for your TraceTarget, let me know.

Through data is it not possible as far as I know. Through triggers is it possible, as the second poster said. Do a search for GAx3 which is a trigger library that among other things allows you to send actor messages to only one player, and therefore you can tell a actor for only one player to be invisible (100% opacity or something).

I'm going to find the author of GAx3, buy a plane ticket, become gay for a day and blow him.

Better way: Set all Allied Players Alliance State to Neutral.

Make each model perma cloak. GG

Now, all I need to do is find the actor/effect that changes the opacity and color of the actor when it's cloaked, and make it have zero effect and we're golden

The final response to the OP in the above thread is very interesting:

"You can do this actor cration, ViewerTreatsUnitAs(Detected) Then signal through that actor to your main actor. Just look at how hallucinate signals. Its kinda complex cause its not fully implemented and gotta bug the editor a bit... probably shouldn't of said anything. I am sorry for posting that, which did seem like trolling."

Basically there's a way using hallucination/changelings to display different actors to different players.

0

@Eiviyn: Go

Skybox support (per player). Right now I have 20 different triggers using GAx3 mod in order to make skyboxes. I have to set teh farclip to outrageous numbers to see the sky box without scaling the skybox model down.

0

Look through the variations of "Castanar Work Station" and "Vahalla Work Station."

Make sure you zoom in real close to the monitors, here's one sample (attached):

0

No, some of you SC2 mapster people act like assholes, even though you do it by accident ... unintentionally ... I share the OP's sentiment. I also thought the same thing when I read that response of yours.

There are some member's that I visually ignore, no matter what they type.

0

@EdwardSolomon: Go

:(

0

I've been using this editor since 2010, and I never noticed Object Groups...ever...

I've seem to get along fine without them so far, does anyone know of their practical uses?

0

Hello SC2 Mapster!

Today I will show you how to make a memory efficient traceline function (as efficient as a traceline can be in SC2). Not only is it efficient, but it uses a quadratic regression function in order to greatly increase it's accuracy. So let's get started! We'll start with the theory behind this traceline (before memory optimization).

First of all, conventional traceline algorithms should NEVER be used in SC2. A conventional traceline would check a small region for units in the camera's direction, many many times. The reason why this fails in SC2 is because each time you check a region for units, SC2 goes through EVERY unit in the game to see whether or not it is in that region. So if you have 1000 units in the game, and you check 50 regions sequentially (over a 1/16 second time period), your computer now does a total of 50,000 checks in 1/16th a second, disregarding every other part of the traceline function.

As a result of this, many SC2 map makers have run far away from tracelines, and rightfully so. However, so times it would be really nice to just have a damn traceline for many things, instead of making a different workaround for each weapon/spell/ability/etc.

So our mission is to make a traceline function, that could easily handle 1000

enemyunits on the map, performing no more than 2000 checks.First, we create Unit Group A equal to "All units on map belonging to player K." We are assuming that player K is the enemy player/computer.

Next, we severely reduce the size of this group with a *range* check to the position of the player's camera. We do NOT want to use the square root function. Number one, it's really memory inefficient; number two, the square root doesn't work well with quadratic regression later on. So here's how we do this.

Let R be the maximum range of the weapon. PointP = Position of Player's Camera, Let PX = X of P, Let PY = Y of P.

Then "For each Unit in Unit Group A, Set PointQ = Position of Picked Unit, QX = X of Q, QY = Y of Q"

Then " If (QX - PX)^2 + (QY-PY)^2 < R^2, then Add Picked Unit to Unit Group B, else [blank/do nothing]

Assuming an even distribution of units about the map, you just reduced the size of Group A by (Area of map/R^2). So if I had 256x256 map and R = 30, then I just reduced the size of Group A by a factor of 23, which is now Group B. So now we're only looking at (1000/23) units or 43 units on average in Group B.

See Diagram B

Next, we want to take Group B, which consists of all enemy units in a circular region centered at PointP, and eliminate them by comparing their 2D angle to PointP to the Camera Yaw of the player. This is the crucial step where quadratic regression is included to increase accuracy' however, I'll add it in in the appendix after the general theory is presented. So the next part:

Pick each Unit in Unit Group B and:

Set PointQ = position of picked Unit

Set Theta = angle between PointP and PointQ

If (Absolute value[Camera Yaw of Player - Theta] < AngleCheck

Then Add Picked Unit Group to Unit Group C, else blank/do nothing

In the above, angle check is an arbitrary number that you choose for the accuracy. So if angle check = 10 degrees, then Unit Group C will consist of all units from Unit Group B that were in a +/- 10 degrees wedge (total of 20 degrees) from the yaw of the camera.

See Diagram C

By doing this, you reduce the size of Unit Group B by a factor of (360/(2*AngleCheck)) on average. So if AngleCheck = 3 degrees, I just reduced the size of Group B by (360/(2*3)) = 60. So the size of B was 43, now it's 3/4 a unit. This means if we spun our camera wildly, there's only a 75% chance that there's even a single unit in our +/- 3 wedge within a circle of radius 30 (assuming even unit distribution about the map). In reality, our player is probably pointing his camera at a group of units, however, even in realistic scenarios, I rarely get more than 10 units in Unit Group C.

Now we want to reduce Unit Group C even more, we're going to eliminate units by comparing their inclination to the inclination of our camera. However, we must be wary, as we must obtain the ABSOLUTE HEIGHT of units when doing this, and then further adjust for the height of our camera and the graphical height of the actors of the enemy units.

First off, what is the absolute height of a unit? It's the Ground Height of where the ground unit is located + the height of the unit OR the Air Height of where the air unit is located + the height of the unit.

Why is absolute height important? Because you cannot compare the heights of two units directly, by simply looking at their unit heights (unless your ENTIRE map is flat and they are all ground units, which would be a very boring map). So, when we check the inclinations of units in Group C, we need to do it in respect to absolute heights. Here is how we proceed with inclination check:

Pick each unit in Unit Group C:

Set PointQ = Position of Picked unit

Set D = distance between PointP and PointQ (we don't care about square root function anymore, since it's sparingly used at this stage)

Set G = [Ground Height at PointP + Camera Height Offset of Player]

If Picked unit can be targeted as Ground then set M = Ground Height at PointQ, else set M = Air Height at PointQ

Set H = [M + Height of Picked Unit + K] where K is your own fudge factor, to be safe set K = 1.5 (more info below on K)

If D not equal to zero then Set Rho = Arctan { (H-G)/D },

else [ If H - G > 0, then set Rho = 90, else set Rho = -90 ]

If (Absolute Value (Camera Pitch of Player - Rho) < Angle Check

Then Add Picked Unit to Unit Group D, else blank/do nothing.

K simply raises the actual height of your unit from the ground a little bit to get the visually perceived height. For instance, an ultralisk is a big unit, about two starcraft distance units tall. However, if you're looking at it's midriff, your traceline probably won't pick it up, because the traceline will calculate it's inclination using the absolute height at the Ultralisk's feet, not its torso. So we add a fudge factor of 1.5 to make up for this. I personally use a Custom Unit Value (depending of type of unit) for this fudge factor. So ultralisks get 1.5 for their K, for marines only get 0.5.

So now we've just taken all the units in Unit Group C, and reduced them further, by an average factor of (180/(2*AngleCheck)). This factor comes from the fact that Pitch is bounded from -90 to 90, or a total range of 180, of which only a range of +/- AngleCheck degrees are valid. So if angle check = 3, then we just reduced the size of Unit Group C by a factor of 30, with a 1000 units on the map, this gives us a only a 2.5% chance of having a unit in our sights if we spin the camera randomly.

See Diagram D

We're now ready to get our Trace Target. Here we go (although we need to calculate how many units are in Unit Group D first):

Add the integer variable named Size to your local variable list.

Pick Each Unit in Unit Group D and

Set Size = Size + 1

Great, now we have the size of Unit Group D (cardinality). Let's move on to getting our trace target:

If Size is NOT equal to zero,

then Set TraceTarget = Nearest Unit in Unit Group D to PointP.

else Set Trace Target = No Unit

You're done! Personally, when Size = 0, I set Trace Target to an invisible dummy unit located at the end of my view range at the pitch/yaw of my camera. You'll be able to see this result in the version I copy and paste here.

~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~--~~APPENDIX:

So, what is quadratic regression? It's a quadratic equation that approximates a sequential set of points. how if this relevant to a traceline function? Well, remember our Angle Check? Suppose we have an angle check of 5 degrees. However, there is a unit VERY close to our camera, nearly taking up half the screen. If I shoot at the sides of this unit (not the center), my traceline will not pick it up, causing me to miss, even though I'm clearly shooting the damn unit. This means I should probably increase my AngleCheck limit for units that are VERY close to me.

However, consider the reverse situation: There's a unit very far away, only a pinprick on my screen, but when I shoot near him (but not directly 100% at him), my traceline still picks him up, almost acting like an aim assist. I guess this means I should decrease my AngleCheck limit for units that are Very far from me.

So now we have to account for three scenarios: 1 the Unit is CLOSE, the unit is FAR, or the unit is in between those extremes. According to where he is, we need to adjust our AngleCheck value. Let's set our BASE value for AngleCheck to 3 degrees. With some experimentation, assuming a maximum range of 50 (instead of 30 like earlier) we notice the following:

For units VERY CLOSE to us, we want Angle Check to be approximately 9 degrees, which is 3 times larger.

For units Very Far from us, we want Angle Check to be approximately 0.7 degrees

But in general, any AngleCheck from 2 to 5 degrees is generally ok for most distances. We will define "Very Far" as 50, and Very Near as 0. However, we're going to use the square of our distance, so "Very Far" squared is 2500. Below are the results we are trying to achieve:

Range^2::::::::AngleCheck(modified)

0::::::::::::::::::9 degrees

2500::::::::::::0.7 degrees

We set a value for which we want AngleCheck(modified) to equal 3. It's best to choose your (MaxRange/2)^2, which equals 625 in this case. We're also, for the sake of simplicity, going to want our desired result at 2500 to be 0 degrees, instead of 0.7

Range^2:::::::AngleCheck(modified)

0:::::::::::::::::9 degrees

625::::::::::::: 3 degrees

2500:::::::::::: 0 degrees

Ok, if we run a quadratic regression from a calculator, we get a pretty crappy result, so we make this plot symmetrical over x = 2500 by adding two more values:

Range^2 :::::AngleCheck(modified)

0::::::::::::: 9 degrees

625:::::::::::: 3 degrees

2500:::::::::::0 degrees

(2500-625):::3 degrees

2(2500)::::::::9 degrees

Since AngleCheck = 3, before modification, let's divide all of this by 3 then:

Range^2 :::::: AngleCheck(modified)

0:::::::::::::::::3 degrees

625::::::::::::: 1 degree

2500::::::::::: 0 degrees

(2500-625) ::1 degree

2(2500) :::::: 3 degrees

If we run a quadratic regression now, we get a pretty formula for this (above diagram):

(2*x^2)/(50^4) - 4x/(50^2) +2.2

In fact, no matter what your Maximum range is, Let R = Maximum Range, the chart:

Range^2::::::AngleCheck(modified)

0:::::::::::::::::3 degrees

(1/4)(R^2)::::::1 degree

R^2::::::::::::: 0 degrees

(7/4)R^2 ::::::1 degree

2(R^2):::::::::: 3 degrees

Always has the regression formula

(2

x)/(R^4) - 4x/(R^2) + 2.2I like to factor the first two terms, to get this cleaner result:

y = (2

x/R^2) * (x/R^2 - 2) + 2.2So what does this regression formula mean for our traceline? Well, when we're comparing a unit in Unit Group B to our AngleCheck, before moving it into to Unit Group C, we're going to modify the limit of the angle check by a factor of (2

x/R^2) * (x/R^2 - 2) + 2.2, wherex= square of distance between PointP and PointQ.This has the advantage of avoiding the square root to begin with, and simultaneously producing a more accurate traceline than a linear regression. The reason quadratic regression is perfect, is because each time the distance between you and a unit is doubled, it's 2D image on the screen has both it's dimensions halved, meaning it's area decrease by 1/4. So in other words, as a unit becomes farther away, it's area of its image decreases by the inverse square, thus making the quadratic model superior to the linear model.

~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~-~~~~--~~Here's what my TraceLine Looks like

This trigger works alongside another periodic trigger which simply cycles an integer variable through modulus 4 and updates Alpha Group (global variable) once every second (once per four quarter seconds):

This allows me to create dummy units that remain in the game long enough for my traceline to shoot at, while also allowing me to remove them from the game in staggered cycles, in order to not clutter the game).

0

The tutorial starts in this post below.

If you see any areas of code that could be optimized further, please reply below.

Also, if you find alternate regression models to achieve different accuracy results, please share them!

EDIT:

I tested CPU usage using this traceline function vs a conventional traceline.

With AMD Phenom II x4 955 3.20 Ghz (normal clocking) using a well air cooling system and only one NVIDIA 560gtx (average gaming computer), the CPU temps averaged 41 Celsius with a conventional traceline function. Using my function instead the temperature averaged at 39 Celsius.

When running 12 of these tracelines at a same (for 12 players) we get 45 Celsius vs 40 Celsius, looks like a good deal to me!

Also, in the multiplayer test, the square root function in Unit Group D to TraceTarget was replaced by sorting algorithm to determine the nearest unit using the square of their distances instead of the actual distance. Also, instead of creating Unit Group A twelve times (one for each player), since Unit Group A contains All units on the map belonging to some player K, it is only created once, and the same Unit Group A is used for determining the respective Unit Group B for each player.

If you want a very simple Terrain Collision check for your TraceTarget, let me know.

0

Does anyone know you how create a Gun in an FPS?

For instance, get get crosshairs I can load an overlay image with triggers, but how does one get a gun and it's attack animations?

0

@zandose: Go

That's makes it easy then, I have a PhD in linguistics, and some say I'm cunning

0

I'm going to find the author of GAx3, buy a plane ticket, become gay for a day and blow him.

0

@EdwardSolomon: Go

Better way: Set all Allied Players Alliance State to Neutral.

Make each model perma cloak. GG

Now, all I need to do is find the actor/effect that changes the opacity and color of the actor when it's cloaked, and make it have zero effect and we're golden

0

@EdwardSolomon: Go

The final response to the OP in the above thread is very interesting:

"You can do this actor cration, ViewerTreatsUnitAs(Detected) Then signal through that actor to your main actor. Just look at how hallucinate signals. Its kinda complex cause its not fully implemented and gotta bug the editor a bit... probably shouldn't of said anything. I am sorry for posting that, which did seem like trolling."

Basically there's a way using hallucination/changelings to display different actors to different players.

0

@EdwardSolomon: Go

However, I did find this link, I'll give it a shot.

http://us.battle.net/sc2/en/forum/topic/2191101410

0

@DrSuperEvil: Go

I checked "ally" on the marine actor filter. However, I can still see enemy marines when I load the map.

Then I changed it and checked "enemy" nothing different. Can still see enemy marines.

0

@EdwardSolomon: Go

Also, Thanksgiving and starcraft 2 mapster dont' mix :(