Differences between config.cpp and description.ext

[pierremgi 4739]

Hi everyone,

I worked hard trying to understand BIKI for making addons.

Finally, I scripted mine like a mission with description.ext. That allows to have an immediate view of what's work and what's wrong.

Since Eden, you just have to restart from editor because description.ext is reloaded. It was not the case with 3D editor.

 

Then, came the time to port this work up to an addon pbo. And here comes the struggle against differences between the 2 kind of files.

I suppose you're aware you need a cfgPatches for your config.cpp (can be already in description.ext). I retain there is a link between the class in it and the name of the addon.

 

More difficult: Where your description.ext worked fine with relative paths to your sqf files, sounds, images...,-- I mean that all files directly saved in mission.sqm folder can be directly mentioned without path --, now, your config.cpp needs the paths from the addon folder,.. more or less!

To be exact, the path with the class name in cfgPatches. This is not the @my_addon\addons\ where file pbo is, but the \my_addon_class\mySubfolderIfAny\... like in cfgPatches in config.cpp

 

For example, all your personal settings in defines.hpp or else are declared like this:

#include defines.hpp  // in description.ext as far as this file is in the same folder as mission.sqm!

but

#include \my_addon_class\defines.hpp   // if this file is in the same folder as config.cpp. Don't forget the first \  unless you'll have an error in Addon builder.

(Btw, this first \ seems to be less important for other paths in configFunctions for example. I don't know why).

If a script (sqf file) refers to images located in sub-folder, you'll need to change "mySubFolder\myImage.sqf" by "my_addon_class\mySubFolder\myImage.sqf"

 

This could be enough for an addon without dialog display, buttons, boxes and so on.

Unfortunately, pain continues with the classes declaration, garbling the stuff with one more step, regardless of the paths skill:

 

When called by description.ext, the included classes in defines.hpp (or equivalent), say like the simple "rscButton" or "RscText", will  work immediately and you can see the changes:  Change backGround color or shadow, or text align, restart preview (Eden) or restart Arma (2D editor), then your changes are here.

Now, with config.cpp...
All changes you do in core classes like said "RscButton" or RscText" don't work. The settings for your display is now the default engine Arma settings!!!

You need to add inherited classes like "my_RscButton" with your settings to make it work! Where you description.ext allowed to change RscButton, you need to have the RscButton + the inheriting my_RscButton: RscButton in your config.cpp

 

Why such differences? I'd like to know. I hope this help. Please comment and correct all you want in these considerations. I'd like to make progress and the less I can say is BIKI missed concrete examples for all of that. You can spend hours, days, weeks trying all possibilities. Regards

[Defunkt 431]

This answer should not be considered authoritative (I would need to test specifics) but I would surmise that the reason why, is that by the time your mission is loaded your changes to base classes (i.e. RscButton) have little effect on anything other than new instantiations within your mission, other global objects have already derived all of their properties before you alter the classes at mission load. However when you alter these classes via config.cpp (in an addon) you're changing these classes much earlier, as they're being used to define/derive other global objects. The *right* way is always to derive your own subclasses, you just don't happen to see the bad effects of not doing so in the limited scope of a mission.

[pierremgi 4739]

That makes sense. Thank you.

[goko- 14]

I am stuck as well. I had a perfect code that worked in missions; which is bunch of eventhandlers hooked up to playsound3d to play sound like throwing grenade, or saying silly stuff when you deploy a weapon, etc...

now I am so confused. so much confused because playsound3d required a "mission root" defined and had to be played from mission directory, naming their *.ogg extensions. Now this makes everything so confusing to me. nothing works. and I can't see any way to make them work.