Tutorial - In-Mission Jumps
From FreeSpace Wiki
Today we're gonna look at how to make in-mission subspace jumps!
They're easy to make and contain 57% of your daily spinning blue content.
All you need is a FreeSpace Open, version 3.6.12 at the very least.
Capital Ship Micro Jumps
Setting up the mission
First lets set up a super simple mission! Open up FRED and make something like this.
Here's a link to the blank mission if you're too lazy to make it yourself.
Okay, so now let's start some magic. Let's move Aquinas Station about 30 klicks out. Then let's make a new Aeolus cruiser. We're going to name it Ascendant#2. We'll place Ascendant#2 close to Aquinas Station.
For ship names, FreeSpace will ignore anything past the # sign. Older missions that might have tried this would have used non-ASCII characters, like a "á" or "ó". Since those characters aren't in the font files, they show up as blanks. But if FreeSpace ever gets true TTF support, guess which missions are going to look pretty funny!
NOTE: This happens in wing names too to a certain detriment. Naming a wing Alpha#2 will make the fighter names be Alpha#2 1, Alpha #2 2 and etc. But since anything past the # will be ignored, in game all you're going to see is Alpha, Alpha, Alpha, and Alpha. So its not a good idea to do this for fighters. We'll get around that later.
So for Ascendant#2's arrival cue, we're going to set it to when Ascendant has departed. You can insert a delay, but for these relatively small distances for FTL, its going to be near instant anyway.
Then we'll make the Ascendant's depart cue to leave after 5 seconds.
Okay, let's go run the mission real quick. We should have the Ascendant warp out and then warp in again, right next to Aquinas Station.
"Gee Axem, I'm not THAT dumb. I could have figured that out by myself!"
I see I have underestimated you. Let's kick it up a notch. Let's increase the depart time for the Ascendant to 30 seconds.
Now lets add a hostile cruiser, a Fenris. Let's name it the Gosforth. And since we're going to be lazy with this, lets just tell it to attack the Ascendant.
The resulting battle should now damage the Ascendant to a degree. Let's replay this mission now!
To no one's surprise, the Ascendant takes out the Gosforth in under 30 seconds. Without beams. With that task finished, the Ascendant warps to Aquinas Station...
and is miraculously healed from its injuries...
Makes sense, the two ships are technically different to the game. So let's fix this with some events now!
We're going to make two events. "Make Ascendant Warp Out" and "Copy Damage". Copy Damage will be chained to the warp out event, with a delay of around 3 seconds. Set up the events inside like so. You can see I've basically moved the departure cue to its own event and I'm just referencing that event now.
You can find ship-copy-damage under Change -> Special.
ship-copy-damage copies the damage stats for one ship and modifies them to any number of ships. The only requirement is that our original ship must present in the mission. It can't have already left. But anyone that is on the receiving end doesn't have to be there yet.
Now why is there a delay? Why not just put ship-copy-damage right with our depart event? Well it takes time for the ship to speed up and actually depart. In that time the ship can take damage. So if we fire it too early, the damage won't be totally accurate. So we'll put up a small delay before we actually copy the damage. Not that it matters here too much... Hey let's add a second hostile Fenris, the Ledberg.
So the Ascdendant was leaving with around 82% hull...
and arrives with 81% hull! (Also note the damage on the flak cannon, damage from subsystems carries over too!)
Something must have hit it on its way out. Man, if you had had used the ship-copy-damage too early, you would have people calling you names because that ship healed itself by 1%.
Well, now you know how to make larger ships micro-jump! That ends this episode of... Oh, you were here looking for how to do player micro-jumping.
Okay, let's do that too. Why should the Ascendant be the only ship that saves itself 17 minutes by warping there. And here I am using my sub-light drives like a sucker.
Player In-Game Jumps
This is the mission file at this stage. It includes everything for the capital ship micro-jump tutorial.
The Thought Process
Let's think about how we want the micro jump to work.
Obviously we want to press something and have a warp effect appear, then we have something like a fade to white, maybe a subspace corridor, then another fade to white and we appear at our destination. Sounds simple enough!
Let's go in order here.
"Obviously we want to press something..."
What key? Alt-J? Sounds cool. But wait, that basically ends the mission anyway. Hey can't we just never-warp the player, like in that SOC mission? We can! Problem solved, right?
Oh, that doesn't look good. It would be kind of odd for that to pop up while you activate your jump drive... and jump.
Ok, let's scrap that event and go to the Misc screen on Alpha 1's Ship Editor. We're going to tick the "No Subspace Drive" box. So now when he hit Alt-J, the game sees that box and goes "You don't have a Subspace drive, so I'm not going to do anything!"
Serious SEXPs are Serious
Now let's get real serious with events here. Make the following events. Don't worry about the chain delays right now, we'll go through each event one by one.
First, "Pressed Alt-J". We're going to use this event to lock the player from his controls. We don't want him moving around and missing the warp vortex. So let's use player-use-ai, clear Alpha 1's goals (Alpha 1 actually receives orders when you tell Alpha or Everyone to do something, so we need to clear those), and tell Alpha 1 to play dead with a priority so high that the player cannot tell himself to do anything. Then let's lock all our weapons and afterburner to make it complete. The AI sexps can be found in AI and IFF and the lock sexps can be found in Subsystems and Cargo.
Now when we tell the ai-player to play-dead, he's going to stop. This might be odd, since ships still have speed when they warp. So let's use ship-lat-maneuver. It allows us to tell ships to move any way we want, but there is a catch. Any movement from the player or AI can completely stop this. Since the ai is set to play-dead, we shouldn't have any problems. I've set the sexp to make Alpha 1 use 33% forward thrust for 15000 ms (15 seconds, that should be good for our entire sequence). ship-lat-maneuver can be found Coordinate Manipulation.
Also give it some directive text so our player knows he can jump and what button to press. If you didn't already know, the $ signs around a key will change if someone has remapped it. So if I remapped Alt-J to Spacebar, it would show up as "Jump to Aquinas Station, Press Spacebar".
Next, Warm Up! We'll use this to play the subspace warm up sound and flash a gauge. Delay here is 0, so it could be put in with the last event, but I got limited space here. hud-display gauge can be found in Hud and play-sound-from-file can be found in Music and Sound.
hud-display-gauge only works with the warpout gauge right now. Basically you put in how long you want it to appear in milliseconds and select warpout. For here we're going to go with 4 seconds.
play-sound-from-file lets us play... sounds from a file. Madness, I know. We just tell it what sound to play and that's it! The FS2 sound used for subspace drive warm up is called rev1.wav, so we'll put that in. It can play anything from a sounds or music folder, but only one sound at a time. One other thing to remember is that this sexp will make the sound play as music. So if you have your music volume turned down, you won't hear anything from that sexp.
Alternatively, you can make a training message, assign it to play rev1.wav using the training-msg sexp instead, and it will play on the voice channel. This might be required if you are already using play-sound-from-file for something else like music.
Cool note from the future: In builds 3.6.16 and beyond, you can also use play-sound-from-table using the sound index 50. There are a bunch of coordinates that appear with the sexp, but you can safely ignore them since the sound isn't a true 3d sound (which requires those).
warp-effect and Relative Coordinates
Now for the fun part. Show Warp 1. Can you find the magical warp-effect sexp in Special? There's a lot of arguments here! Let's look at what the arguments do for a second.
- 1: Origin X
- 2: Origin Y
- 3: Origin Z
These are where the effect will appear.
- 4: Location X
- 5: Location Y
- 6: Location Z
These are where the effect is going to point.
- 7: Radius
This is how big the effect is going to be.
- 8: Duration in seconds (values smaller than 4 are ignored)
Gee, I wonder.
- 9: Warp opening sound (index into sounds.tbl)
- 10: Warp closing sound (index into sounds.tbl)
For reference 45 is a warp sound for fighter arrivals, 46 is a warp sound for fighters departures (45 and 46 are the same sound in FS2, warp_1.wav), 69 is a warp sound for capital ships arriving (warp_open.wav) and 70 is a warp sound for capital ships warp vortices closing (warp_close.wav).
- 11: Type (0 for standard blue [default], 1 for Knossos green)
Self explanatory as well.
- 12: Shape (0 for 2-D [default], 1 for 3-D)
It's probably a good idea to keep this at zero. If its 0 and people have the 3d warp flag on, the game will turn it into a 3d effect anyway.
Ok, so now lets set the Delay to 4 so the effect appears when our hud gauge is finished flashing.
NOW WE ARE GOING TO MAKE SOME MISTAKES. You don't need to do this part unless you like redoing work.
Making the warp effect appear infront of the player is easy, but you need to understand WHY some certain sexps act the way they do. To do that, we're going to take chances and make mistakes!
Origin of our effect should be about 100m in front of the player. So you might think X and Y should just be Alpha 1's position, and then we add 100 to the Z coordinate. Let's try that and see what happens. For now we'll just change the Origin and Location and leave the rest as default.
Let's try this in game.
Hey wait! That worked just like we wanted. Why did I say this was wrong? Let's try it again only move the player a bit.
We... missed the warp hole. Why? Because we're using a global coordinate system here. Let's look at what we told FRED.
- Origin X = get-object-x Alpha 1
- Origin Y = get-object-y Alpha 1
- Origin Z = get-object-z Alpha 1 + 100
So if we never move from 0,0,0, then the warp origin appears at 0,0,100. Which as we can see from the pic, is exactly where the player is facing.
But if we rotate the player a bit...
The player's location didn't change, so the warp effect is still going to appear at 0,0,100. But the player isn't facing 0,0,100 anymore.
Let's take a look at the get-object-* sexp a little closer...
- Returns the absolute Z coordinate of a set of coordinates relative to a particular object (or object's subsystem). The input coordinates are the coordinates relative to the object's position and orientation. If no input coordinates are specified, the coordinate returned is the coordinate of the object (or object's subsystem) itself. Takes 1 to 5 arguments...
- 1: The name of a ship, wing, or waypoint.
- 2: A ship subsystem (or "<none>" if the first argument is not a ship - optional).
- 3: The relative X coordinate (optional).
- 4: The relative Y coordinate (optional).
- 5: The relative Z coordinate (optional).
Look at those WORDS. What on Earth do they mean? Well first, if there are no optional arguments, the sexp just returns the global coordinate of the ship or subsystem. Thats what we were going before. But if the relative X Y Z coordinates are there, it will return a coordinate that is X, Y, Z from the ship, taking in account its own position and orientation.
Well that was easy, we just need to do something like this then, right?
Let's try it out.
We're still off! But why?!
If we look at the sexp, we see we're only changing the Z coordinate. So the sexp is keeping the warp effect on X=0 and Y=0. Here's a pic to show this.
Warp Point:1 is where we want our warp effect to appear, but Warp Point:2 is where the game is calculating it to be. The solution is easy. We just tack on the rest the same optional arguments to get-object-x and -y! It should look something like this.
Basically we tell the game to place a warp effect so that its X, Y, and Z coordinates are 0,0,100 from the player. Easy peasey. Let's try it.
Hooray! I moved my fighter so he's facing something totally different, and yet the warp effect still appears directly in front of me.
MISTAKE TIME IS OVER. Add that stuff to your event now! Then lets tweak the size of the effect so it doesn't completely block our view at first. And modify the sounds so they are the fighter style ones, 45, and 46.
Fading Through Space and Time
Now lets move on to the most easiest event ever. Fade Out 1. Chain delay it for 2 seconds. And add in a fade-out sexp for 1000 ms, set the second argument to fade to white. fade-out is found in the cutscenes event menu.
The fade out will help with our transition into subspace. The subspace corridor is optional, but you might want it there for rule of cool. If you're jumping across the system you might want a quick flash to one. We're going to add one to this example anyway.
So in our next event, Subspace Corridor, we'll put in a Chain Delay of 1, so as soon as the fade out is finished, we'll fade into the subspace corridor. We'll use the mission-set-subspace sexp to put us in subspace for a bit. The mission-set-subspace sexp is found in Backgrounds and Nebula. Set it to 1 and we'll be set. And for fun let's turn shields off, those don't work in subspace!
And finally let's move the player far far away so he doesn't see anything that might ruin the experience. Even though we made the background a subspace corridor, everyone is still around fighting. So we're going to move him to 0,50000,0 and make him face 0,50000,1000. So the player will be 50km above everyone and since the controls are still locked, he can't see the battle still going on below him. This is where you would make ships depart if you weren't going to see them for the rest of the mission (such as if you were going from planet to planet in a mission).
Ok, so lets make a new Fade Out event for our transition back to normal space. Name it Fade Out 2 and chain delay it by 5 seconds. We're going to cram the last warp effect and fade out sexps together here. Just copy and paste them.
Time for Fade In + Move Player. Chain Delay of 1 here people. Now we're going to move and orient the player, make another warp effect and fade back in. We'll do all the moving and stuff first so the fade in only starts after we're finished goofing around. I put a pair of waypoints down to use as an anchor. You can just key in the coordinates yourself, but if you need to move the warp in position, its a lot easier to do by just moving a waypoint. The first waypoint is going to be where we drop Alpha 1 and the second will be what he's going to face.
Set up your sexps like so.
We're going to make our warp effect real short and we'll keep the default sounds so you hear the closing one when the vortex starts to close. You're sick of hearing the normal effect by now, aren't you? This is also where you would set up ships to instantly arrive or change backgrounds if you wanted.
Then finally in Regain Player Control, we set a chain delay of 1 and we remove the locks on weapons and give control back to the player. And shields. Can't forget shields.
Let's give it a whirl!
Finishing It Off
Cool, wasn't it?
But we left before the battle was over. Command would not look too kindly on this! (If you did stay, then kudos)
Let's set up some events to only allow the player to leave after the two Fenrises have been killed.
Boy, that was easy. But we are missing one thing.
The way the key-press sexp works is that as soon as you press a key, a key-pressed check against the key will remain true even if you pressed it once 15 minutes ago. So if we chain "Pressed Alt-J" under Kill Fenrises, and we press Alt-J before the Fenrises are dead, nothing happens. But as soon as those Fenrises die, the game goes down the chain and checks to see if Alt-J was ever pressed. And it was. So it warps you right away! The key-reset sexp will reset the key pressed status. So lets set up this chain.
Now what happens if we want to jump out in the end? We don't actually have a subspace drive on our fighter. By using the force-jump sexp, you can force the player to jump into subspace, even if he doesn't have a subspace drive. Set up the events like we did before. Remember to key-reset! The only caveat is that you cannot cancel a forced-jump by hitting escape. Oh well...
Jumping In Other Fighters
Now what about my fighter friends? They didn't warp. There's a few things you can do here. Fighters are pretty small, so you can modify their position at the same time as the player without too much notice. But if you MUST do all the proper warp effects for your wingmen, we're going to go into AXEM'S PERFECT FRED CLASS.
A degree in conditional arguments is required to make sense of this. If you don't know what those are, then you're done here.
I'm going to fly through this, so hold on to your hats.
First we kill the AI in the rest of Alpha wing.
Then we make the warp effects appear.
Then we move them somewhere safe for a bit. We'll make them go -50000m down so the player won't see them. Collisions shouldn't be a big deal, but we can make them invulnerable if you wish. Just remember to take that off later.
Next we'll need to place them by the player. Let's use waypoints like we did with the player. We won't bother with orientation too much.
Now we move them by the player once he's been placed and do a bunch of other stuff, like clear the play dead orders. (Which just got cut off from the last pic :( )
And that, as they say, is that. If you give it a try, the fighters should warp out with you and warp in when you warp in.
Here's a link to the mission file so you can see what the finished product looks like and identify anything you might have done wrong.