If conditions in description.ext

[gc8 981]

Hi

Is it possible to include file in description.ext by using some kind of If condition?

 

Like this:

#if ("ModToUse" call BIS_fnc_getParamValue) == "apex"

#include "apex.h"

#endif



#if ("ModToUse" call BIS_fnc_getParamValue) == "RHS"

#include "rhs.h"

#endif

 

maybe using __EVAL or something?

 

thx!

[pierremgi 4934]

No. Furthermore, when you can read (call) the BIS_fnc_getParamValue, the  description.ext is already run.

[mrcurry 517]

14 hours ago, gc8 said:

Hi

Is it possible to include file in description.ext by using some kind of If condition?

 

Like this:

#if ("ModToUse" call BIS_fnc_getParamValue) == "apex"

#include "apex.h"

#endif



#if ("ModToUse" call BIS_fnc_getParamValue) == "RHS"

#include "rhs.h"

#endif

 

maybe using __EVAL or something?

 

thx!

Well closest thing you got is #ifdef but that is more for manual switching tbh.

 

What is it that you're trying to do that requires such an approach. Instead of filtering on mod in the description.ext why not just load all configs and choose the appropriate ones during runtime?

[gc8 981]

12 hours ago, pierremgi said:

Furthermore, when you can read (call) the BIS_fnc_getParamValue, the  description.ext is already run.

 

true. That wasn't very good example by me.

 

However maybe description.ext is read twice, first when starting server and next when starting mission?

 

21 minutes ago, mrcurry said:

What is it that you're trying to do that requires such an approach. Instead of filtering on mod in the description.ext why not just load all configs and choose the appropriate ones during runtime?

 

Yes I could add all configs and then select one to be used. But having only used configs loaded would be ideal...

[Grumpy Old Man 3550]

2 minutes ago, gc8 said:

 

true. That wasn't very good example by me

 

 

Yes I could add all configs and then select one to be used. But having only used configs loaded would be ideal...

Weird approach, why not just use a simple isClass check inside the respective functions to see if a certain mod is loaded?

Compatibility for certain mods can be implemented by the script author, so you already know which classes (i.e. unit/item spawning) will be used, simply add them to an array, then use an isClass check for further procedures.

 

Cheers

[gc8 981]

1 minute ago, Grumpy Old Man said:

Weird approach, why not just use a simple isClass check inside the respective functions to see if a certain mod is loaded?

 

I am doing that but I would like to add only the config to mission/description.ext that is used. Otherwise I just bloat the description.ext

[mrcurry 517]

2 minutes ago, gc8 said:

 

I am doing that but I would like to add only the config to mission/description.ext that is used. Otherwise I just bloat the description.ext

 

That's not inherently bad though. The entire game is built around the concept of the config for data storage. The impact of a "bloated" mission description should be negligible. Unless you got some solid evidence that it is slowing things down I'd argue that your optimization efforts are better spent elsewhere. Remember that the most elegant solution is not necessarily the best. 

[gc8 981]

1 minute ago, mrcurry said:

That's not inherently bad though. The entire game is built around the concept of the config for data storage. The impact of a "bloated" mission description should be negligible. Unless you got some solid evidence that it is slowing things down I'd argue that your optimization efforts are better spent elsewhere.

 

Probably true. I'm just bit of perfectionist :)

 

However in my mind it would be good to have classes with same name defined in header files and only one actually used.

like so:

test.h



class Test

{
 stuff = 77;
};



test2.h



class Test

{
 stuff = 7;
};

 

 

The one class would overwrite the other

 

 

[pierremgi 4934]

I'm about to issue some modules with a different approach. For instance, in the civilian life, the mission maker can choose what addon will spawn units. So, i did some filters for civilian unit classes (no need to make a definite long boring array for that). So, if you tick CUP (Chernarus) in the module, and untick arma (by default), you'll spawn only CUP Chernarussians in the area(s).

That looks like:

if (gettext (configfile >> "CfgVehicles" >> _unit >> 'faction') == 'CUP_C_CHERNARUS') then { _CUP_CHERNARUS_CIVS pushBack _unit };

 

You can also easily detect if an addon is active with modParams.

See also activatedAddons

I never used activateAddons... Not sure it's reliable in A3.

 

[gc8 981]

if it's not possible what I'm after then I'm probably going to use code similar to this:

 

getUnitDefs =
{
 missionConfigFile >> format["UnitDefs%1", modUsed]
};

 

Will return classes like this:

 

class UnitDefsApex

{

};

 

And that will give me appropriate unit definitions depending on mod used

[pierremgi 4934]

If I'm right, your missionConfigFile will return some declared classes (or included) in description.ext.
If you load some mods, even using them in mission.sqm, without any reference in description.ext, i'm not sure you'll obtain something like this.

[gc8 981]

7 minutes ago, pierremgi said:

If I'm right, your missionConfigFile will return some declared classes (or included) in description.ext.

 

yep

[gc8 981]

So any one has ideas about this?

 

I have been playing with the __EVAL and __EXEC commands but I think they cannot be used to construct a class name (Or If statement).

 

Please correct me if I'm wrong but __EVAL can be only used to set config property and __EXEC creates variables in parsingNamespace

 

 

[Dedmen 2724]

20 hours ago, gc8 said:

I have been playing with the __EVAL and __EXEC commands but I think they cannot be used to construct a class name (Or If statement).

They can't

20 hours ago, gc8 said:

Please correct me if I'm wrong but __EVAL can be only used to set config property

Yes

20 hours ago, gc8 said:

and __EXEC creates variables in parsingNamespace

No, but you can do that inside __EXEC.