[Nuclear1]

Five Things You'll Forget To Do Before You Release

Alright, so your campaign is nearly done.  You've got everything you need for a great mod--shiny new ships, a compelling storyline, memorable characters.  The mod's certain to be an instant hit.

So you log onto Hard Light, you head to the Missions and Campaigns Forum, and you start a new thread:  RELEASE:  MY AWESOME MOD.

You go to sleep, satisfied with a job well done.  After dreams about people falling in love with your campaign, you wake up in the morning, eagerly refresh Missions and Campaigns (because, let's face it, you never even logged off), open your thread, and...

Oh no.

"CTD for me on Mission 2"
"There's no objectives for the third mission..."
"(epic long FRED error dump)"
"dude, it's spelled T-U-R-R-E-T"
"ah god this thing is a nightmare"

It seems, in your eagerness to post your campaign, you missed a few things.  Well don't worry, because I'm going to tell you exactly what it was you forgot.


#5 -- You Didn't Make A .VP

The Complaints You'll See

"Why is the mod so big? Couldn't you compress it?"
"Which folders do these files go in?"
"Did I get all the files...?"

Why This Is Important

.VPs are, quite simply, an easy way to manage your campaign's files.  Instead of you (or, worse, the users) having to create individual folders and sort out the files, you can compile a .VP and let that one file sort out all of your organization issues.  The process of making a .VP essentially involves you organizing the files in the same way you would without one, but it all becomes compressed and neatly organized in one file. 

Easy for you to organize, patch, and keep track of, and easy for the user to install.

Crap, How Do I Avoid This Problem?

Head on over to FreespaceMods, and find the VP Editors section in the downloads (or just click me).  VPMage and VPView are essential tools.  VPView allows you to open and extract files from a .VP, and VPMage allows you to build a .VP

#4 -- You Didn't Make A Mod.ini

The Complaints You'll See

"Do I need mediavps for this?"
"It said it can't find a ship class..."
"This needs FSPort?  I'm not copying into my FSPort folder..."

Why This Is Important

You don't want to ruin people's Freespace folders.  Freespace Open is touchy enough when it comes to installation that you don't want people improvising to get your mod to work.  It'll break their installation and cause them to come after you with the nonfunctional flamethrowers.  They don't actually shoot flames, they're filled with water, but they still hurt when you get clubbed by angry HLPers.

The mod.ini file allows you to configure how your mod looks when it's selected in the Launcher, and, more importantly, it designates which mods it's supposed to use in conjunction with yours.  Say, if your campaign is based on FSPort, you would designate FSPort under the multimod section.

Crap, How Do I Avoid This Problem?

Nearly every single mod released in the last year has a mod.ini file included.  You can simply copy/paste in your mod's folder and makes changes as needed.  Or, if you want to learn how mod.ini's are constructed and do it yourself (not recommended), you can head here.

#3 -- You Didn't Test On A Recent Build

The Complaints You'll See

"CTD on mine...using a nightly"
"dude which build did you test this on?!"
"*unbelievably stupid long error dump message*"

Why This Is Important

As our wonderful Freespace Open programmers continue to work on the Source Code, they publish builds on a regular basis.  Lots of people have a habit of working with an older build (one of these may be you, in fact), but many choose to update fairly regularly with the Nightly Builds. 

While changes aren't typically drastic between builds over the course of, say, two weeks, or even a month, if you're still using a build from 2010, your mod is likely to have compatability issues with some of the more recent builds. 

Crap, How Do I Avoid This Problem?

Update your Freespace Open Build on a regular basis.  It doesn't have to be an update every time a new build is released, but once a month or once every two weeks is a good way to go.  When it comes time to test, download the most recent build, no matter when you last updated, and test your missions on that.  You don't necessarily have to build-creep, but keep a fairly recent one handy.

You can also have playtesters with other builds do your testing for you, which brings us to our next topic...

#2 -- You Didn't Test, Period

The Complaints You'll See

"Mission X is way too easy/hard"
"There's no RTB directive...."
"i accidentally mission 4 is this bad"

Why This Is Important

Testing may very well be the most important part of finalizing a mod.  It allows you to weed out all of the nitpicky or show-stopping bugs in your campaign, and it shows you did a damn thorough job in making sure your campaign is top-notch.  It allows you to avoid the absolute headache of having to continually patch annoying problems that should have been caught on the fifth or six playthrough of a mission.

Let's face it, when you design a mission, you know how it's supposed to play out.  You go into the mission knowing how the player is supposed to react to everythin that happens, and you play the mission how you know it's supposed to be completed.  The end-users don't know this, however, and if they play even remotely differently than how you intended, they may break the mission or cause some bug to pop up that you hadn't expected.

Crap, How Do I Avoid This Problem?

Recognize that very bias as soon as you're done FREDing.  Realize that others will play your mission differently, and use that to your advantage.  Have some playtesters go through your missions, and make it their goal to try to break your mission in every way they can imagine.  The more perspectives you have on a mission and the more playthroughs you have, especially of your more complex missions, the more possibilities for errors and bugs you and your playtesters can locate and correct.

The honest truth is that, no matter how much testing you do, your campaign won't be 100% mechanically sound.  Lots of people will play your mod, and the more people play, the greater the chance that someone will find a new and interesting way to make your mod break.  But it's much easier to do one patch for an error that comes up weeks after release than doing many patches for bugs that come up instantly upon release.

Bugs you can avoid if you test.

#1 -- You Didn't Spellcheck

The Complaints You'll See

"T-U-R-R-E-T"
"wth is a detstroery"
"i before e except after c n00b"

Why This Is Important

Alright, I'll be fair, spellchecking won't break your campaign.  Spellchecking is never a show-stopping bug.  But it does show a lack of scrutiny, a lack of testing, or not having a firm grasp of the English language.

It shows a level of professionalism when a mod is released and there's no significant grammatical or spelling errors.  It just makes the mod look nicer.

Crap, How Do I Avoid This Problem?

While you're playtesting, have your testers look for spelling and grammar errors as well.  Or, better yet, ask a native speaker to go through your mission files and correct to their heart's content.  Spellchecking is something that doesn't take a whole lot of time, and there's plenty of native speakers in most languages on Hard Light that would be more than able to go through your mission files in an evening or an afternoon they have free.

[MatthTheGeek]

#5 -- You Didn't Make A .VP

The Complaints You'll See

"Why is the mod so big? Couldn't you compress it?"

Well, keep in mind that .vp isn't compressing anything at all. It's just a package easy for the game to read.

#3 -- You Didn't Test On A Recent Build

The Complaints You'll See

"CTD on mine...using a nightly"
"dude which build did you test this on?!"
"*unbelievably stupid long error dump message*"

Why This Is Important

As our wonderful Freespace Open programmers continue to work on the Source Code, they publish builds on a regular basis.  Lots of people have a habit of working with an older build (one of these may be you, in fact), but many choose to update fairly regularly with the Nightly Builds. 

While changes aren't typically drastic between builds over the course of, say, two weeks, or even a month, if you're still using a build from 2010, your mod is likely to have compatability issues with some of the more recent builds. 

Crap, How Do I Avoid This Problem?

Update your Freespace Open Build on a regular basis.  It doesn't have to be an update every time a new build is released, but once a month or once every two weeks is a good way to go.  When it comes time to test, download the most recent build, no matter when you last updated, and test your missions on that.  You don't necessarily have to build-creep, but keep a fairly recent one handy.

Well, this isn't really necessary. Using the latest stable build is enough, in our case 3.6.12. Remember we are still all playing a campaign that was tested for a 11 years-old build : the main Freespace 2 campaign.

Tis all for now. Lemmie wake up...

[Jeff Vader]

#5 -- You Didn't Make A .VP

The Complaints You'll See

"Why is the mod so big? Couldn't you compress it?"

Well, keep in mind that .vp isn't compressing anything at all. It's just a package easy for the game to read.

Well, probably as easy as reading files from \freespace2\data\ or \freespace2\mod\data\ . But .vps are considerably easier for end-users. Instead of figuring out where to put which file (if the releaser was polite enough not to create the necessary directory structure), the end-user can simply punch .vp files of <mod> to \freespace2\<mod>\ and be done with it. Also eases up troubleshooting, as debug builds can count the number of files in each .vp, and some checksums.

[MatthTheGeek]

That's true. Also, if/when LMZA support is implemented, we'll have true compressed packages. Let's just not advertise VPs for wrong reasons. Those you mentioned are good enough reasons.

[Zacam]

Actually, the biggest issue I've personally witnessed is:

People assuming that because the mod runs on the Release build = Everything is hunky dory

-Always- (regardless of the build version, but at the very least always use the latest stable build) run the mod through Debug versions of both FRED and FSO.
Open the LOGs and pay attention to the listed issues. Immediately address -any- crashes that occur or warning dialogue pop-ups or Warnings windows.

When in doubt: Post to the Support Thread or the Missions/Campaigns thread with logs (pastebined or in code tags) and any number of people will be able and possibly willing to help you out with A: Understanding what it all means and B: resolving as many of them as possible.

If I see that a mod has only ever been run through Release builds before release, I just flat out won't bother downloading it.

[bigchunk1]

#1 -- You Didn't Spellcheck

...

Crap, How Do I Avoid This Problem?

While you're playtesting, have your testers look for spelling and grammar errors as well.  Or, better yet, ask a native speaker to go through your mission files and correct to their heart's content.  Spellchecking is something that doesn't take a whole lot of time, and there's plenty of native speakers in most languages on Hard Light that would be more than able to go through your mission files in an evening or an afternoon they have free.

I suck at spelling, but the best way I have found to deal with the issue is copy-paste your fred work (briefings, command briefings, messages etc.) into a word document and run the spell checker on it. It will catch everything, it's wonderful.

The larger problem is grammar, i.e. using "Get they're ships!" instead of the correct "Get their ships!". These kind of fixes more or less require a human to read your material over before release. That is unless you feel confident enough in the language you are writing the material in, where careful proofreading might be all you need.

For large projects, a tester is recommended either way.

[Snail]

Don't use a spellchecker, that doesn't help and if you do run it by a tester eventually it might even make errors harder to spot.

[bigchunk1]

Don't use a spellchecker, that doesn't help and if you do run it by a tester eventually it might even make errors harder to spot.

  Why?

[headdie]

Spell checker is a good step one but it wont catch words that are spelt wrong but still form an actual word.  At the end of the day you can't beat a human who can spell

[TopAce]

Because all it can do is check whether a given string of letters has a dictionary entry. Like you said, it cannot differentiate between they're and their or hangar and hanger.

It also cannot fix punctuation mistakes, so it will recognize the "Good work pilots return to base" string as correct, which it is not.

Also

Which witch is which?

Spellcheckers are for quick fixes, like determining whether it's independence or independance. It's also useful for typos--I mean mistypings like capacty.

[Snail]

Don't use a spellchecker, that doesn't help and if you do run it by a tester eventually it might even make errors harder to spot.

  Why?

Outright spelling errors are often easier to spot than words just used in the same context.

[bigchunk1]

I don't understand why you think a spellchecker is not a helpful tool for catching spelling errors.

As for making grammar harder to spot, I would argue that a more unreadable text, i.e. a text wrought with spelling errors, is actually more difficult to proofread because the writer's meaning is even more convoluted. Also, a spelling error isn't necessarily a breadcrumb which leads to a grammatical error, so I don't see how intentionally leaving out half the editing work for the tester to mull over is helpful to either party.

Headdie/Topace: Spellcheckers do not catch grammatical errors, I agree, but it is a tool to aid the proofreading process.

[TopAce]

I would argue that a more unreadable text, i.e. a text wrought with spelling errors, is actually more difficult to proofread because the writer's meaning is even more convoluted.

Yes, of course much depends on the quality of the actual material. I was just trying to say not to rely on spellcheckers only. While playing INFA, I felt it was run through a spellchecker, yet it was full of punctuation errors and mixed-up words. The above "Good work pilots return to base" example is from INFA.

[karajorma]

A spellchecker won't magically make your text error free. It will avoid you annoying your grammar checkers with a horribly misspelled mission which they have to fix.

I suck at spelling, but the best way I have found to deal with the issue is copy-paste your fred work (briefings, command briefings, messages etc.) into a word document and run the spell checker on it. It will catch everything, it's wonderful.

Why are you cutting and pasting? Use the Voice Acting Manager to print out the script for you.

[Silent Warrior]

Nuclear1: I like you. Lots.