OFP Forum, OFP Home, OFP File Formats, OFP Tools, OFP Missions, OFP 3D Modeling, OFP Terrain

Operation Flashpoint (OFP) aka ArmA: Cold War Assault (CWA)

OFP HOWTO Release Addons / Mods

Note: this insert is from WrpTool's manual and is focused on terrains, but you can learn and adapt this to your Addon instead (if it happens not to be terrain what you're releasing).

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 at least one nice background menu cutscene. So now you are looking for the release of this addon… how to do it?

Many people these days use the Agent Smith Industrial, Harbor kit or MapFact Baracken addon buildings in their terrains. These make quite nice additions to the default bis objects and saves tons of time for terrain maker compared to him starting to do his own models and textures for such buildings.

But then comes the question, should these addons be added into the terrain pbo or just be required for the terrain to work. Well its WrpTool Development Team's opinion that none of the addons should NOT BE ADDED into the terrain pbo/release itself since these addons are already released and available from internet. If they are added they just increase the download size and its good possibility that the user who downloads the terrain already has these addons installed normally, so it is not a good solution to “hardcode” them into your terrain pbo. Just let the users know that the terrain requires these addons and they need to be installed.

If your terrain uses objects and textures from other terrains like the very common usage of SEB NAM Pack 2 stuff, then it is essential that you DO NOT ADD the sebnam_obj.pbo into your terrain release. We cannot address this enough as it is so obvious, do not do it, it makes you and your mod/team look like fools if a mistake like this is done for your release. SEB NAM Pack 2 has been released and it's available on most sites so there is no reason why anybody could not get their hands on it. By leaving it out you not only decrease the download size, you also avoid the conflict which comes from your sebnam_obj and the official one, unless yours is just going to overwrite it.

Same applies for the quiet release of Ebud's iloilo_obj.pbo which has some type of jungle objects and textures; this original pbo (we think) has a big TARGA (tga) file inside it, its 1mb in size which increases the download size for absolutely no reason. If you want your terrain to be jungle/NAM theme, please stick with the official objects and textures of SEB NAM Pack 2, you can do wonders with them and this way you do not need to use iloilo with the tga inside it.

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.

It is very very important that you include decent readme.txt into your addon release. This text file should be written with notepad or similar text editor that any kind of editor can open and read.

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 might include AGS industrial, Baracken or even SEB NAM Pack 2 for textures and objects.
• Installation instructions. This should include clear and specific install instructions like “place anims dir and pbo dir to ofp\Addons dir” or similar stuff. Also it would be nice to package the release so that there already are the directories and when user unpacks it to his/her ofp dir, it's ready to use.
• 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.

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.

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.

2024-08-01T07:00:00Z This was updated for latest software updates, ie 7-zip usage.

The final release package format is very important. The most common would be a PkZip archive format, it's been used for ages and everyone knows it these days. You can leech latest WinZip from winzip web page.

There is also the bis suggested AAE system, Addons At Ease. Well we are so blunt and call it stupid. Yep, we bash bis, eek shame on us! No seriously, the AAE is stupid because it uses the microsoft MSI install system, you need to leech some lame installer to even make the AAE .msi packets to be opened. Stay away from it, even if its bis endorsed stuff. This is of course only our opinion, but you can judge from yourself by looking at the OFP scene and count how many releases there are with and without AAE system.

Then there is the worst choice you can do and that is installshield 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 OFP 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 installshield not capable of uninstalling it anymore.

Then there is the RAR utility. There are some older versions but everyone should first go to rar homepage and download latest winrar to get his rar up to date. Now somebody goes, eeww, RAR what is that I never heard of it before? Well here the newsflash for you buddy, RAR is capable of opening ZIP's and lot of other archives and more importantly it compresses the files much better than WinZip. You'll save tons of download size by choosing RAR for the packaging method for your terrain release. Do a comparison if you don't believe us. RAR is great.

In 2024 and actually several years already, pretty much post 2010s you need to use 7-zip, get it from 7-zip.org homepage, it is by far the best archive compression packing software today, it does the smallest archives and can open zips, rars and various other packed file formats. Do not use ZIP or RAR anymore, those are outdated.

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.

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 OFP, check the menu cutscenes, check the textures (mission editor texture button), check the map view-lag etc 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 OFP 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.

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.