At some point someone will do an awesome Wiki article like Axem's guide to tactical jumps. (http://www.hard-light.net/wiki/index.php/Tutorial_-_In-Mission_Jumps) It'll have pictures and it won't be dry, rambling, and boring as ****.
In the meantime, here's the Blue Planet guide to rigging up mid-mission checkpoints in FreeSpace Open. It's hastily written and bad! Sorry.
This is a guide for those already fluent in FRED. It's not going to hold your hand. It's a low-quality guide compared to Karajorma's FREDDOCS or Axem's jump guide; it doesn't have any pictures of the events editor, or a sample mission to build and help you along. Here's the general outline:
- Finding a good spot for a checkpoint
- Setting up your checkpoint save using PPVs
- Setting your checkpoint load
- Allowing the player to load the checkpoint, and disguising the load process with a fadeout
- Making your mission logic checkpoint-compliant
Here's a really simple diagram of how the checkpoint logic works:
badttuta's bad diagram
Normal playthrough:
MISSION START - INTERIM 1 - SAVE EVENT WRITES TO CHECKPOINT VARS - INTERIM 2 - MISSION END
Checkpoint playthrough:
MISSION START - CHECKPOINT LOAD WINDOW - CHECKPOINT LOAD CALL - INTERIM 1 BREAKS - FADEOUT - LOAD EVENT LOADS FROM CHECKPOINT VARS - INTERIM 2 BEGINS - MISSION END
STEP ONE
make a fred
Make sure to design your mission with what I like to call 'mission phase space bottlenecks'. People who aren't assholes call these 'calm spots'. You need to make sure that the mission contains at least one moment during which there will be no active combat and as many ships as possible are at known, predictable locations. Here is a useful checklist:
- There's no fighting going on
- Large ships are at a predictable location - for example, the end of one set of waypoints, or 5000 meters from a target they're approaching
- The player can be expected to be in a particular location - for example, near a ship she's guarding
- The mission SEXP script is coming up on a major trigger event. You can easily jump the script ahead to this point without breaking the mission logic. (this one's the tricky one)
These criteria aren't all completely necessary, but they'll help you avoid going over your variable budget.
Now we'll start on the checkpoint.
STEP ZERO
office of player persistent variable budget control
The key element in the checkpoint system is the Player Persistent Variable, or PPV. Unlike other variable types (campaign persistent, for example) this type of variable is not set at mission end - it's set immediately and stored in the player file.
Unfortunately, you're only given 100* of them per campaign. This means you need to be economical in their use.
Now that you've identified WHEN in the mission your checkpoint is going to happen, you're going to use PPVs to store the location, hull state, and dead/alive status of key ships in the mission. There are two steps to a checkpoint: the SAVE and the LOAD. We're going to rig up the SAVE first, because it's a lot easier.
Keep in mind there are some factors you can't currently save: mission clock time, countermeasures fired, and player kills among them.
STEP TWO
every morning i wake up and open palm slam a vhs into the slot
Create two events - we'll call them CHECKPOINT LOAD and CHECKPOINT SAVE. Set them up to trigger at the calm spot you've selected.
Use the FRED events editor to create a series of Player Persistent Variables. You need one for the hull state of each ship you're going to save. (Bear in mind it's often safe to ignore the hull state of smaller ships like fighters and bombers -- though you should probably save the player's hull.) If you're going to save the position of a ship, you'll need three additional variables for its X, Y and Z coordinates. (With new improvements in the SCP, it may be possible to save these as a single number, then break it into three values when you want to load the checkpoint.)
Make sure to give these variables consistent names like alpha1hullstate, alpha1x, alpha1y, alpha1z.
Now, expand CHECKPOINT SAVE. Make sure you've got the trigger condition where you want it. Make sure this trigger condition is not based on the mission clock - you may want the SAVE to work properly even if the player has loaded a checkpoint, or you might want to disable it if the player has loaded a checkpoint. (You can use 'or' to good effect here: six minutes have elapsed in mission time, OR checkpoint 1 has been loaded.) Rig up events for each ship you're saving to read the necessary information (hull state at minimum, possibly coordinates) and write it to the variables in question.
You'll probably want to test the mission right about now. Rig up some messages to print these variables and make sure they were stored correctly. I've had some trouble with ships destroyed as of CHECKPOINT SAVE not saving their hull state as 0, so you may need to mix in additional variables to indicate whether a ship's been destroyed.
Sometimes you don't want to waste three PPVs to save a ship's position. You just want to set it to the same place every time the checkpoint's loaded. To get a good idea of where a ship is at any point in the mission, rig an event that prints the target ship's X, Y and Z coordinates to the training message box in your HUD, and have this event update every second. You can monitor a ship's coordinates and figure out where it is at the point when your checkpoint should be firing. You can just write the numbers down.
Another way to save PPVs is to use relative coordinates. Say you know three fighters will be escorting a freighter - you can save the freighter's position, and then just assume the fighters will be positioned in a triangle relative to it. This is a good way to put the player's fighter near a ship he's guarding.
Congrats: you're now saving coordinate and health information on the ships you've selected. There's one more key thing you need to do: set up a player persistent variable called 'checkpoint1unlocked' or something like that. Arrange for it to be set from 0 to 1 to indicate that the player has unlocked this first checkpoint.
Time to move on to the hard bit, the LOAD.
STEP THREE
it's chronicles of riddick and right then and there i start doing the moves alongside the main character, riddick
Expand your LOAD event. Don't worry about the trigger for now. We're going to work backward: set up the back end of the LOAD event first.
Imagine for a moment what this event is going to do. It's going to take the mission's initial state and rearrange it to resemble the saved state. In order to do this, it needs to achieve the following:
- Change the hull state of all starting ships to the saved state
- Remove ships that are saved as destroyed
- Move ships to their saved coordinates
- If you're really OCD, alter the player's missile capacity and even weapon loadout to the saved state
- A tricky one: cause ships that hadn't arrived at mission start, but should have arrived by the checkpoint, to jump in, and, if necessary, move to a new position
You need this event to accomplish everything, at least in abstract, that should've happened in the part of the mission you're skipping over.
The first thing you should do is use set-object-position to grab every ship from mission start and slap it in its slaved spot.
Next, delete ships that should be destroyed. You may want to use vanish instead of self-destruct, but bear in mind this won't trigger is-destroyed-delay conditions.
Sabotage hull subsystems to get ships to their correct hull state. If you want to save key subsystems on capships, here's the time to take care of that as well.
Do anything else you want to do, like alter player missile capacity or loadout based on saved info.
You may need to do some other kung fu as well. There's no way to save orientation state, so you may need to do some set-object-facing-object. Clear AI goals and set them to what they need to be. Make sure ships don't do anything dumb with their waypoint paths, like starting the whole thing over from the beginning. Make sure subsystem and ship guardians have been properly applied to ships that need them.
Here's a tricky bit: there may be ships that we need to cue to warp in, then quickly move to a new location. Set up their arrival triggers to include an OR condition which triggers at checkpoint load. Immediately kill the ship's entry momentum with a SEXP (this is glitchy and requires some work), then teleport them to where they want them, and apply any necessary hull and subsystem damage AFTER they arrive.
Bear in mind we still haven't told this LOAD event when, exactly, to fire. We're going to move forward a little further before you do that. You need to look at your mission logic going forward, and make sure that the flow of the script can continue based off either a normal mission play or from this checkpoint LOAD event. This should be easy as long as your mission logic is pretty linear, but it may take some finesse. I'll leave that as an exercise for the FREDder.
Time for the next step: arranging for the player's ability to fire the checkpoint, and actually triggering the LOAD event.
STEP FOUR
i do every move and i do every move hard, makin whooshin sounds when i slam down some necros
Let's look at what we have right now:
Mission start (the mission starts)
A LOAD event which sets the mission up the way we want it once the checkpoint loads
A SAVE event which stores the mission state. (You may want to alter the trigger for this event so it won't fire if the checkpoint has been loaded - this can lead to weird behavior.)
Since the SAVE event sets our checkpoint1available var from 0 to 1, the player will have access to this checkpoint after they've played through the mission once. (You may want to have a training message or HUD gauge indicate when the checkpoint's unlocked.) For testing and dev purposes, just set this var to 1 at mission start.
What do we want to happen if the checkpoint is available? Well, to keep things convenient, I usually give the player a 10 second window at mission start to select the checkpoint - if they don't do it right then, they're committed to a normal playthrough. If you let the player load the checkpoint at any time, you can cause all sorts of mess.
Let's set up an event which checks whether the checkpoint1var equals 0 or 1. If it's 1, we want to show the player a message. You can use a training message or a new HUD gauge.
Now, figure out how the player will tell the mission to load the checkpoint. In BP, we allowed the player to call in a com buoy from the reinforcement menu named 'Load Checkpoint 1'. Another approach is just to tell the player to press Alt-X or Alt-A, or 1 or 2 on a menu if you have more than one checkpoint. Remember, make sure the player can only take this option for the first 10 seconds or so of the mission.
No matter what happens, you should have a single flag which goes from 0 to 1 to indicate that the player has asked for a checkpoint load. We'll call this LOAD CALL. But you don't want the LOAD event to fire right away, or the player will see everything teleporting around. So once LOAD CALL fires, the first step is to fade out to white and lock the player's controls.
Once the fadeout to white is complete, fire your LOAD event. Give it another second, then fade back in and unlock the player's controls. Congrats! You've loaded your checkpoint.
But there's a problem: your mission start logic is probably still running.
STEP FIVE
not many can say they escaped the galaxy's most dangerous prison
Because you read this tutorial all the way through before starting your mission, you're going to know from the start that your pre-checkpoint mission logic needs a break point. After your 10 second starting window, check whether the LOAD CALL has fired. If it hasn't, mission proceeds as normal. If it has, break your mission logic and then resume from the point of the LOAD.
You'll also need to suppress any messages or events that would've fired before the checkpoint when, say, a loaded ship took damage or exploded. You don't want your checkpoint loading and immediately firing 15 messages about how ships have taken damage.
Okay I'm probably forgetting a bunch of important **** but congrats, off the top of my head I think you've got the rough outline of a working checkpoint! Time to check it a billion times. Ask me questions and point out my dumb mistakes here in this thread.
I'm skipping over a lot of finesse here. You need to build the whole mission with the checkpoint in mind, using clean, easily broken chains of mission logic. But if you're a good FREDder you'll have no trouble, and if you're not, it'll be a great way to touch up your skills. Good luck, and happy loading!
next time on battuta writes words: the easy business of dialogue skips