Upgrading campaigns
- This article requires proofreading by native speakers of English
Upgrading a campaign means editing someone else's work. This means that the changes a FREDder can make are somewhat restricted, but could still improve gameplay in a radical way.
Unless the original campaign creator is available to assist, radical changes are to be kept to a bare minimum.
Contents
Guidelines
Upgraders
Finding the problems
Although most of the bug-hunting job is up to testers, FREDders are also encouraged to playtest campaigns in need of upgrades at least once.
There are several benefits: first of all, it's very important to get acquainted with the original campaign creator's FREDding style so that the upcoming changes can fit with the previous work. It's also extremely important when trying to supplement a tester's work and propose significant changes - testers with poor or nonexistent FREDding experience are focused on mission bugs and balancing while a FREDder may also analyze the campaign and decide wheter or not cutscenes and/or other special effects should be added.
Proper naming conventions
Naming conventions are of the utmost importance. There's nothing worse than making hard-to-guess edits with vague info. New events, for example, need to have comprehensive and exhaustive names. It's also important to track the FREDder who made the changes should problems arise.
Example:
- MBS - Destroy Transports Directive
In this example, the event has been created by Mobius and it's intended to show up a specific directive: "Destroy Transports".
Change logs
Change logs are necessary to track edits and undo them should problems arise. Each upgrader working on a project is supposed to attach a .txt file with the changes he made. The document needs to be exhaustive.
It's also recommended to post the contents of the change logs in the forums. Do not attach the .txt to a post, since attachments are deleted at regular intervals.
Testers
- See also: Testing
Compiling initial reports
Initial reports mark the beginning of an upgrade. During this phase, in facts, the most noticeable bugs and problems are found and discussed with the rest of the upgrade team.
Problems are various and aren't all supposed to be FREDding-related; certain campaigns are, in fact, old enough to give problems with recent builds of FreeSpace Open (or worse, with FreeSpace Open in general) so immediate edits are needed to test the campaign in a proper way.
The basic formula to create a report is the following:
- <Mission Name>
- Command Briefing:
- <Stage N>
- Text
- <Stage N>
- Command Briefing:
- Briefing:
- <Stage N>
- Text
- Icon placement
- Usage formula (eventually)
- <Stage N>
- Briefing:
- Mission:
- <Arrival of ship X>
- <Message X>
- <Time-elapsed particular event>
- Other
- Mission:
- Debriefing:
- <Stage N>
- Usage formula
- Text
- <Stage N>
- Debriefing:
As it can be easily noticed, Mission-related problems are harder to point out. This happens mainly because of the fact that a problem can occur because of a certain event becoming true or false anytime (or, at least, in a wide time window) during the mission. Even "easily understandable" events like the ones connected to the destruction or the arrival of a ship may result in problems if the conditionals are complex.
When compiling a report, it's worth reminding that a) it should be comprehensive for FREDders and b) it should respect the "One line per problem" rule, meaning that all reported bugs/problems shouldn't be mixed in the text file.
This:
- Ship Y departs too soon, one of its messages is sent by Command instead;
- Bomber wing Z, tasked to destroy Ship Y, remains immobile if the ship departs and the bombers are unsuccessful at destroying it;
Is much more appropriate than this:
- Ship Y departs too soon and bomber wing Z remain immobile instead of engaging the player and/or other friendly ships. One of the messages Ship Y is supposed to send is sent by Command instead;
Playthroughs
To be filled in later.
Compiling further reports
To be filled in later.
Sanity check
To be filled in later.
Basic edits
Grammar-checking
To be filled in later.
Hostile wings management
Although waved wings are rare in main campaigns, their use in custom campaigns is notable. For several reasons, an upgrader may have to change the number of waves and/or the delay between waves according to the reports compiled by testers:
Number of waves:
Editors ---> Wings ---> Edit the value placed near # of Waves.
Delay between waves:
Editors ---> Wings ---> Arrival ---> Delay between waves ---> Edit the Min and/or Max value.
Number of stars
Older campaigns were tested using FRED Retail. Back then, no starfield skyboxes were available, (the SCP added them) so the only ways to improve a background were to add nebulae and set the number of stars to the max value, 2,000.
Many fans complain about the presence of those stars because their usage results in certain render oddities, like the "distortion effect". A recent change to the code has made sure that the skybox overwrites auto-generated stars, but it's always a safer to the number of stars to 0:
Editors ---> Background ---> Misc ---> Number of stars ---> Set the value to 0.
Among the FREDding mistakes that can really screw up a mission, order-related ones deserve a relevant position. In many campaigns, in fact, it's possible to issue orders to transports, freighters, cruisers, and corvettes which are supposed to fly through waypoints and/or to follow certain orders. Ordering, by mistake or intentionally, to attack a ship and/or to capture a given target can lead to unpredictable results, like freezing the progress of a mission.
Unless it is clearly specified that the player is supposed to issue orders to such ships, it's very important to make sure that those ships will do only what they're supposed to:
Editors ---> Ships ---> Player Orders ---> Unmark all orders that the player can issue. The white squares need to be empty.
Even spacecraft can cause trouble because of their initial orders. It is possible to generalize on this subject and claim that the player, even in the role of squadron leader, should not be capable of issuing orders to all spacecraft. There might be fighters and/or bombers he has no authority on as well as units which are supposed to behave according to the original campaign creator's will without any interference (kamikaze runs, waypoints, suicide attacks, ignore certain allied ships, etc). It's also possible that certain spacecraft may need to receive orders by the player, but that should be an extremely rare occurrence.
It's also worth noting that in missions featuring characters, it shouldn't be possible to order those characters to depart anytime during the mission. If the player orders them to depart, all messages they were supposed to send will be sent by Command, instead.
Choosing the orders the player can issue is very easy:
Use the mouse or the Select List button on the interface (or, alternatively, press H) ---> Choose the spacecraft whose player orders need to be changed ---> OK (if using Select List, otherwise jump this step) ---> Player Orders ---> Mark/unmark the orders. Pay a lot of attention to characters.
Skybox models
Skyboxes are among the best graphical enhancements introduced by the FreeSpace Upgrade Project. Needless to say, as fan-made effects, skyboxes are totally missing from old campaigns.
Adding them is a must during the upgrade—they're the easiest and most effective way to show a good background even without any nebula. The standard skybox model released with the Media VPs is called "starfield". Adding it is easy:
Editors ---> Background ---> Misc ---> Skybox Model ---> Type "starfield.pof" without the quotes. There's no need to browse the model.
Timings
To be filled in later.
Unappropriate names
To be filled in later.
Weird warship battles
Often, FREDders order ships to engage each other in a fight by simply ordering them to attack each other. This is known to cause oddities, mostly under an eyecandy point of view—ships engaged in some sort of "dance" and/or involved in multiple collisions aren't worth watching. Obviously, this edit isn't necessary if all warships involved in the battle are supposed to remain immobile.
The best idea is to create waypoints the warships will then be supposed to fly through. If the warships are too fast and/or their starting distance is too short, it may be a good idea to reduce their speed. All of this can be easily done:
Removing orders:
Normal orders:
Editors ---> Ships ---> Initial Orders ---> Remove the order to attack the opposing ship.
SEXP-triggered orders:
Editors ---> Events ---> Find the event ---> Remove the add-goal SEXP. It may be a good idea to delete the whole event as long as it's not in the middle of a chain and/or there are other SEXPs other than add-goal.
Waypoints:
Creating waypoint paths:
Interface Shiplist ---> Choose Waypoint ---> Press Ctrl + Left bt. on mouse to add ---> Create, if necessary, a waypoint path ---> Name the waypoint path ---> Repeat this process for the other ships.
New orders:
Normal orders:
Editors ---> Ships ---> Initial Orders ---> Fly the selected waypoint.
SEXP-triggered orders:
Editors ---> Events ---> Find the event ---> Use the add-goal SEXP to order ships to follow their specified waypoints.
Speed:
Editors ---> Events ---> Find the warship's arrival event ---> Add the cap-waypoint-speed SEXP to set a reduced speed. It can be reset by choosing a speed of "-1". This may be necessary if a ship involved in a battle is successively supposed to fly through waypoints at max speed or, at least, at a speed different from the one showed during the battle.
If there are no events related to the warship's arrival and/or to the beginning of the battle, it's a good move to create at least one for better handling.
