I have created a demo map to demonstrate a method in creating kill streak tracking for only a specific unit.
The way it works is like this
(In this demo, I used 4 seconds as the Kill Streak Timer - meaning the unit has to kill every 4 seconds to keep the streak going)
When a unit is killed, check to see if Killing Unit is the unit we'd like to do kill streaks for
If it is, then start a timer that expires in a few seconds.
This timer, when it expires, will set the kill streak to 0 and end the streak altogethe.
If, however, before the timer expires, the unit kills again, the timer resets, and the kill streak goes up by 1, and the timer is reset back to it's default countdown time, and it grants the unit another 4 seconds to kill again.
If the unit takes more than 4 seconds to kill another unit, though, the timer expires, and resets the Kill Streak back to 0.
I also added a little visual cue so that it is more obvious when you kill a unit. On the left (in the Debug Message Area), I also added some text to show how large the kill streak is.
If you have anymore questions just post them and I'll be happy to answer them!
I would start with going into the Data Editor and turning on for the ball "Ignore Terrain Height", for starters.
Change the Ball unit's acceleration to As High as it can go, Deceleration also as High as it can go.
In the Trigger Editor, create these Global variables:
XYAngle<real>XYSpeed<real>ZSpeed<real>
Make some Constants that you will use for Decelerating the ball, to make sure that it does not just roll forever everywhere, and actually make it seem real.
I've attached another map that has comments in the Code, so go ahead and give that a read - the code works for all types of structures - Orbitals, Infestation Pits, etc. (And I put a few of them on the map).
As far as the bit about arrays:
Imagine you made a map, that had 8 players, and they each had to ... kill One Zergling on the map. Since you now know how to create global objective variables, you might create 8 Individual varaibles like this....
Then, inside your Unit Dies Trigger, you would have to use an If Then Else statements (like 8 of them) to check what player killed a Zergling, and then set their objective to complete (only for that one player).
The easy way to do it would be using an Array. Arrays are sort of like "Lists" of variables. You set the maximum different items there are in the "List" by change the "Size" parameter of an Array variable. SO , the easier way to do this would be creating One Array variable with the size of 8:
ObjectiveKillZergling[8]
Now, the Huge advantage about arrays is that you can, instead of putting a number between the "[ ]" braces, you can put a variable, or a math equation, or any number. Before, in the example above, I was discussing a Trigger that checks every time a Zergling dies. Imagine if your long Trigger from up there, with 8 IF THEN ELSE statements was changed simply one line of code, this:
I attached a map in the style of a single-player campaign map. Open it up, give it a test run, but definitely read through the Triggers. I put a lot of comments in there for you to help you understand the process in how we make these types of objectives, make them compete when certain things happen, and all the rest of it. It really is pretty simple.
Orbital Killed Objective:
Let's say there are 6 possible players:
Create global variable (maybe name it Player Orbitals[6]) by creating a 'Unit' type variable in the file list (on the left) and clicking the 'array' checkbox. Change the size of the array variable to the maximum number of players you will have.
In game, when the Orbital Commands are created for players by triggers, use the Set Variable function to set Player Orbitals[<PutPlayerNumberHere>] to the Last Created Unit (which is the Orbital you just created). If you put the Orbital Commands on the Terrain Editor, and they're already in the game when it starts without having to create them via triggers, then, in a Melee Initialization Trigger, set all of the Player Orbitals[<PlayerNumbers>] to the ones you've placed in the terrain editor (via the 'Value' tab under the Set Variable).
Create a Trigger that has multiple events that make it fire; the event you'll be looking for is 'Unit Dies'. The first Event that will cause the Trigger to execute will be something along the lines of "Player Orbitals[1] Dies. Then you will continue on and put "Player Orbitals[2] Dies, 3, 4,... etc.
I'm not using my editor to test this out right now, but you would make it so the Triggering Player is kicked from the game, or, you could change all of the player's units to Neutral, Reveal the entire map for them, and make it so they can watch but not play. I don't know how your map will play, but you can make the decision on what happens when you get that far. If you need help figuring out the rest, let me know.
As for the rest of the objectives, I don't have my Editor open right now. But, if you need further assistance, I will be glad to give you more help.
In the Starcraft 2 Editor, there are three standard types of regions: Circles, Rectangles, and Diamonds. These are very basic shapes and don't support rotations whatsoever. Here is how to make them work in that regard.
Overview
This function does not work by rotating the region. Instead, it rotates the checking point in relation to the pseudo-angle of an imaginary rotated region. The rotation is only applied to the checking point (in relation to the center of the region) and not to the region itself.This is much better on the CPU and takes a ton less math, is perfectly accurate, and uses the built in Point/Unit Is In Region (allowing for support of any regions built of as many of the standard shapes as you want). And, it's surprisingly simple.
On the left, the region is not actually rotated, only the point. On the right is the final product.
There will be two function when we are done that return booleans:
Point Is In Rotated Region
Unit Is In Rotated Region
Now, let's get started...
The Code and Theory
Basically, the required parameters are very similar to the standard "Point Is In Region", except we add one more parameter to the function: Angle. The reference point of the rotation is the regions center.
Center is the center of the region.
Point is the point we are testing to see if it's in the region.
WorkPoint is the final test point we calculated after rotating.
So, the trick:
1. Store the distance between Center and Pointdist
2. Store the angle between Center and Pointa
3. Create a rotated point (WorkPoint by off-seting the Center (polar) by distance dist at angle a plus the parameter Angle.
Unit checking in rotated region can be slightly painful. You have to create an invisible target dummy unit, set it's radius to the radius of the unit you're checking and see if that unit, placed at the position of WorkPoint, is in the region. You can use the Point version for unit checking, but it will only register positive if your unit's center is standing directly in the region.
More on that later.
Uses
You can use this function for many different things. You can:
Trace-lines (for TPS and FPS) that are as accurate in width as a bullet.
Make a rotating lava bridge (I don't know)
Anything!
So, thanks for reading, GLHF, and I've uploaded a test map with a super cool region I designed myself.
Edit your Car Ignition auto-cast ability to have a .5 second cool down
Have the car's movement speed set to 0 in the data editor
Create a behavior called "Car Ignition On", and change the field in the new behavior window from Attribute to Buff.
Max stack count to 3
Duration to .6 second
Movement: Movement Speed Bonus to <whatever you want the speed to be>
Now, in your trigger, when the auto cast ability is fired, Apply your "Car Ignition On" Behavior to your triggering unit. It will add a new .6 seconds to the car's ignition. When .6 seconds pass, that buff will be removed and the car will be unable to move. However, if the auto cast is still on, and was cast within the past .6 seconds, the Buff will have been renewed, and the car will continue on after even the old buff has been removed because of the new one that was applied in the meantime. If the Auto Cast is disabled, within anywhere from 0 to 0.6 seconds later, the car will stop.
This method will keep the car moving just as long as the ignition is cast within the past .5 seconds. You can make this time smaller to make the accuracy higher, the smaller it is, the more CPU it takes (but honestly, you can set it to 0.07, and the buff duration to 0.08 and it will work just the same, unless you have 600 cars at once).
Just remember to always have your buff duration a little longer than your Auto Cast cooldown. Otherwise, the buff will run out at the exact same time as the ability is cast, and it might make the vehicle stutter.
If the target unit is atop the cliff (possible by If( TargetUnit is in region TopOfCliff, and also If(AttackingUnit is NOT in region TopOfCliff)), then you could issue to the AI to attack a point just at the top of the cliff, and add the order afterwards to their queue to attack the point of the Target Hero Unit.
Now, if there are multiple ramps to the top of the cliff, you may have to get tricky with the code; you may have to dynamically pick which point will be queued for the TopOfCliff point. You may have to set up multiple points at the top of the individual different ramp entrances, and do some math to figure out which is the closest. Once you find the closest TopOfRamp point, you'll have to issue an order to that point before the Attack order towards TargetUnit. This will be a small process for each individual unit that you will have to do. However, I don't think it'll eat up much performance; if you do this for 200 units every 2 seconds, it won't be an issue really if you code it properly.
OR
In the data editor, change the Unit Vision Height to 2 and sight radius to the length of a ramp
If you do this, then if a unit is at the bottom of a ramp, the unit will be able to see the blocking supply depot and attack it, but it won't be able to attack too far up onto the cliff.
PROS:
Enemies will not be aimlessly walking into a cliff just next to the ramp
If they are within range of attacking a supply depot, they will
CONS:
Enemies will be able to see up cliffs, and will be able to attack up without walking up the ramp (which is why you set their vision radius to the smallest possible amount,the length of a ramp, to mitigate the con).
OR
You could give the enemies Vision Height of 5, and add a Validator to their attack "Cliff GE0" or something (can't remember the exact name)
If you do this, then the units will be able to see up the cliff, but won't be able to attack unless it is on the same cliff level as the unit.
PROS:
The unit will be able to see the supply depot, and perhaps attack it properly, walking up the ramp to attack it.
CONS:
The unit won't be able to attack up cliffs at all, even if the unit has vision of the high ground from its allies.
This is not what I'm trying to do, but for the sake of example, if I had a portrait/glossary, and I theoretically knew that the actor inside the portrait had a Ref_Head attach point, and if I had a model of a cowboy hat, how would I go about attaching the Cowboy hat to the Portrait Marine's Head?
Actor scopes seem to be getting in my way (yet another completely ambiguous and undocumented seemingly vain fundamental of the SC2 Editor). I have absolutely no idea how to circumvent the whole "Actor cannot be created outside of scope" (???).. If I want to create an actor at a point, I don't understand why some weird thing called an actor scope should be telling me that I cannot...
I digress....
The portrait? Is there a way to create an extra model inside the portrait and then attach it to the attach point of the first model inside there?
The problem with making invisible units to create collision, and all those sorts of things, is the AI Pathing. When you use standard doodads and the like, units will plot paths to avoid obstacles in order to reach their destination, just like the example on the left. However....:
As you can see on the Right, when Invisible Units/ No Fly Zones are used, the unit No Longer plots a path, and instead just dumbly walks straight at the goal without any regard for what's in the way. The unit no longer thinks about how to get there, and instead just tries to get there. I am going to be making a few very hard to kill enemies on the second floor, but they have to be able to navigate out of a room. If the bottom floor is using standard doodads, then the second floor has to use something else that (hopefully exists) they can intelligently path though. Otherwise, I have to use Triggers to program an A* Pathing algorithm myself (which is going to be buggy for a long time and also clunky, because they're triggers).
I can make units colliding mutually exclusively, sure, but I'm not asking for collision. I'm asking for Pathing.
PS: There was a pathing footprint (1x1 Underground) that I saw in the Pathing Footprint list.. perhaps, if the 2nd story units are "burrowed", they will path around those objects with the 1x1 Underground footprint....
Is there any way to get one unit to path through, for example to only collide with structures, and another unit to only collide with doodads?
I'm trying to make a multiple floor building, and everything is working out just fine, but the second floor needs to have units colliding and pathing around the walls up there, not on the ground floor. If I have the same pathing algorithm for both floors, the unit will be bumping into walls that aren't even on that floor (they're on the floor above/below)!
Unfortunately, trying to have the 2nd story units use a flying mover didn't work - not only are the no fly zones annoying, but the units don't actually try to path anywhere; they just fly straight into obstacles and bounce around. This is the same case with placing tons of units to block fliers or burrow-movers (diggers), the whole no-pathing thing. I'm afraid it has to be an Avoid mover for the unit to use.
I really don't want to have to program a pathing algorithm myself for the second floor, >< !
So, if there is a way to make one unit Ignore doodads, but Collide with structures, and another unit Ignore structures and Collide with doodads, that's exactly what I'm looking for.
I am really trying to learn to be self-sufficient with the export of custom models from 3ds Max (2011, 64bit) for use in game (units and whatnot). I've attached a model (with the textures) and I am posting in search of help; can someone teach me how to export this as an m3? What things do I need to change, and how do I properly change them? I'd like it if someone could open up the model, export it as an m3 and perhaps tell me how they did it. I am a noob with 3ds max; animating isn't very hard, but exporting, importing, creating models... I just don't understand. I have rudimentary understanding of how bones, layers, and meshes work, but when it's telling me to add a "skin modifier" to all the bones, and that the bones don't have SC2 Materials applied, Even Though They Do, I'm just like way in over my head I realize. Can someone figure out not just what to do, but explain to me why the model won't export?
Sorry buddy, this is probably a SC2 Layout thing (Check that section of the forum). Also, when you post in the SC2 Layout section, post a picture of the problem via a screen shot. They'll be able to help you much faster.
0
I have created a demo map to demonstrate a method in creating kill streak tracking for only a specific unit.
The way it works is like this (In this demo, I used 4 seconds as the Kill Streak Timer - meaning the unit has to kill every 4 seconds to keep the streak going)
I also added a little visual cue so that it is more obvious when you kill a unit. On the left (in the Debug Message Area), I also added some text to show how large the kill streak is.
If you have anymore questions just post them and I'll be happy to answer them!
0
Absolutely is possible.
I would start with going into the Data Editor and turning on for the ball "Ignore Terrain Height", for starters. Change the Ball unit's acceleration to As High as it can go, Deceleration also as High as it can go.
In the Trigger Editor, create these Global variables:
Make some Constants that you will use for Decelerating the ball, to make sure that it does not just roll forever everywhere, and actually make it seem real.
Then, create an action that looks something like this:
That will get you started I hope, Good luck! I might goof around with this idea later if I have time.
0
I've attached another map that has comments in the Code, so go ahead and give that a read - the code works for all types of structures - Orbitals, Infestation Pits, etc. (And I put a few of them on the map).
As far as the bit about arrays:
Imagine you made a map, that had 8 players, and they each had to ... kill One Zergling on the map. Since you now know how to create global objective variables, you might create 8 Individual varaibles like this....
Then, inside your Unit Dies Trigger, you would have to use an If Then Else statements (like 8 of them) to check what player killed a Zergling, and then set their objective to complete (only for that one player).
The easy way to do it would be using an Array. Arrays are sort of like "Lists" of variables. You set the maximum different items there are in the "List" by change the "Size" parameter of an Array variable. SO , the easier way to do this would be creating One Array variable with the size of 8:
Now, the Huge advantage about arrays is that you can, instead of putting a number between the "[ ]" braces, you can put a variable, or a math equation, or any number. Before, in the example above, I was discussing a Trigger that checks every time a Zergling dies. Imagine if your long Trigger from up there, with 8 IF THEN ELSE statements was changed simply one line of code, this:
Much Easier, right?
If you still aren't getting it, just let me know.
0
I attached a map in the style of a single-player campaign map. Open it up, give it a test run, but definitely read through the Triggers. I put a lot of comments in there for you to help you understand the process in how we make these types of objectives, make them compete when certain things happen, and all the rest of it. It really is pretty simple.
Good luck!
0
Orbital Killed Objective: Let's say there are 6 possible players:
As for the rest of the objectives, I don't have my Editor open right now. But, if you need further assistance, I will be glad to give you more help.
0
@Epicdeath66: Go
Set all units vision range to 0 in the data editor, except for the searchlight unit.
0
Rotated Region Collision
In the Starcraft 2 Editor, there are three standard types of regions: Circles, Rectangles, and Diamonds. These are very basic shapes and don't support rotations whatsoever. Here is how to make them work in that regard.
Overview
This function does not work by rotating the region. Instead, it rotates the checking point in relation to the pseudo-angle of an imaginary rotated region. The rotation is only applied to the checking point (in relation to the center of the region) and not to the region itself.This is much better on the CPU and takes a ton less math, is perfectly accurate, and uses the built in Point/Unit Is In Region (allowing for support of any regions built of as many of the standard shapes as you want). And, it's surprisingly simple.
There will be two function when we are done that return booleans:
Now, let's get started...
The Code and Theory
Basically, the required parameters are very similar to the standard "Point Is In Region", except we add one more parameter to the function: Angle. The reference point of the rotation is the regions center.
Center is the center of the region. Point is the point we are testing to see if it's in the region. WorkPoint is the final test point we calculated after rotating.
So, the trick:
Unit Check
Unit checking in rotated region can be slightly painful. You have to create an invisible target dummy unit, set it's radius to the radius of the unit you're checking and see if that unit, placed at the position of WorkPoint, is in the region. You can use the Point version for unit checking, but it will only register positive if your unit's center is standing directly in the region.
More on that later.
Uses
You can use this function for many different things. You can:
So, thanks for reading, GLHF, and I've uploaded a test map with a super cool region I designed myself.
0
@Netro9: Go
Oh, whoops, don't forget to also set the "Movement Speed: Maximum" to the same as the Bonus field.
Or, for every buff the car gets, the car will go faster and faster! Make sure the car's Movement: Speed Maximum in the behavior is set too!
0
Edit your Car Ignition auto-cast ability to have a .5 second cool down
Have the car's movement speed set to 0 in the data editor Create a behavior called "Car Ignition On", and change the field in the new behavior window from Attribute to Buff.
Now, in your trigger, when the auto cast ability is fired, Apply your "Car Ignition On" Behavior to your triggering unit. It will add a new .6 seconds to the car's ignition. When .6 seconds pass, that buff will be removed and the car will be unable to move. However, if the auto cast is still on, and was cast within the past .6 seconds, the Buff will have been renewed, and the car will continue on after even the old buff has been removed because of the new one that was applied in the meantime. If the Auto Cast is disabled, within anywhere from 0 to 0.6 seconds later, the car will stop.
This method will keep the car moving just as long as the ignition is cast within the past .5 seconds. You can make this time smaller to make the accuracy higher, the smaller it is, the more CPU it takes (but honestly, you can set it to 0.07, and the buff duration to 0.08 and it will work just the same, unless you have 600 cars at once).
Just remember to always have your buff duration a little longer than your Auto Cast cooldown. Otherwise, the buff will run out at the exact same time as the ability is cast, and it might make the vehicle stutter.
0
3 Potential solutions:
If the target unit is atop the cliff (possible by If( TargetUnit is in region TopOfCliff, and also If(AttackingUnit is NOT in region TopOfCliff)), then you could issue to the AI to attack a point just at the top of the cliff, and add the order afterwards to their queue to attack the point of the Target Hero Unit.
Now, if there are multiple ramps to the top of the cliff, you may have to get tricky with the code; you may have to dynamically pick which point will be queued for the TopOfCliff point. You may have to set up multiple points at the top of the individual different ramp entrances, and do some math to figure out which is the closest. Once you find the closest TopOfRamp point, you'll have to issue an order to that point before the Attack order towards TargetUnit. This will be a small process for each individual unit that you will have to do. However, I don't think it'll eat up much performance; if you do this for 200 units every 2 seconds, it won't be an issue really if you code it properly.
OR
In the data editor, change the Unit Vision Height to 2 and sight radius to the length of a ramp
If you do this, then if a unit is at the bottom of a ramp, the unit will be able to see the blocking supply depot and attack it, but it won't be able to attack too far up onto the cliff.
PROS:
CONS:
OR
You could give the enemies Vision Height of 5, and add a Validator to their attack "Cliff GE0" or something (can't remember the exact name) If you do this, then the units will be able to see up the cliff, but won't be able to attack unless it is on the same cliff level as the unit.
PROS:
CONS:
0
This is not what I'm trying to do, but for the sake of example, if I had a portrait/glossary, and I theoretically knew that the actor inside the portrait had a Ref_Head attach point, and if I had a model of a cowboy hat, how would I go about attaching the Cowboy hat to the Portrait Marine's Head?
Actor scopes seem to be getting in my way (yet another completely ambiguous and undocumented seemingly vain fundamental of the SC2 Editor). I have absolutely no idea how to circumvent the whole "Actor cannot be created outside of scope" (???).. If I want to create an actor at a point, I don't understand why some weird thing called an actor scope should be telling me that I cannot...
I digress....
The portrait? Is there a way to create an extra model inside the portrait and then attach it to the attach point of the first model inside there?
0
The problem with making invisible units to create collision, and all those sorts of things, is the AI Pathing. When you use standard doodads and the like, units will plot paths to avoid obstacles in order to reach their destination, just like the example on the left. However....:
As you can see on the Right, when Invisible Units/ No Fly Zones are used, the unit No Longer plots a path, and instead just dumbly walks straight at the goal without any regard for what's in the way. The unit no longer thinks about how to get there, and instead just tries to get there. I am going to be making a few very hard to kill enemies on the second floor, but they have to be able to navigate out of a room. If the bottom floor is using standard doodads, then the second floor has to use something else that (hopefully exists) they can intelligently path though. Otherwise, I have to use Triggers to program an A* Pathing algorithm myself (which is going to be buggy for a long time and also clunky, because they're triggers).
I can make units colliding mutually exclusively, sure, but I'm not asking for collision. I'm asking for Pathing.
PS: There was a pathing footprint (1x1 Underground) that I saw in the Pathing Footprint list.. perhaps, if the 2nd story units are "burrowed", they will path around those objects with the 1x1 Underground footprint....
0
Is there any way to get one unit to path through, for example to only collide with structures, and another unit to only collide with doodads?
I'm trying to make a multiple floor building, and everything is working out just fine, but the second floor needs to have units colliding and pathing around the walls up there, not on the ground floor. If I have the same pathing algorithm for both floors, the unit will be bumping into walls that aren't even on that floor (they're on the floor above/below)!
Unfortunately, trying to have the 2nd story units use a flying mover didn't work - not only are the no fly zones annoying, but the units don't actually try to path anywhere; they just fly straight into obstacles and bounce around. This is the same case with placing tons of units to block fliers or burrow-movers (diggers), the whole no-pathing thing. I'm afraid it has to be an Avoid mover for the unit to use.
I really don't want to have to program a pathing algorithm myself for the second floor, >< ! So, if there is a way to make one unit Ignore doodads, but Collide with structures, and another unit Ignore structures and Collide with doodads, that's exactly what I'm looking for.
0
Hello,
I am really trying to learn to be self-sufficient with the export of custom models from 3ds Max (2011, 64bit) for use in game (units and whatnot). I've attached a model (with the textures) and I am posting in search of help; can someone teach me how to export this as an m3? What things do I need to change, and how do I properly change them? I'd like it if someone could open up the model, export it as an m3 and perhaps tell me how they did it. I am a noob with 3ds max; animating isn't very hard, but exporting, importing, creating models... I just don't understand. I have rudimentary understanding of how bones, layers, and meshes work, but when it's telling me to add a "skin modifier" to all the bones, and that the bones don't have SC2 Materials applied, Even Though They Do, I'm just like way in over my head I realize. Can someone figure out not just what to do, but explain to me why the model won't export?
Thanks
0
Sorry buddy, this is probably a SC2 Layout thing (Check that section of the forum). Also, when you post in the SC2 Layout section, post a picture of the problem via a screen shot. They'll be able to help you much faster.