I'm trying to crack the nut of a map I want to progress on. Basically, it's a third person shooter where you can select 1 of 3 vehicle types to control:
Type 1: "Wheelers"
Such as the Hellion and the Siege Tank. These will move with accelerated movement by using the forward and reverse keys. (Players can set up their keys as they like, but WASD is default). Ofcourse, they won't stop because you release a key. They'll keep rolling and decelerate. They have frictional turning, which means you turn them with the right and left keys. But it should also be so that the more speed a wheeler has currently, the more it can turn, a bit like real cars.
Type 2: "Poddies"
Legged vehicles, such as the Goliath or the Immortal. You turn them with the left and right keys, but they can stand still and turn perfectly. They can't reverse like a wheeler. Instead the down key will turn them 180 degrees immediately.
Type 3: "Flyers"
Scout, Wraith, etc. They should have accelerated 3D movement, be unable to reverse but they can still use the down key to brake/decelerate. I won't ponder too much yet over how to create their movement, as I'm sure it's going to be twice as complicated as making wheelers and poddies move correctly. They will turn to whatever way the camera is pointing (and you'll control the camera with the mouse). Left and right keys make them strafe left and right in the air.
I've allready been on making WASD systems for foot units, but this is way more complicated as there are three different types of movement. I need to figure out what variables, triggers, and functions I need to build this machine and get it to work efficiently. And I'm currently in a state of mild frustration over how complex this is getting in my head. Can someone help me boil it down?
I've so far tested some unit acceleration/deceleration using Cosine to figure out their speed after pressing the forward key for X amount of time, and the same for reverse. I'm gonna use Cosine for acceleration and deceleration, and I have two arrays with precalculated Sine and Cosine results so my map won't have to calculate them runtime, only during the loading screen. Thus, these can be used like crazy. They won't affect performance.
Oh, yes. On top of all this, there'll be shooting in the map. Here, the vehicle types will probably differ as much. I have thought about how shooting work in this map, but I'm not yet sure as to whether it's possible for example to turn a turret towards the yaw of the camera. Though, it's not my first time making mathematical tracelines, so don't worry I've that part figured out. I'm looking forward to implementing a lot of interesting math, but the base mechanics of movement with three vastly different vehicle types and all that is very confusing. It's a structural problem, you could say.
Can anyone give some constructive feedback? Tips on implementing my idea maybe? Thanks a bunch.
@Kueken531
All good points. I can see how #1 and #2 could be useful. It's not a real hindrance to miss those options, but could be useful.
@LinkD
Yeah, I was about to say, any advanced formula I would do with custom script. However, because I didn't know to put gv_ in front, I was doing this WITHOUT custom script:
...Maximum((Abs(d-270)/360)*distMult,distMax)...
Which is a pain to edit wihtout having used custom script. The good thing is how GUI will correct itself when I rename any element. And how I can easily move things around.
Edit: so to use a record, I would write: "gv_myRecord.Member"?
Should I learn Galaxy scripting to do the "real stuff"? Or the "fun stuff"?
Are there any things you can do with Galaxy scripting that you can't do in the trigger editor without custom script? In Wc3, there were some very essential things you could only do in JASS, like defining functions and local variables. But all that seems to be available for GUI users in Galaxy's trigger editor now... Is there anything I'm missing by not knowing the ins and outs of Galaxy scripting?
Maybe events? Because event definitions in the trigger editor do not seem to work, so maybe that's one thing?
I also have another question: I know that local variables start with lv_, and parameters with lp_, but what about globals, constants, and records?
Thanks.
Really didn't know about that. Exactly what I was trying to do. Well that could've saved me some to-no-avail work I've allready done. I'm a noob at cheats. But thanks whether you want them or not.
I am making something I call a "UI Editor" which is supposed to at least make it easier to construct and preview a Dialog-based UI (see how everything looks and have the settings visible onscreen and editable while doing so), and if banks work as I hope, save some information that the player can somehow retrieve (for example in a text document). Though I heavilly doubt that the last part is supported. If only.
But anyway, a side feature: The player will probably want to check out some command buttons and stuff for different units while messing around with the UI. Reason: It's also going to allow you to show and hide different parts of the UI through a menu, and if possible toggle various imported layout files. If the latter isn't possible, at least the user will be able do it from the editor.
In a chat message, the player can type "select player *unit name*", "select ally *unit name*", or "select enemy *unit name*". Doing so will launch 1 of 3 triggers which responds by calling this action:
Options- Action
Return Type- (None)
Parameters
Unit Type = Marine <Game Link - Unit> (becomes the unit type that player 1 typed in the message)
Player = 0 <Integer>
Grammar Text
Create Selection Unit(Unit Type)
Hint Text- (None)
Local Variables
Actions
Unit - Remove Selection Unit from the game
Unit - Create 1 Unit Type for player Player at Map Center using default facing (No Options)
Variable - Set Selection Unit = (Last created unit)
Unit Selection - Select (Last created unit) for player 1
The trigger that fires on "select enemy *unit name*" calls the action with the second parameter (Player) set to 3 (who is an enemy of player 1). The trigger that fires on "select ally *unit name*" creates a unit for player 2 (ally), and so on.
But the actual problem is that when I try to save, it reports generated syntax error in the Action Definition above.
It points to the line that creates 1 Unit Type. Apparently, it won't take a Game Link even after I've set a default value for the Unit Type parameter to Marine. So I basically can't use the entered chat string to specify a unit type and use that game link. Doesn't Unit Tester map do something similar? I don't know, because I've never played it, but I thought I saw on YouTube that it was able to create units of many different types in a similar way, and I thought they had probably done something a bit similar to this.
No?
I want to ask before I give up: Is this possible somehow? Or should I just pre-define a smaller selection of units instead? I really can't see why it wouldn't be possible like this. Never seen the editor do like this before.
If you enable all dependencies, it adds different versions of units to your Data Editor. If you have Story Mode Tech - (Battlecruiser) Yamato Cannon upgrade for player 1, you need to use the unit that the Battlecruiser for Story Mode, for example. To keep them seperated while in the unit placement layer, select Melee/Liberty/Story Mode filter in one of the dropdown menus so it only shows those units. If the ability is greyed out, you got the unit from the wrong dependency. Different identical upgrades for different identical or almost identical units oringinating from different dependencies.
In the Data Editor also, you can see which Dependency an object originates from in the "Source" column for the list to the left. It can say Liberty.SC2Mod, [YourMap].SC2Mod, Liberty.SC2Campaign, etc.
This tutorial explains how you can deal with the aesthetical issues associated with a SC2 Mouse-Look camera. Namely: Restrainting pitch, making a camera follow a unit properly, and disabling/editing mouse-wheel zoom levels.
This tutorial does not teach you how to make a WASD system or anything, though. It's assumed you are familiar with the different camera properties. If not, it's easy to create and play around with a camera in the Galaxy Editor's Camera Layer to get a feeling for what the properties do individually.
Go ahead, make yourself a really good camera that you like for a third person camera... In the Camera Layer. Click Create Camera, double click the
camera object, or right click and select -> Properties, go crazy!
When you're done, let's get the basics up. Go to the trigger editor and create a trigger with event map initialization or whatever you like.
Add the following actions:
Camera - Apply (Your Camera) for player 1 over 0.0 seconds with Existing Velocity% initial velocity, 10% deceleration, and Include Target
Camera - Turn camera mouse rotation On for player 1 (How do you make line breaks in this forum?)
Camera - Lock camera mouse relative mode On for player 1
Camera - Follow for player 1 (Unit group(Your unit)) with the camera and Clear current target
Camera - Turn camera height displacement Off for player 1
Right. If you go ahead and test your map right now, you might notice at least 3 big problems :
1) Your camera is restraintless. It can go upside down, and underground when you move your mouse vertically.
2) When you order your unit to move somewhere (or move via a WASD system), the camera can't keep up! It trails behind like an old granny.
3) If you accidentally turn the mouse-wheel just a bit, your camera settings are ruined! For the rest of the map if the creator hasn't either "fixed it" with a periodic trigger, or done what I'm doing in this tutorial.
I will explain how to solve all these issue within the data editor. No need for a periodic trigger to force the desired camera on all the time. Open up your camera object, and open up notepad so you can write down your desired camera properties. We will need to move them to the data editor later.
MODIFY PITCH MAXIMUM AND MINIMUM ANGLES
We go to the Data Editor, and enter the Cameras tab. In here we will do everything from this point on.
Either duplicate Default Camera and name it something new, or just edit the Default Camera directly.
Topmost we have three values for Angle of Attack (AKA pitch). Set "Angle of Attack Maximum" and "Angle of Attack Minimum" to what you like. They are self-explanatory: Maximum is the maximum pitch, minimum is the minimum pitch. But those settings do not normally work very well. I will show you further down how to make them more strict.
I don't know what "Angle of Attack Increment" exactly does. Increment sounds like it might be some acceleration or what? But my guess is probably worse than yours. Just a shot into the mist.
Find the "Parameter Smooth" field and modify the value. You will see a window containing a list of the various camera properties. These are settings for
smoothing. The slow smoothing is what enables you to tilt your mouse-look camera upside down. That's why we're gonna edit the smoothing for Angle of Attack.
Select the "Angle of Attack" item on the list. Change "Smooth Time Maximum" and "Smooth Time Minimum" to something much lower than the default 2.0 and 0.25. I have set my "Smooth Time Maximum" to 0.1, and my Minimum to 0.02.
Set any of the two above values too low (both to 0.0 for instance), and you'll get a really choppy camera. So if you're smart, don't. The settings we just set greatly improve the speed at which the camera adjusts to the minimum and maximum angle of attack fields I showed you earlier. With these settings, my camera never goes upside down. Yay!
Find the "Target Smooth" field further down. Modify the value. You will see a window containing 4 settings. These values by default cause your camera to trail behind a unit it is following via the "Follow unit group" trigger action. We can change that.
Change "Smooth Time Maximum" to something way lower than 2.0, like 0.05. Change "Smooth TIme Minimum" to something way lower. You might choose the same value again (0.05). In the screenshot (link below), I've set Velocity Maximum to 75, but I later found out it's just fine at 10. I haven't noticed any difference.
This can be done easy. Find "Zoom Levels" and modify the field. This is when you need your open notepad. Did you write down your camera properties? Good.
You will see a window with 5 different zoom levels by default. These are the settings the camera move between when you touch the mouse-wheel or use page up/page down. You can simply select the topmost zoom level and hit the red "X" until the list only contains a single zoom level.
To add new zoom levels, click the green "X".
Then set the parameters to your liking. To apply a change, select a Parameter in the Parameters list below the Zoom Levels, and check Enabled. Then double click the value column in the enabled rows and apply a new value. You can see some of my settings in the screenshot.
I chose to have a simply zoom with 6 levels set to Height Offsets from 1.3 down to 1.0. But if you just want a completely fixed camera disallowing zoom, use a single Zoom Level.
If you have made a new camera (by duplicating default, presumably) you must go to the "Terrain Texture Sets" tab now. There you should find the texture set for the map and set the field Camera to your new camera. Otherwise, you don't need to do this step.
Now, test your map and see if you like it or not. If not, try playing around some more with the fields I pointed out in the Data Editor.
That's it.
I hope this tutorial was comprehensive. If there is anything I missed or something you would add, or a question for that matter, feel free.
Edit: I've noticed that if you rotate your camera way down, pushing against the limit for awhile, it can sometimes leap instantly to the maximum angle of attack all of a sudden. I hope I'll find out how to prevent that.
0
I'm trying to crack the nut of a map I want to progress on. Basically, it's a third person shooter where you can select 1 of 3 vehicle types to control:
Type 1: "Wheelers"
Such as the Hellion and the Siege Tank. These will move with accelerated movement by using the forward and reverse keys. (Players can set up their keys as they like, but WASD is default). Ofcourse, they won't stop because you release a key. They'll keep rolling and decelerate. They have frictional turning, which means you turn them with the right and left keys. But it should also be so that the more speed a wheeler has currently, the more it can turn, a bit like real cars.
Type 2: "Poddies"
Legged vehicles, such as the Goliath or the Immortal. You turn them with the left and right keys, but they can stand still and turn perfectly. They can't reverse like a wheeler. Instead the down key will turn them 180 degrees immediately.
Type 3: "Flyers"
Scout, Wraith, etc. They should have accelerated 3D movement, be unable to reverse but they can still use the down key to brake/decelerate. I won't ponder too much yet over how to create their movement, as I'm sure it's going to be twice as complicated as making wheelers and poddies move correctly. They will turn to whatever way the camera is pointing (and you'll control the camera with the mouse). Left and right keys make them strafe left and right in the air.
I've allready been on making WASD systems for foot units, but this is way more complicated as there are three different types of movement. I need to figure out what variables, triggers, and functions I need to build this machine and get it to work efficiently. And I'm currently in a state of mild frustration over how complex this is getting in my head. Can someone help me boil it down?
I've so far tested some unit acceleration/deceleration using Cosine to figure out their speed after pressing the forward key for X amount of time, and the same for reverse. I'm gonna use Cosine for acceleration and deceleration, and I have two arrays with precalculated Sine and Cosine results so my map won't have to calculate them runtime, only during the loading screen. Thus, these can be used like crazy. They won't affect performance.
Oh, yes. On top of all this, there'll be shooting in the map. Here, the vehicle types will probably differ as much. I have thought about how shooting work in this map, but I'm not yet sure as to whether it's possible for example to turn a turret towards the yaw of the camera. Though, it's not my first time making mathematical tracelines, so don't worry I've that part figured out. I'm looking forward to implementing a lot of interesting math, but the base mechanics of movement with three vastly different vehicle types and all that is very confusing. It's a structural problem, you could say.
Can anyone give some constructive feedback? Tips on implementing my idea maybe? Thanks a bunch.
0
Thanks.
0
@Kueken531
All good points. I can see how #1 and #2 could be useful. It's not a real hindrance to miss those options, but could be useful.
@LinkD
Yeah, I was about to say, any advanced formula I would do with custom script. However, because I didn't know to put gv_ in front, I was doing this WITHOUT custom script:
...Maximum((Abs(d-270)/360)*distMult,distMax)... Which is a pain to edit wihtout having used custom script. The good thing is how GUI will correct itself when I rename any element. And how I can easily move things around.
Edit: so to use a record, I would write: "gv_myRecord.Member"?
0
Should I learn Galaxy scripting to do the "real stuff"? Or the "fun stuff"?
Are there any things you can do with Galaxy scripting that you can't do in the trigger editor without custom script? In Wc3, there were some very essential things you could only do in JASS, like defining functions and local variables. But all that seems to be available for GUI users in Galaxy's trigger editor now... Is there anything I'm missing by not knowing the ins and outs of Galaxy scripting?
Maybe events? Because event definitions in the trigger editor do not seem to work, so maybe that's one thing?
I also have another question: I know that local variables start with lv_, and parameters with lp_, but what about globals, constants, and records?
Thanks.
0
Aahahaha, lol and $#!£!%
Really didn't know about that. Exactly what I was trying to do. Well that could've saved me some to-no-avail work I've allready done. I'm a noob at cheats. But thanks whether you want them or not.
I should go to sleep. Solved.
0
I am making something I call a "UI Editor" which is supposed to at least make it easier to construct and preview a Dialog-based UI (see how everything looks and have the settings visible onscreen and editable while doing so), and if banks work as I hope, save some information that the player can somehow retrieve (for example in a text document). Though I heavilly doubt that the last part is supported. If only.
But anyway, a side feature: The player will probably want to check out some command buttons and stuff for different units while messing around with the UI. Reason: It's also going to allow you to show and hide different parts of the UI through a menu, and if possible toggle various imported layout files. If the latter isn't possible, at least the user will be able do it from the editor.
In a chat message, the player can type "select player *unit name*", "select ally *unit name*", or "select enemy *unit name*". Doing so will launch 1 of 3 triggers which responds by calling this action:
The trigger that fires on "select enemy *unit name*" calls the action with the second parameter (Player) set to 3 (who is an enemy of player 1). The trigger that fires on "select ally *unit name*" creates a unit for player 2 (ally), and so on.
But the actual problem is that when I try to save, it reports generated syntax error in the Action Definition above.
It points to the line that creates 1 Unit Type. Apparently, it won't take a Game Link even after I've set a default value for the Unit Type parameter to Marine. So I basically can't use the entered chat string to specify a unit type and use that game link. Doesn't Unit Tester map do something similar? I don't know, because I've never played it, but I thought I saw on YouTube that it was able to create units of many different types in a similar way, and I thought they had probably done something a bit similar to this. No?
I want to ask before I give up: Is this possible somehow? Or should I just pre-define a smaller selection of units instead? I really can't see why it wouldn't be possible like this. Never seen the editor do like this before.
0
@PhoenixKNight
If you enable all dependencies, it adds different versions of units to your Data Editor. If you have Story Mode Tech - (Battlecruiser) Yamato Cannon upgrade for player 1, you need to use the unit that the Battlecruiser for Story Mode, for example. To keep them seperated while in the unit placement layer, select Melee/Liberty/Story Mode filter in one of the dropdown menus so it only shows those units. If the ability is greyed out, you got the unit from the wrong dependency. Different identical upgrades for different identical or almost identical units oringinating from different dependencies.
In the Data Editor also, you can see which Dependency an object originates from in the "Source" column for the list to the left. It can say Liberty.SC2Mod, [YourMap].SC2Mod, Liberty.SC2Campaign, etc.
0
CUSTOMIZING YOUR MOUSE-LOOK CAMERA
This tutorial explains how you can deal with the aesthetical issues associated with a SC2 Mouse-Look camera. Namely: Restrainting pitch, making a camera follow a unit properly, and disabling/editing mouse-wheel zoom levels. This tutorial does not teach you how to make a WASD system or anything, though. It's assumed you are familiar with the different camera properties. If not, it's easy to create and play around with a camera in the Galaxy Editor's Camera Layer to get a feeling for what the properties do individually.
Go ahead, make yourself a really good camera that you like for a third person camera... In the Camera Layer. Click Create Camera, double click the camera object, or right click and select -> Properties, go crazy!
When you're done, let's get the basics up. Go to the trigger editor and create a trigger with event map initialization or whatever you like. Add the following actions:
Camera - Apply (Your Camera) for player 1 over 0.0 seconds with Existing Velocity% initial velocity, 10% deceleration, and Include Target
Camera - Turn camera mouse rotation On for player 1 (How do you make line breaks in this forum?)
Camera - Lock camera mouse relative mode On for player 1
Camera - Follow for player 1 (Unit group(Your unit)) with the camera and Clear current target
Camera - Turn camera height displacement Off for player 1
Unit Selection - Select (Your Unit) for player 1
http://www.sc2mapster.com/media/attachments/18/717/Trigger.GIF
Right. If you go ahead and test your map right now, you might notice at least 3 big problems :
1) Your camera is restraintless. It can go upside down, and underground when you move your mouse vertically.
2) When you order your unit to move somewhere (or move via a WASD system), the camera can't keep up! It trails behind like an old granny.
3) If you accidentally turn the mouse-wheel just a bit, your camera settings are ruined! For the rest of the map if the creator hasn't either "fixed it" with a periodic trigger, or done what I'm doing in this tutorial.
I will explain how to solve all these issue within the data editor. No need for a periodic trigger to force the desired camera on all the time. Open up your camera object, and open up notepad so you can write down your desired camera properties. We will need to move them to the data editor later.
MODIFY PITCH MAXIMUM AND MINIMUM ANGLES
We go to the Data Editor, and enter the Cameras tab. In here we will do everything from this point on. Either duplicate Default Camera and name it something new, or just edit the Default Camera directly.
Topmost we have three values for Angle of Attack (AKA pitch). Set "Angle of Attack Maximum" and "Angle of Attack Minimum" to what you like. They are self-explanatory: Maximum is the maximum pitch, minimum is the minimum pitch. But those settings do not normally work very well. I will show you further down how to make them more strict. I don't know what "Angle of Attack Increment" exactly does. Increment sounds like it might be some acceleration or what? But my guess is probably worse than yours. Just a shot into the mist.
http://www.sc2mapster.com/media/attachments/18/718/Angle_of_Attack_Fields.GIF
SOLVING RESTRAINTLESS PITCH
Find the "Parameter Smooth" field and modify the value. You will see a window containing a list of the various camera properties. These are settings for smoothing. The slow smoothing is what enables you to tilt your mouse-look camera upside down. That's why we're gonna edit the smoothing for Angle of Attack.
Select the "Angle of Attack" item on the list. Change "Smooth Time Maximum" and "Smooth Time Minimum" to something much lower than the default 2.0 and 0.25. I have set my "Smooth Time Maximum" to 0.1, and my Minimum to 0.02.
Set any of the two above values too low (both to 0.0 for instance), and you'll get a really choppy camera. So if you're smart, don't. The settings we just set greatly improve the speed at which the camera adjusts to the minimum and maximum angle of attack fields I showed you earlier. With these settings, my camera never goes upside down. Yay!
http://www.sc2mapster.com/media/attachments/18/719/Parameter_Smooth.GIF
SOLVING CAMERA TRAILING BEHIND UNIT
Find the "Target Smooth" field further down. Modify the value. You will see a window containing 4 settings. These values by default cause your camera to trail behind a unit it is following via the "Follow unit group" trigger action. We can change that.
Change "Smooth Time Maximum" to something way lower than 2.0, like 0.05. Change "Smooth TIme Minimum" to something way lower. You might choose the same value again (0.05). In the screenshot (link below), I've set Velocity Maximum to 75, but I later found out it's just fine at 10. I haven't noticed any difference.
http://www.sc2mapster.com/media/attachments/18/720/Target_Smooth.GIF
SOLVING THE "MOUSE-WHEEL OF DOOM" PROBLEM
This can be done easy. Find "Zoom Levels" and modify the field. This is when you need your open notepad. Did you write down your camera properties? Good.
You will see a window with 5 different zoom levels by default. These are the settings the camera move between when you touch the mouse-wheel or use page up/page down. You can simply select the topmost zoom level and hit the red "X" until the list only contains a single zoom level.
To add new zoom levels, click the green "X".
Then set the parameters to your liking. To apply a change, select a Parameter in the Parameters list below the Zoom Levels, and check Enabled. Then double click the value column in the enabled rows and apply a new value. You can see some of my settings in the screenshot. I chose to have a simply zoom with 6 levels set to Height Offsets from 1.3 down to 1.0. But if you just want a completely fixed camera disallowing zoom, use a single Zoom Level.
A slightly better screenshot: http://www.sc2mapster.com/media/attachments/18/723/Zoom_Levels_2.GIF
If you have made a new camera (by duplicating default, presumably) you must go to the "Terrain Texture Sets" tab now. There you should find the texture set for the map and set the field Camera to your new camera. Otherwise, you don't need to do this step.
Now, test your map and see if you like it or not. If not, try playing around some more with the fields I pointed out in the Data Editor. That's it.
I hope this tutorial was comprehensive. If there is anything I missed or something you would add, or a question for that matter, feel free.
Edit: I've noticed that if you rotate your camera way down, pushing against the limit for awhile, it can sometimes leap instantly to the maximum angle of attack all of a sudden. I hope I'll find out how to prevent that.
0
The tutorial is found 2 posts down. This top post was a mistake. (it's my first tutorial and I'm new here. Something was bound to fail.)