Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: Nuclear1 on March 28, 2010, 07:26:40 am
-
This is the discussion thread for the Campaign pre-release checklist (http://www.hard-light.net/forums/index.php?topic=68817.0).
My personal biggest pet peeve:
Mission variety
Are your missions different enough to be fun and original? Will the player notice significant amount of repetition in mission design?
-
I don't think this thread is about the defaults of the campaign plot. I remember there was already a thread about "your biggest peeves in mission design" somewhere, let's try to stay focused on a "pre-realease checklist" point of vue.
If you're just about to release a campaign, it's a bit late to fully rework all your missions isn't it ?
-
Indeed. This is about avoiding technical issues, not issues regarding storytelling and mission design.
-
Even if I usually don't care about this, there are people who do, so you may want to add "making sure you credit everyone". Especially when adding new ships or whatever.
But that's minor. Most campaign designers do think about it and I've never seen any complain about that around here yet.
-
I spy some sticky-worthy stuff. Perchance, once there is enough agreement on the status of the list, the first post could be left as a sticky thread, with the rest of the discussion split apart from it (like with the MediaVPs release thread).
-
Even if I usually don't care about this, there are people who do, so you may want to add "making sure you credit everyone". Especially when adding new ships or whatever.
But that's minor. Most campaign designers do think about it and I've never seen any complain about that around here yet.
Noted.
-
Fair enough...we should have a condensed version of the pet peeves thread as a checklist for mission design too I think
-
Good stuff :yes:. I have a few suggestions:
Maybe an explanation (or a link to one) of what to include in the .vp. Like excluding mission.bak files and such.
Proper installation instructions, in order to avoid "put this in you main FS2 folder". A reference to the topic on the support board should do it.
Maybe emphasize the testing of the final product a little.
-
Remotely related to .vp files. Should there be a word or two about actual compression? The ever-so-hot Relentless, for example, had a single .vp file that was 84.4MB, but could be squeezed down to 33.2MB with 7-Zip. I like bandwidth in general, but I also believe there are many people who have issues of varying degree with downloading large files.
-
Okay, I'm not an expert at graphical and sound formats, so can anyone check what I wrote about it?
-
Actually, DDS files are probably on average larger than PCX, and uncompressed DDS files with mipmaps will be larger than TGA.. However, since they can be used directly by the GPU, their filesize corresponds 1:1 with the video memory usage for that texture.
In addition, they feature built-in mipmaps, which are a good thing to have in terms of performance.
You should also link to HerraTohtori's GIMP thread (http://www.hard-light.net/forums/index.php?topic=64769.0), which explains everything in more detail.
-
Okay, so DDS files are worse for downloading but better for playing?
-
Okay, so DDS files are worse for downloading but better for playing?
DDS is better, period.
*DDS
-Direct Draw Surface. Full of awesome and sauce. Use this whenever you can (except for work-in-progress editing - TGA is better for that purpose).
-should always have power-of-two dimensions, e.g. 32x32, 64x128, 512x1024, 2048x2048 or the like.
-to avoid strange issues with older graphics cards (http://img264.imageshack.us/img264/576/mvperror3yb0.jpg), make sure that both height and width dimensions are at or above 16 pixels. In other words, recommended minimum resolution is 16x16.
-DXT compression reduces video memory consumption to either 1/6th or 1/4th compared to uncompressed texture of same resolution
-DXT1 compression is for files with no alpha channel
-DXT3 and DXT5 compression include an alpha channel
-uncompressed DDS files can be used when the DXT compression is too hard on the image quality. u888 for RGB files, u8888 for RGBA files.
-some effects can also use u555 and u5555 formats. These are much the same as uncompressed 24- and 32-bit files (u888 and u8888), but instead of 8 bits per channel they have five. This makes them a good options for, say, converting PCX weapon effects and such without getting horrid compression artefacts. They are larger than DXT compressed files, but smaller than full 24/32-bit files.
-supports mip maps included in the image format itself
-speeds up loading times as the GPU can use this image format directly without need to convert it to uncompressed bitmaps, as is the case with PCX and TGA textures.
*TGA
-24-bit RGB or 32-bit RGBA files.
-alpha channel for transparency when needed
-excellent work-in-progress format
-high video memory use
-can be used for all modeling purposes to see how the stuff looks like - including normal maps.
-do not be confused by apparently very small TGA files. The TGA format supports run length encoding, which can significantly reduce file size for stuff such as starfields and some other texture types; however this will not reduce memory consumption because the encoding needs to be decoded before the bitmap can be sent to the graphics card to use and show to you.
-not recommended for final, distributed mods
...
*PCX
-native, retail-based FreeSpace 2 image format. Will work with the retail game assuming the stuff that uses it is also compatible.
-limited to 8-bit aka 256 colours (or 255 if you use one colour for transparency support)
-pure green (#00ff00 or [0,255,0]) is considered transparent as a rudimentary one-bit alpha channel
-ANI file frame format - when you're building animation files for interface, you'll need to use this format for now.
-should only be used for modding for Retail FreeSpace 2 or some of the interface art - mainly bits that are not yet compatible with more sophisticated image formats.
-
Indeed. DDS files compress really well in 7-zip or other compressed file formats, so the download bandwidth usage overhead is negligible.
-
Okay, fine.
-
how about pre-release testing by a couple of reliable people (outside the "team" if one was used to develop the campaign), either here or that you know through other sources using the planed release version
-
I know I said I wouldn't post again, but I just wanted to say I'm very happy to see this thread here and I hope it remains stickied and continues to be edited and developed. :yes:
-
Split for great justice. Only the first post shall remain stickied.
-
Will you lock it?
-
Can do, but while locked, only Swantz, Turey, global mods and admins can edit it. Then again, there probably won't be too much need for updating it.
-
The list of VPs in the main folder misses the Tango VPs BTW.
-
Fixed.
-
As far as about the DDS stuff goes, it doesn't actually mention that DDS is a higher quality format than PCX because it can store 24/32bit color instead of just 8bit. But that whole section could easily just refer to the other forum posts on texture differences too instead of going into it there.
-
Didn't see anything about trying to have a nice clean file set. Having extra unused files in the VPs not only increases the size of the VP but can cause issues down the road with any updates or other mods that use your mod or TC.
-
Didn't see anything about trying to have a nice clean file set. Having extra unused files in the VPs not only increases the size of the VP but can cause issues down the road with any updates or other mods that use your mod or TC.
How typical is this?
-
Probably more than you'd think. I also see releases that have files included in the filesystem itself that should not be released. So it's not just the files in the VPs but the entire release.
-
Not sure but TBP is full of that stuff and it annoys the heck out of me. Lots of textures in 2, 3 and even 4 formats (yes there is at least one map that has pcx, jpg, tga, and dds versions). Maps might be quite common as people tend to work with one format then convert to dds. Things like old lod map versions of updated mods might also get left behind.
So I guess what I'm saying is it doesn't hurt to point it out.
-
so basicaly create a fresh release directory, copy the needed files into it and convert that into the vp
-
Or keep an eye on it as you go along. But yeah, typically during testing extra files get created by the engine, or used by a modder perhaps, and aren't intended for inclusion, yet people often miss that when making a release. Heck I accidentally released something with my FS2NetD pass at one point :P
-
If it's a bigger project svn is good for keeping track. Only version and commit assets that are to be released or replaced by newer versions. Haven't tried it myself but I've heard it works for smaller stuff as well without a server.
-
Git makes more sense for small stuff, local setup is much easier to get going. And it really probably makes a lot more for just about anything compared to SVN.
-
:bump:
One thing just occured to me. It would be a good idea for mod releases to include a list with the following things:
1. A list of the VP checksums, as generated by debug builds
2. A list of the VP file numbers (that is, showing how many files are in the vp), again generated by a debug build
3. A list with MD5 checksums of each VP.
These things can help the support guys to quickly detect VP corruption.
-
Dun. Give me a shout if something went horribly wrong.