This is driving me crazy. I can attach this model to a native SC2 model, in this case the Ultralisk and it works perfectly. I can adjust the local offset to place it perfectly and it will follow the attachment point with animations.
However, whenever I do the same for an imported model, even using the same actors, it behaves strangely.
- Whenever I attach the model with no local offset it appears to work fine and tracks with animations (although it is not in the correct spatial position due to the lack of the local offset actor)
- When I add the local offset actor (or an explicit rotation) it moves into position, but now it ceases to track with all animations except for Walk.
What's throwing me for a loop is that it seemingly works until I put the local offset in, yet the ultralisk model continues to work. All I want is to be able to adjust the local offset while still maintaining the link to animations.
Map instructions for keybinds
1 = Spawns a murloc with a giant pair of goggles that don't move except when running. (see the #2 description above)
2= Spawns a murloc with normal goggles that move but aren't in position. (see the #1 description)
3= Spawns an ultralisk with the goggles in the correct position and moves correctly.
I have yet to run into a situation where I have too many triggers going and my map routinely has dozens of complex and lengthy triggers running even in the editor. My pc is decent, but by no means beastly.
The few times I have had problems with trigger slowdown was because I did something stupid. Typically things like forgetting to add some sort of delay into loops, accidentally creating duplicate graphical/sound effects, or some other boneheaded error along those lines. A good rule of thumb is to activate triggers thru actual events rather than a periodic timer. If you can't find a workable event then add in some conditions to prevent the trigger from running needlessly.
Although some things are better to periodically update if they change rapidly. IE if you're updating some sort of status and it's constantly changing then using a periodic sample at a second or so would reduce the trigger load and make the read out easier on the player.
Alot of the tutorials have great example maps. Personally i like the very focused, minimal tutorials because it's very easy to see what fields were changed. I can read Programmer's or Prozaic's tutorials and not learn a single thing because they seemingly speak a completely different language than me. It's not until I open up the maps and take a look under the hood that I think "Oh, that was simple".
You have to remember that Blizz wants very high quality maps because they eventually intend to sell them and promote SC2 itself thru them. They need us to point out the major problems that are hindering map creation because the better our maps the more money Blizz stands to make. SC2 map making is a bit different than in ages past where you were a peasant thankful for any scraps thrown your way and all you could make were dinky little hero and TD maps.
By not being vocal about bugs/limitations we are not only hurting the maps themselves but also Blizz's vision for what they want the SC2 custom map world to be. Without proper feedback they may not know how to improve the product. The vast majority of people are not whining and have very valid concerns that would improve conditions for a great many map makers.
Increase the 1/16th game cycle to 1/32nd so we at least get 30~ FPS on triggers. One of the big problems I've run into with tracelines and collision detection in general is that to get things to go faster you have to increase the increments they travel per game cycle. The fallout of this is that with small objects your projectile may be going fast enough to skip over them. IE you have a projectile going 3 distance units per cycle, and are trying to hit a target with a radius of 0.5 distance units. Since the game cycle time is so long your projectile has already completely bypassed the radius of the target, essentially ghosting by.
Things get really messy when you start using long distances, variable speed projectiles, variable sizes, non-linear trajectories, etc... I've had to scrap a lot of weapons, enemies, and gameplay elements because they become too buggy at high speeds. Also for really fine movements where you use the Move Unit instantly you lose alot of resolution and for larger movements you get a choppy transition.
They've come down alot now, only about 200 for an 80gig. Think that cost me about 325 about a year ago or so. Wouldn't go any lower than 80, it gets cramped fast and you only have room for a few games at one time on it. My WoW folder is 21.5 gigs, SC2 just over 8, and windows is taking up 24. Keeping it from getting cluttered is a pain but worth it.
It's only 6 gigs, just checked. Dunno where I got 8 from, then again I'm not that into hardware and just said what I thought it was. It's in non table view btw. Switching actors and letting the event tab fill up takes less than a second, scrolls right thru. I imagine the main thing is the SSD.
80gb intel SSD for windows and games (with other drives for actual storage)
8gb DDR3 ram
3ghz intel I7
GTX 295
Startup of the galaxy editor takes <5 seconds. Loading a map <10s (varies on size). Only time I ever notice delays is when in the data editor and I switch tabs without any filters up. IE viewing every single effect on the list will make it stutter for a second or two.
Although I have noticed the editor likes to heat up my CPU when in terrain view and zoomed way out with the far clip set high. Nothing dangerous, but I've seen it get up into the low 60's which is about the highest it's ever been.
Yeah, if it hadn't been for the contest I wouldn't have put a fraction of the effort in that I did. I have pretty much no shot at the contest because I screwed up my upload, but when the NDA is lifted and I've had time to put a bit of polish on it I think it will be very impressive. The map editor is simply phenomenal. Really the only weakness is BNet =/ As far as single player goes though the sky is the limit.
Ah, if you want movement then you have to be a bit more creative. Take a look at this. If you store the points and heights as variable and then alter your unit location/height via actor messages then you can maintain your facing.
I only made W/A so you can only move up/left, but it shows the effect. Just do the same thing for the other directions and you're good to go.
Here's a quick and dirty example I threw together of making the unit look in the direction of your camera since I suck at explaining things and formating things is a pain.
Something seems wrong with trying to set rotations via actors. You can only do pitch and yaw thru actor triggers it seems. For your code, try something like
Forward X = (Cos(Yaw)) <Real>
Forward Y = (Sin(Yaw)) <Real>
Forward Z = (Tan(Pitch)) <Real>
Actions
Variable - Forward Z: * -1.0
Actor - Send actor message (SetRotation Forward X Forward Y Forward Z, 0, 0, 0) to main actor of unit Actor
This will have the actor follow the facing of the camera. I use that for beam models too so you can sweep the beam anywhere with the camera. You could do the *-1 as part of an arithmetic real function, but I store the tan(camera pitch) in a global variable so I only have to check it once, then grab that variable and do things with it in various other triggers. Dunno if it makes a difference or not as far as optimization.
Didn't have much of a problem with trigger count, granted my map is meant to be played offline so I abused key presses and triggers whenever possible. Really the triggers never slowed me down (unless I really lowered the interval checks on my tracelines, which there could be over a hundred of in the hectic scenes).
Although to lower my traceline count I made all of the enemy projectiles units. Then I would issue orders to them based upon if statements. Could make enemies that shot at the character, in the direction the char was traveling, zig zags missiles, homing missiles, etc... The missiles I set to be killible. I would only check the parameters of the closest enemy to my ship, that way I didn't have tracelines everywhere checking every single point for a hit. Unit orders and changing the height seem to be relatively low load in comparison.
so there's no way to do barrel rolls and rotate look w/ triggers?
I did mine thru triggers and explicit rotation actors attached to models. That way I could make the ship roll left and right a little as it turned, and once you pressed a button it would do a full barrel roll. You could also hit another button to lock the roll angle while turning and fly at that angle, say 90 degress. I would make custom hit boxes for various angles, so like the 90 degree locked roll you could squeeze thru narrow vertical gaps
0
This is driving me crazy. I can attach this model to a native SC2 model, in this case the Ultralisk and it works perfectly. I can adjust the local offset to place it perfectly and it will follow the attachment point with animations.
However, whenever I do the same for an imported model, even using the same actors, it behaves strangely.
- Whenever I attach the model with no local offset it appears to work fine and tracks with animations (although it is not in the correct spatial position due to the lack of the local offset actor)
- When I add the local offset actor (or an explicit rotation) it moves into position, but now it ceases to track with all animations except for Walk.
What's throwing me for a loop is that it seemingly works until I put the local offset in, yet the ultralisk model continues to work. All I want is to be able to adjust the local offset while still maintaining the link to animations.
Map instructions for keybinds
1 = Spawns a murloc with a giant pair of goggles that don't move except when running. (see the #2 description above)
2= Spawns a murloc with normal goggles that move but aren't in position. (see the #1 description)
3= Spawns an ultralisk with the goggles in the correct position and moves correctly.
Arrow keys move the last created unit.
0
You can disable the mouse wheel from altering the camera thru the data editor.
-> Data editor -> Cameras -> Default Camera -> Zoom Levels -> Disable everything
0
I have yet to run into a situation where I have too many triggers going and my map routinely has dozens of complex and lengthy triggers running even in the editor. My pc is decent, but by no means beastly.
The few times I have had problems with trigger slowdown was because I did something stupid. Typically things like forgetting to add some sort of delay into loops, accidentally creating duplicate graphical/sound effects, or some other boneheaded error along those lines. A good rule of thumb is to activate triggers thru actual events rather than a periodic timer. If you can't find a workable event then add in some conditions to prevent the trigger from running needlessly.
Although some things are better to periodically update if they change rapidly. IE if you're updating some sort of status and it's constantly changing then using a periodic sample at a second or so would reduce the trigger load and make the read out easier on the player.
0
Alot of the tutorials have great example maps. Personally i like the very focused, minimal tutorials because it's very easy to see what fields were changed. I can read Programmer's or Prozaic's tutorials and not learn a single thing because they seemingly speak a completely different language than me. It's not until I open up the maps and take a look under the hood that I think "Oh, that was simple".
0
@StatusQ3: Go
You have to remember that Blizz wants very high quality maps because they eventually intend to sell them and promote SC2 itself thru them. They need us to point out the major problems that are hindering map creation because the better our maps the more money Blizz stands to make. SC2 map making is a bit different than in ages past where you were a peasant thankful for any scraps thrown your way and all you could make were dinky little hero and TD maps.
By not being vocal about bugs/limitations we are not only hurting the maps themselves but also Blizz's vision for what they want the SC2 custom map world to be. Without proper feedback they may not know how to improve the product. The vast majority of people are not whining and have very valid concerns that would improve conditions for a great many map makers.
0
Increase the 1/16th game cycle to 1/32nd so we at least get 30~ FPS on triggers. One of the big problems I've run into with tracelines and collision detection in general is that to get things to go faster you have to increase the increments they travel per game cycle. The fallout of this is that with small objects your projectile may be going fast enough to skip over them. IE you have a projectile going 3 distance units per cycle, and are trying to hit a target with a radius of 0.5 distance units. Since the game cycle time is so long your projectile has already completely bypassed the radius of the target, essentially ghosting by.
Things get really messy when you start using long distances, variable speed projectiles, variable sizes, non-linear trajectories, etc... I've had to scrap a lot of weapons, enemies, and gameplay elements because they become too buggy at high speeds. Also for really fine movements where you use the Move Unit instantly you lose alot of resolution and for larger movements you get a choppy transition.
0
@BumpInTheNight: Go
They've come down alot now, only about 200 for an 80gig. Think that cost me about 325 about a year ago or so. Wouldn't go any lower than 80, it gets cramped fast and you only have room for a few games at one time on it. My WoW folder is 21.5 gigs, SC2 just over 8, and windows is taking up 24. Keeping it from getting cluttered is a pain but worth it.
0
@BumpInTheNight: Go
It's only 6 gigs, just checked. Dunno where I got 8 from, then again I'm not that into hardware and just said what I thought it was. It's in non table view btw. Switching actors and letting the event tab fill up takes less than a second, scrolls right thru. I imagine the main thing is the SSD.
0
Running
80gb intel SSD for windows and games (with other drives for actual storage)
8gb DDR3 ram
3ghz intel I7
GTX 295
Startup of the galaxy editor takes <5 seconds. Loading a map <10s (varies on size). Only time I ever notice delays is when in the data editor and I switch tabs without any filters up. IE viewing every single effect on the list will make it stutter for a second or two.
Although I have noticed the editor likes to heat up my CPU when in terrain view and zoomed way out with the far clip set high. Nothing dangerous, but I've seen it get up into the low 60's which is about the highest it's ever been.
0
@Zarakk: Go
Yeah, if it hadn't been for the contest I wouldn't have put a fraction of the effort in that I did. I have pretty much no shot at the contest because I screwed up my upload, but when the NDA is lifted and I've had time to put a bit of polish on it I think it will be very impressive. The map editor is simply phenomenal. Really the only weakness is BNet =/ As far as single player goes though the sky is the limit.
0
@Beffyman: Go
Ah, if you want movement then you have to be a bit more creative. Take a look at this. If you store the points and heights as variable and then alter your unit location/height via actor messages then you can maintain your facing.
I only made W/A so you can only move up/left, but it shows the effect. Just do the same thing for the other directions and you're good to go.
0
Here's a quick and dirty example I threw together of making the unit look in the direction of your camera since I suck at explaining things and formating things is a pain.
0
@Beffyman: Go
Something seems wrong with trying to set rotations via actors. You can only do pitch and yaw thru actor triggers it seems. For your code, try something like
Forward X = (Cos(Yaw)) <Real>
Forward Y = (Sin(Yaw)) <Real>
Forward Z = (Tan(Pitch)) <Real>
Actions
Variable - Forward Z: * -1.0
Actor - Send actor message (SetRotation Forward X Forward Y Forward Z, 0, 0, 0) to main actor of unit Actor
This will have the actor follow the facing of the camera. I use that for beam models too so you can sweep the beam anywhere with the camera. You could do the *-1 as part of an arithmetic real function, but I store the tan(camera pitch) in a global variable so I only have to check it once, then grab that variable and do things with it in various other triggers. Dunno if it makes a difference or not as far as optimization.
0
@crazyfingers619: Go
Didn't have much of a problem with trigger count, granted my map is meant to be played offline so I abused key presses and triggers whenever possible. Really the triggers never slowed me down (unless I really lowered the interval checks on my tracelines, which there could be over a hundred of in the hectic scenes).
Although to lower my traceline count I made all of the enemy projectiles units. Then I would issue orders to them based upon if statements. Could make enemies that shot at the character, in the direction the char was traveling, zig zags missiles, homing missiles, etc... The missiles I set to be killible. I would only check the parameters of the closest enemy to my ship, that way I didn't have tracelines everywhere checking every single point for a hit. Unit orders and changing the height seem to be relatively low load in comparison.
0
@Beffyman: Go
I did mine thru triggers and explicit rotation actors attached to models. That way I could make the ship roll left and right a little as it turned, and once you pressed a button it would do a full barrel roll. You could also hit another button to lock the roll angle while turning and fly at that angle, say 90 degress. I would make custom hit boxes for various angles, so like the 90 degree locked roll you could squeeze thru narrow vertical gaps