How do you create a module?

I am interested in creating a module, how is it done?

You need to create a AddOn first.

In your ArmA 2 root folder create a folder called "@MyAddOn".

In the "@MyAddOn" folder create a folder called "AddOns".

In the "AddOns" folder create a folder called "Module".

In the "Module" folder create a .txt file called "Module.sqf" and a .txt file called "Config.cpp" with Notepad for example.

Note: The "Module.sqf" will be executed by creating the "Module" in the mission editor.

So now you should have: @MyAddon\AddOns\Module\Config.cpp and Module.sqf

Config.cpp

class CfgVehicles
{
class Logic;

class MyLogic : Logic
{
	displayName = "My Logic";
	icon = "\ca\ui\data\icon_functions_ca.paa";
	picture = "\ca\ui\data\icon_functions_ca.paa";
	vehicleClass = "Modules";

	class EventHandlers
	{
		init = "_this execVM ""\@MyAddOn\AddOns\Module\Module.sqf"" ";
	};
};
};

Pbo the "Module" folder in "@MyAddOn\AddOns\" and you are ready to go.

Of course you need to launch the "@MyAddOn" with ArmA 2.

Thanks for the help, though how do I use synced units in the script?

---------- Post added at 12:21 AM ---------- Previous post was at 12:16 AM ----------

Also, will people who play a map online be able to use this module? or do they need ot download it manually?

synchronizedObjects returns an array with all objects syncronised to the module.

Players have to download and install your module to play a mission using it.

Alrite, thanks for the help mate.

So many scripting texts and instructions and there is no single template or tutorial about modules... And I am very sad to say that I tried everything written here and this module "My Logic" won't even show in the editor...

So can anyone help a little bit more?

I tried to search for some simple addons, to unpbo them and see what's inside, but I keep running onto heavily packed scripts :(

Just one tiny tiny template to get started....

The example misses the cfgPatches part:

class CfgPatches {
class MyLogic {
	units[] = {};
	weapons[] = {};
	requiredVersion = 0.1;
	requiredAddons[] = {"ca_modules"};
};
};
class CfgVehicles {
class Logic;
class MyLogic : Logic {
	displayName = "My Logic";
	icon = "\ca\ui\data\icon_functions_ca.paa";
	picture = "\ca\ui\data\icon_functions_ca.paa";
	vehicleClass = "Modules";

	class EventHandlers {
		init = "nul = _this execVM '\PBONAME\Module.sqf' ";
	};
};
};

@SNKMAN

Could you please explain why on the initEventHandler you used absolute pathname? This limits foldernaming down to exactly whats it says there. Personally, i dislike such "hardcoding" since it really isn,t necessary. But you might have your reason so i would like to hear and learn.

@ArmAIIholic.

I suggest you get the BIS editing tools and install them, although most of them you wont need. But there are 2 things that are probably helpful:

P: drive

BIS editing tools create a virtual drive, usually with drive letter P:, using DOS command "subst". For those who don't know: with subst you can create a "vrtual drive" with any folder you want. BIS tools will create a folder on a drive you define, named "armawork" and use subst command to create drive P:

To create a new addon, you just create a new folder into the root of P:. This foldername will be the later addonname. So name the folder MyAddon and you will get a MyAddon.pbo.

Any paths, be it in config or scripts, have to point to this folder. Inside you may create any folder structure you want, just keep config in the main folder.

BinPBO

Although there are other pbo creating tools, i personally prefer BinPBO since it i'm used to it. It let's you select with a simple checkbox if the addon should be binarized and/or signed.

Thanx [GLT]Myke, I knew I can count on you. I already installed all the tools and have that virtual drive (I was "oh Gosh, how this got here"), but I didn't know how to use all these things. Thank you very much.

----EDIT---------------------------------------------

Someone should made this sticky, because I spent 5 hours searching this forum and other sites and I didn't find anything as simple and concise as this explanation / example [my opinion].

What is the size of icon I want to change?

How do I put more Modules in the cfgPatches?

@kheiro -- nice idea, I will try that

here is how (source: http://forums.bistudio.com/showthread.php?t=101918)

Make a image, save image as a .TGA and then drag it into TexView 2 and save it as a PAA. Then just point to it from the script above. I guess...

---EDIT---

Now I am wondering how can I point to the files back inside mission folder (it will later be pbo in sp).

---EDIT---

I guess I will have to put everything inside @MyAddOn/AddOns, both pbo of the module and separate sqf files that I don't want to pack (and protect) so that people can edit them.

So kheiro I am just guessing, but you can put your picture there: "\@MyAddOn\AddOns\MyIcon.paa"

What is the size of icon I want to change?

How do I put more Modules in the cfgPatches?

Icon size you can change with this:

mapSize = 9;

AFAIK it is meant as "meters" as scale. Useful if you want the icon represent the real size of an object, which is obsolete with a module.

The cfgPatches, you may more look at it as some kind of "familyName".

class CfgPatches {
class MyAwesomeModules {
	units[] = {"MyModuleOne", "MyModuleTwo", "MyModuleThree"};
	weapons[] = {};
	requiredVersion = 0.1;
	requiredAddons[] = {"ca_modules"};
};
};

If ever you create a follow-up addon which requires stuff in this previous addon, put it's "Family Name" into the requireAddons part:

class CfgPatches {
class MoreAwesomeModules {
	units[] = {"MyModuleFour", "MyModuleFive", "MyModuleSix"};
	weapons[] = {};
	requiredVersion = 0.1;
	requiredAddons[] = {"ca_modules", "MyAwesomeModules"};
};
};

This will make the game load this second addon after the required addons are loaded.

The path for the map icon is this one:

	icon = "\GLT_MOAB\glt_moab_ico.paa";

So guessing you used the P: drive and there you have a folder named GLT_MOAB (which will later be GLT_MOAB.pbo), the .paa file is right in there.

@ArmAIIholic

afaik you can't point back from addon to mission folder. If it's only to get some variables set by user, then there are ways to do it without scripts.

First way, use setVariable and getVariable for userdefined parameters.

Those can be added to the initline of the module. While developing, use a simple GameLogic as placeholder for the latter module. Also try to pre-set all user-definable parameters to a default value that might fit for most cases. This way some parameters can be left out by users, taking default parameters.

Or you provide a single script outside of the addon which does the parameter settings.

[GLT]Myke thanx for the clarification.

About outside scripts... as you suggested in my thread and I will listen you, I will make a module. The problem is (was) that I intend to leave some sqf files, with soldiers classnames that need to be spawn, open so people can make their own squads and simply add them to the game. Now, I understand setVariable and getVariable, but it would be a lot of work.

(And you will see I have completely different system to deal with settings, I just need time to do it).

So I intend to to this:

I will create my @MyAddOn folder and there I will create AddOns folder and units folder. Now, my module will go from original addons folder to this "custom" and I will refer to all other - not packed files - via absolute path at @MyAddOn.

In that way I will sign my module, distribute it with default files and if someone wants to change squads it will be available and more important distributable because key is only for the module.

P.S. It's sad I won't be able to do it before weekend. Time, time, time...

--EDIT--

Or, hm even better, ha :) Same as your example up there, I can put them into separate folder on P: (like GLT_MOAB) and just not sign them at all........ he he he, niiiiiceeeee :D yeah

--EDIT 2--

This should reeeeeeally be a sticky post.

[GLT]Myke Thank you for this detailed explanation you are really creative

ArmAIIholic thanks And I am following the topic

I do not recommend to work with unsigned pbo's since they're vulnerable to misuse. Also most servers wont allow unsigned addons at all, due to the fact that they open ways for misuse.

My recommendation: create your module as single addon (pbo) and provide an external script which is used by missionmakers to create/define own stuff/parameters. This script is later included into the mission pbo so misuse wont be possible since always the version from the server is used.

You see, signed addon with mission scriptfile would be best and safest way to go.

I never got the whole idea of making modules. I can certainly see the benefits. However the mission makers have to convince the people that want to play their mission to install the addon (or at least on the server) that has the module. Instead if you just create all stuff necessary you can just start it from the init of a normal game logic, instead of an module with an event handler, and nobody would have to download an addon.

Can someone tell me why they think the benefits outweight the drawbacks?

One thing is, I can think of, that if several campaigns use the same module you don't have to download it over and over again with every mission.

Connected with that --- all core files are concentrated in one or several pbo(s), so you don't make "junk" files in every mission you create. Just find the addon in the modules (F7) and there you go. For example if I am about to make several campaigns, just use different maps, I can put my addon into separate package.

Next one I can think of is that server does not necessarily has to ask for a key. You can just protect your addon from unauthorized changes (as I understood).

And finally -- you want to make a mission with my addon. Do you really want to dig among bunch of files to extract core files? Well, yes, I can put them into the folder that you will copy to your mission 1, mission 2, etc. but that's the same thing with pbo(s).

So, I think there are several good reasons.

I never got the whole idea of making modules. I can certainly see the benefits. However the mission makers have to convince the people that want to play their mission to install the addon (or at least on the server) that has the module. Instead if you just create all stuff necessary you can just start it from the init of a normal game logic, instead of an module with an event handler, and nobody would have to download an addon.

Can someone tell me why they think the benefits outweight the drawbacks?

There are several reasons for a module, although your points are surely valid aswell:

- Easier to handle for beginners. It is easier (and probably better documented) to install an addon than copy/pasting code/folders to the right place.

- Mission files remain smaller. Without the additional scripts, mission files are smaller and therefor faster downloaded from the server.

- Updates. Whenever a module creator improves his modules, already existing missions will profit from them without the need of updating them, unless new features requests to do so.

And finally, a module-only addon isn't that big, probably stays below 1 megabyte, so it's quickly downloaded.

I completely agree [GLT]Myke. And Muzzleflash they can be big too, take for example Group Link 4 Special FX Edition... 45 MB. You can implement and distribute all of it or just for example Enemy A.I. Enhancement.

Hm I succeeded in this:

scripts are normally calling each other '\PBONAME\Module.sqf', \PBONAME\etc.sqf' then some of them calls "\@MyAddOn\AddOns\Module\SomeFolder\Module.sqf", but then I cannot go back, not even to the \@MyAddOn\AddOns\Module\Module.sqf....

strange.... I will have to find some other way....

why are the names {"MyModuleFour", "MyModuleFive", "MyModuleSix"};

different from "MyAwesomeModules"... I didn't get it.

Question:

Suppose I have two modules. Module 1 is running all the time, but occasionally it has to call Module 2 to do something, call some other sqf files inside, but Module 1 has to keep running and keep calling his sqf files.

How can I do that?

---------- Post added at 08:34 PM ---------- Previous post was at 08:20 PM ----------

Hm.... familiy name.... am I close? :)

---------- Post added at 08:45 PM ---------- Previous post was at 08:34 PM ----------

Here is the problem Myke - it requires class CfgPatches { class to be MyLogic

---------- Post added at 08:56 PM ---------- Previous post was at 08:45 PM ----------

Oh my God it's simple...

2 pbo_s, two modules on the map, 1 script running on init, they can call different '\PBONAME\SomeScript.sqf'

...so simple... sweeeet :D :D :cool:

I have a Q:

Is there an easy way to test the module? Maybe I did something wrong, but....

If I make changes to the module files (i.e. some .sqf) I have to exit game, pbo new files, then start the game and test it... Is that necessary?

While I was doing everything from mission's folder it was easy. Alt-Tab ArmA, change something, load a game and test it.

Thanx in advance

Since a Module consist of script, for testing mid-developement, i wouldn't create pbo's but testing the scripts as...well, mission scripts.

Go in the editor, place a player unit and save your mission. You'll find a new created folder here:

C:\Users\Myke\Documents\ArmA 2 Other Profiles\[GLT]Myke\missions

Inside this, copy your addons folder so path remain the same.

Changes on scripts are now loaded on each preview, so you can alt+tab between game and scripteditor.

Testing as addon would be the very last stage before release, to see if path do work and a last check for previously overseen bugs.

I have a Q:

Is there an easy way to test the module? Maybe I did something wrong, but....

If I make changes to the module files (i.e. some .sqf) I have to exit game, pbo new files, then start the game and test it... Is that necessary?

While I was doing everything from mission's folder it was easy. Alt-Tab ArmA, change something, load a game and test it.

Thanx in advance

Use a PBO prefix file.

http://community.bistudio.com/wiki/CMA:DevelopmentSetup

http://forums.bistudio.com/showthread.php?t=85642&highlight=%24PBOPREFIX%24

What it does is use the source files, so that you can test update fix etc without needing to restart Arma after every change. Though files like your config.cpp can't be updated without restarting i think. You still need the pbo's, and you need to make sure your paths are setup correctly. Use the links above.

Ensure you don't have -noFilePatching in your startup line as this disables the above to force arma to use the pbo's

http://community.bistudio.com/wiki/Arma2:_Startup_Parameters

Thanx both of you :D

Myke;1679588']

C:\Users\Myke\Documents\ArmA 2 Other Profiles\[GLT]Myke\missions

Inside this' date=' copy your addons folder so path remain the same.

Changes on scripts are now loaded on each preview, so you can alt+tab between game and scripteditor.

[/quote']

:mad::mad: It took me one hour to find that this path that works for modules doesn't work for testing with folders...

instead

execVM '[b]\[/b]PBONAME\Module.sqf'

one should call the function via this path

execVM 'PBONAME\Module.sqf'

grrrrrr :mad:

Now, finally after spending some time making modules I have a clear angle to view all the benefits of the module.

Example 1:

Take this example (that was about compatibility of WICT with other modules):

I used it with my "full pack" that contains: vftcas, ACE, GL4, SLX(lite), mma, zeus, warfx, jtd stuff, and sound mods.

So let us assume that all these modules are just folders inside the mission zapat created and that he wants to upload it to a dedicated server.

Now, let us assume that I want to change something, and then several days later there is a new version of ace, then in a few days zeus etc.

What zapat would have to do is download these module each time and replace folders in his mission, then pbo it and upload it again on dedicated server.

With modules he can rely on the modular organization and then just upload the module.

Example 2:

Let's assume that zapat made 20+ missions with different modules and that I update WICT. What he will have to do is to open all missions, change the folder there (and update files), then pbo the mission and upload it again.

With module he can just upload it and all missions that use that module will be updated.