Mondkalb's "How to create an Addon from scratch"

[mondkalb 1087]

Well, here we go:

In the follwoing I will explain to you in ten easy steps how you plan an addon, create the model, create the textures, put the textures on the model, how to get a working door in it, how to implement a proper damage simulation, how you get this addon to Arma 2 and how you can release it:

Mondkalb's Addon Tutorial.

I hope this tutorial will spawn many new addonartists and even more high quality addons to this great Arma2 Community!

A .PDF version of this file is already in progress, and currently I am on page 45 and half of the pictures aren't included yet. So expect a 60 page Manual on how to start an Addon from scratch.

This is an unoffical tutorial.

Edited January 3, 2012 by Mondkalb

[.kju 3239]

Very nicely done!

You still need to adapt the formatting for the wiki in some parts. :)

Mainly for model.cfg and config.cpp.

You miss one very important part:

Always one has to use a sublevel for a model addon, like p:\MyTag\MyTag_Addon.

This is key to binarize an addon correctly.

Aspects you might want to add:

* Sign all your addons with an individual key, to allow server admins rule out addons

* Even doable to sign every release with a new key to rule out old addons

* Addon/Pbonaming.

* Copyright/permission.

Again very well done and thanks for putting this into the BIKI.

[PhilippRauch 0]

Lovely! Thanks for doing it, otherwise i would have felt the urge to do that... but honestly it wouldnt be nearly as neat and compleat as your tutorial is!

Kudos.

[lt.chris 0]

Good work on this manual, these are the type of things which gets new makers involved :)

[soul_assassin 1723]

You miss one very important part:

Always one has to use a sublevel for a model addon, like p:\MyTag\MyTag_Addon.

This is key to binarize an addon correctly.

Really? :S it always binarized fine for me straight from the addon folder :j:

In any case good job man!

[Herbal Influence 10]

Wow - a really teasing thing it is ...

By the by:

Found a whole german phrase in there ... sure it's something redundant.

[mondkalb 1087]

Thanks to all of you. :)

I'll try to get the typos and formatting-errores fixed during this weekend.

[beton 2]

Thank you very much Mondkalb...

even if i have to redo some of my models now...

[Binkowski 25]

Very good Mondkalb.

[Mr Sarkey 0]

Excellent, I'll be using this. Great work so far.

One suggestion, it might be good to have a list of programs that are required at the beginning.

[superrat 10]

i've been waiting for something like this

[ceeeb 147]

Oh, and please don't edit this page, even though this is an open document, I'd appreciate if you keep it "my" (Mondkalb's) tutorial, thank you. I've put a lot of time and effort into this.

Please note that all contributions to Bohemia Interactive Community may be edited, altered, or removed by other contributors. If you don't want your writing to be edited mercilessly, then don't submit it here.

A great contribution to the Wiki! I know writing such documentation takes a lot of time, but I personally don't like the inclusion of your user name in the article and the request not to edit it (especially relevant if you expect to leave the community). The power of a Wiki is that it can be updated by all as a collaborative effort. The internet is full of people with spare time, willing to fix spelling and grammar. Chances are there are other members of the community (or even BI staff) who know more about the topic and could improve your article. Why not allow others to build on your work rather than expecting them to start over?

Furthermore, as the game engine evolves documentation requires maintenance, and you will eventually (soon?) lose interest in the game. For example, Arma2's config structure may change, leaving this "reserved" document full of outdated information (misinformation relating to the current engine).

[Dwarden 1124]

stickied due to value contained :)

[.kju 3239]

Very much agreed with ceeeb.

Be aware that the wiki contains the full history, so any bad change can easily be reverted.

[mondkalb 1087]

A great contribution to the Wiki! I know writing such documentation takes a lot of time, but I personally don't like the inclusion of your user name in the article and the request not to edit it (especially relevant if you expect to leave the community). The power of a Wiki is that it can be updated by all as a collaborative effort. The internet is full of people with spare time, willing to fix spelling and grammar. Chances are there are other members of the community (or even BI staff) who know more about the topic and could improve your article. Why not allow others to build on your work rather than expecting them to start over?

Furthermore, as the game engine evolves documentation requires maintenance, and you will eventually (soon?) lose interest in the game. For example, Arma2's config structure may change, leaving this "reserved" document full of outdated information (misinformation relating to the current engine).

Good point!

Feel free to fix and improve it the way you like it!

I've reverted the "Private"-content thingie. :)

Edited October 24, 2009 by Mondkalb

[ceeeb 147]

Good stuff, thank you for that! :)

[Anykey 1]

very nice tutorial but you have written something in german

here > the Step Seven: The LODs

Resolution LOD

Each resolution-lod (0,000; 1,000, usw...)

usw = und so weiter =D

[Sjonkovic 0]

Thnx, great tutorial. Time to do some reading... :bounce3:

...but you have written something in german

here > und so weiter

it means "and so on" aka "etc." :)

[Anykey 1]

Thnx, great tutorial. Time to do some reading... :bounce3:

it means "and so on" aka "etc." :)

Yeah i know , i learn german for 6 years , but i still suck so much ... :p

[rübe 127]

Thank you very much for this tutorial. Though, some things are a bit unclear at times, it was very usefull for my first addon attempts.

Anyway, you might wanna complete your tutorial regarding doors and AI actually useing them! (I've burned some hours to figure it out... I guess I grow old, hrhr)

So: the following ingredients are lacking, to make AI use your doors:

1) We absolutely need a PATHS LOD. If you don't have any, AI might completely refuse to enter it/walk through it -> Bad.

2) An ordinary PATHS LOD consisting Inn- and Posn-selections is NOT enough (or the AI wallhacks through your door). What we need is something like this:

         .  Pos1
        /\
       /  \
      /    \
    .________.   -> both points: ActionEnd1
     |      |
     |      |
     |      | --> horizontal door position |----|
     |      |
    .|______|.  -> both points: ActionBegin1
      \    /
       \  /
        \/
         . In1

This is exactly what can be found in the "KBud" model from the ARMA_SampleModelsEnvironmentOther-Pack.

Now, I don't know exactly why, but this didn't really work for me (it's for a wall-fragment and not a complete building as in KBud, so exactly like in the tutorial). Maybe I've placed the In1 and Pos1 too close or whatever.

Anyway, I ended up with this variation which works very nice for my maze (thread 89926):

         .  In2
        /\
       /  \
      /    \
    .________. Pos1 (one single point) 
     |      | 
     |      |
     |      |    
    .________.   -> both points: ActionEnd1
     |      |
     |      |
     |      | --> door position |----|
     |      |
    .|______|.  -> both points: ActionBegin1
      \    /
       \  /
        \/
         . In1

^^ I don't know if the Pos1 is really needed. I started without it (just In1 and In2) and it didn't work. Don't know why, maybe because again placed too close, or maybe because min. one Posn is needed. (btw. exactly this makes it so hard to do anything: one never really knows how and/or why stuff exactly works. What are the exact rules? We can only guess :/)

All needed then is to add the following to your class-definition in you Config.cpp:

class CfgVehicles 
{
  class LAND_theObject : inheritFromThisObject
  {
     ...
     class UserActions
     {
        class OpenDoors1
        {
           // open door animation definition 
        };
     };
     ...
      ActionBegin1 = OpenDoors1;
      ActionEnd1 = OpenDoors1;
  };
 ...
};

If you've ever wondered for what ActionBegin1, resp. ActionEnd1 are for while studying the official examples... well, that's what they are for: to trigger AI-Action if they cross a certain line (the two points).

The thing is: if you don't do this (that is no ActionStuff and only ordinary In/Pos PATHS) then the AI will happily wallhack through your door - while the player can't, hehe. I guess the PATHS will force the AI to wallhack in this situation, and thatswhy we have ActionBegin1 and ActionEnd1..

I guess it's important that they have exactly this name-schema (like In/Pos-Selections).

Hope this helps a bit, because IMHO it's very important that AI can handle your stuff/addons well too!

[rocket 9]

Perhaps you could quote some slightly modified Sagan in it:

"If you wish to make an apple pie Addon from scratch, you must first invent the universe" - Carl Sagan

Great work on the tutorial, it's fantastic :)

[TRexian 0]

Hey,

Dunno if this may be the right place for this, but I've recently struggled trying to make custom editor icons. It seems like the different... sides?... have different pre-ordained color schemes. For instance, a module is the color blue. If you make a png of your icon, any white areas will be blue, and pure alpha will be white, and other colors seem darkened or muted.

For civilian objects, the color is like a greenish-brown. I can post some examples, if you want. :) But, I didn't know if this was something from OFP or A1 that I didn't find in my searches, or if it was new.

Regardless, this thread/wiki entry is fantastic!

[soul_assassin 1723]

Hey,

Dunno if this may be the right place for this, but I've recently struggled trying to make custom editor icons. It seems like the different... sides?... have different pre-ordained color schemes. For instance, a module is the color blue. If you make a png of your icon, any white areas will be blue, and pure alpha will be white, and other colors seem darkened or muted.

For civilian objects, the color is like a greenish-brown. I can post some examples, if you want. :) But, I didn't know if this was something from OFP or A1 that I didn't find in my searches, or if it was new.

Regardless, this thread/wiki entry is fantastic!

As far as I rember its real easy: square pic, all white and the alpha is the shape. The colour in multiplied automatically in game.

[Daffe 0]

Hey

Great Tutorial, Great initiative!

I've never done any modelling at all before, allways thought it's too hard, but hey it aint(for starters atleast)!

there's allways a BUT tho, on Step 4. i'm completly stuck:

Now load a texture to the UV-Editor. To do so, click on „Filter“ -> „Browse new texture...“. Select your „TUT_Wand1_CO.paa“. The screen should be filled with blue color. To change the zoom, use your mouse-wheel while holding the "Ctrl"-key.

Where the hell does TUT_Wand1_CO.paa come from? can't find the steps for doing it, tho i have done "TUT_Wall_CO.paa", so i used it, continued on and got stuck abit later on:

Click on the following symbol: (planarmapping.jpg).

The Planar Mapping is gray in the UV Editor.

Now i'm goin' nowhere, so what have i missed?

[mondkalb 1087]

1.)

You get the "TUT_Wand1_CO.paa" by loading the "TUT_Wand1_CO.tga" in O2.

Simply hit "A", right-click somewhere and choose the File. It is automatically converted into .paa and found in the same folder where your .tga is located.

2.) Before using the "Planar-Mapping" button you have to select some parts in the model.

I think all of this was described in the Tut. ;)

Anyways, I hope I could help you.