PMC Editing Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== How To Release ======

When you're reading this we assume you already know about [[arma:howto_be_mod_maker|How to be mod maker]] and [[arma:howto_mod|How to Mod]] articles which explains the backgrounds before you reach the release point which is topic of this article you're reading now.

Okay so now you're at that point where all those sleepless hours are behind, the addon has been built to that point that it looks nice, your config.cpp has been all setup along with everything else. So now you are looking for the release of this addon... how to do it?


====== Included Addons ======

Do not include "required addons" with your release. If your soldier addon's use XYZ mod groups weapon pack, DO NOT ADD IT TO YOUR RELEASE. Understand?

People can download it them selves and the ones who bitch about it being extra work for them to find it etc... can frankly shut the hell up! :)

Many addon's these days use the extended event handlers (XEH) which is pretty much the only addon you should include with your release.

If they are added they just increase the download size and its good possibility that the user who downloads your addon already has these addons installed normally, so it is not a good solution to "hardcode" them into your release. Just let the users know that your addon requires these other addons to work and they need to be installed.


====== Clean out temporary files ======

When you are developing an addon there can be all kinds of temporary files laying around in your work dir. It is very important that you make sure that none of these unusable temporary or shall we call them leftover files gets into the release pbo package because they only increase the download size, but look bad for anyone willing to take a look inside your pbo.

Good rule of thumb is that the addon pbo should not contain anything not used in the addon in one way or the other. Of course you might have objects and textures in different pbo's but you'll get our point here, when you release; only put out the files used in the item you are releasing. Make sure no leftover TGA or Thumbs.db files for example are laying around in some sub dirs etc. Be careful with this one.


====== RAR, ZIP or EXE ======

The final release package format is very important.

PkZIP is out dated, do not use it anymore.

The worst choice you can do and that is executable installer or some other installer which asks the user to place where to install and adds the "software" into the windows programs menu etc. Stay away from this kind of crap as it's definitely not suitable for ArmA addon installing by any means. Not only it strays possible users away from your release but it's a pain to use for those who choose to install it as most likely they remove/etc the addon files that makes the installer not capable of uninstalling it anymore. 

RAR utility [[http://www.rarlabs.com/|rar homepage]] is the most common and community accepted archive tool, use it for your addon / mod releases.

Then there is the 7zip utility [[http://www.7-zip.org/|7zip homepage]]. This packs better than rar but is not widely used and accepted, stick with rar for now.


====== Documentation ======

Readme is very important file in your release. Nothing is as lame as release with just a pbo in a packet, that is so lame its not even funny. You must write readme in English language, place your web site and email address there clearly or at least some forum link for your username where you can be reached. Everyone should have web site or at least email so there is very little excuses for not to write them into the readme.

Readme should of course start by just few lines explaining what this packet is, like "ArmA M4 Green Assault Rifle" and then longer description about the addon if you so choose. Installation instructions are always nice, but nowadays you already can find several web sites that have install instructions so you can link just for those.

Also version number and release date is very nice to include, many times people get confused about what is the version number of the particular addon release.


===== Readme Text =====

It is very very important that you include decent readme text into your addon release. This text file should be written with decent text editor that any kind of editor can open and read, try to avoid making HTML or PDF readme files, those are always cumbersome to read for end user.

Basic readme should clearly state these following things; 

  * Common release name
  * Addons needed, as stated above the addons you want to use but should not add to the release package.
  * Installation instructions. This should include clear and specific install instructions.
  * Contact information listed at the bottom of the readme, authors name and the web site where to contact him if not direct email. Maybe you don't get much feedback or questions, but it would be decent to have contact information and if you have web site, its link there. Always nicer to know that the author of an addon is reachable by some means, if not else than just to check new versions or fixes.

File name for the readme is also important, do not add just "readme.txt" as world has seen millions of them already. But use instead for example "<tag>_<release>_<version>.txt" type of naming, for example: PMC_IraqTerrain_v0.1.txt would be perfect file name for a readme.

With that stuff you should have covered all the basic information what possible addon looking users are interested to know. Add the readme inside the rar packet but also if possible make it available on forum post or a web page.

You know... a good release is half of the addon quality and word spreads quickly over the internet if certain release has been goofed up. Make the effort to give your addon a good quality all around, not just the addon itself. It's worth it on the long run.


===== Documentation file types =====

When making readmes for your release archive, try to avoid HTML pages or PDF files as they really are "too heavy" and cumbersome for small addon. Naturally if your addon is complex beyond this world and requires user to read 7 well illustrated tutorials to operate it, then of course PDF for example is preferred media.

If your readme is one or so pages long, only use simple normal format text file for it.


====== Release File Name ======

First of all, **//do not never ever use spaces in file names//**.

Please give the release a file name which itself describes the released product. Do not release "Iraq.rar" as that is so lame you lose all credibility when someone starting to download sees the file name. If you have a tag, start with that, then add the release name, then version number. For example.

<tag>_<release>_<version>.rar

PMC_IraqTerrain_v0.1.rar

When you name it like this, anyone seeing that file months from now in some directory, immediately knows that ah-ha, its PMC's Iraqi Terrain the first version.


====== Screenshots ======

Sometimes you see people putting a screenshot or two into a release packet, sometimes you see 4 megabytes worth of screenshots in the packet. Now ask yourself, if a user already downloaded 50mb worth of your addon to play with it... //why// do he need to see screenshots 10 seconds before he fires the addon up ingame? **DO NOT include screenshots** in the release packet, its just stupid, screenshots belong to news sites or forum release announcement posts.


====== Beta Testing ======

Its good if you test your addon through before release, this avoids a lot of the frustration that 23:30 you release an addon to news sites, only after first forum replies you discover a critical bug and have you release hot fix before midnight, its not a good start for your addon / mod.

Beta testing is very important if you don't want to loose your face and reputation. No matter how cool you think you are, the bigger the mod, the higher the chances are that something slips through your own testing phase and after the release users come to complain why this and that is broken. To avoid this, beta test with few other people than yourself to prevent this and to catch as many bugs as possible.

Don't be discouraged to go back time after time again even though you have set deadlines, if bugs show up, you must fix those before public release.

Then there is of course the public beta testing, seems like people are nowadays more and more "falling back" into this method, you just do your mod, when you feel its good enough, you release it as "public beta" or "alpha" etc. Then if you get complaints, you can always say that hey, I said its alpha/public beta so stop bitching. Of course this is not the preferred way. At least to release public betas to wide audiences (news sites and such), small scale forum development type releases are okay though.

It is very common to loose the track of what's wrong when working on an addon release for a long time. You get inpatient when doing a testing after testing and just concentrate on the editing, this is very common situation. Therefore you need an outsider beta tester who isn't involved in the editing. You should have at least one person who is willing to open your release archive, look at the readme, install the addon, play it with in ArmA to really give it a run for its money.

To have more people in the beta test team helps to discover bugs, errors or something you left out much quicker. Also to have the beta testers run rather clean ArmA installs (not the developer install you've got) helps as you might have some files which are used in the addon but you don't even know it and the files aren't included in the release package. Mod directories are the key here.

Also give the beta testers some time to test; you cannot expect them to discover everything in the release in 5 minutes of testing time. Have them testing it one evening or so, at least several hours where they can calmly go through the basics of the addon.

It is very embarrassing to submit a news and forum posts and then few hours/days later discover that users start to report something very obvious bugs which should have been discovered. Trust beta testing, it helps.


====== Permissions ======

//This is only vaguely related to how to release, but its most suited here.//

When you release something, you need to have permissions to use other peoples work if you need to. Even if you only have one or few permissions granted, its very much recommended that you take a screenshot of this granted permission if its private message in forums, email or IRC chat etc (and maybe even if its public post) and to save it to under a name like this:

**Permissions_AddonName_Author.jpg**

For example it could be:

**Permissions_XYZ_M4_AddonDude.jpg**

Which would immediately tell you that this is a screenshot of granted permission for XYZ groups M4 rifle by author AddonDude.

Its very unlikely that you get any trouble with permissions from anyone else than the author, sometimes some lamers in forum stir trouble by accusing you of releasing addons without permissions, but usually its enough if you say that you have permission or perhaps the author himself corrects these false claims. There is no chance of the author himself starting to cause trouble of permissions... since he already granted them. But in any case, screenshot "proof" of the granting of permissions is rock solid way to keep your back covered in any situation that might come up later.


====== Notes ======

This article has been written with experience of editing since 2000 and after witnessing / inspecting hundreds of lame addons and releases.
PMC Editing Wiki

User Tools

Site Tools

Page Tools
