Jump to content
Sign in to follow this  
tortuosit

Conditional #include of file / check if file exists?

Recommended Posts

Hi guys,

in an Addon, I want to allow parsing of a config file inside the addons folder - if that does not exist, it should use the arma3\userconfig one. This way the user would be able to simply duplicate the addon with different settings...

Now I tried the following in config.cpp: First read the userconfig one, then read the addon folder one and overwrite variables.

class TORT_DYNAMICWEATHER_Settings
{
#include "\userconfig\tort_DynamicWeather\tort_DynamicWeather_config.hpp"
#include "tort_DynamicWeather_config.hpp"
};

But if the file does not exist, mission cannot start. How should this be done? ArmA, to my knowledge, does not have a fileExists check...

Thx

---------- Post added at 12:38 ---------- Previous post was at 12:31 ----------

BTW. I must say I have no problem with not using "ArmA 3\userconfig\" - but I know that it is the way to go. But I ask you: Why? Because of distribution software like PWS?

Different configs can best be handled by simply duplicating the mod, where every mod folder has it's own config file. I'm about to do that, except if someone convinces me not to do it :D

Share this post


Link to post
Share on other sites

You could load the file via script afterwards instead of using include. That gives you more flexibility.

BTW. I must say I have no problem with not using "ArmA 3\userconfig\" - but I know that it is the way to go. But I ask you: Why? Because of distribution software like PWS?

Different configs can best be handled by simply duplicating the mod, where every mod folder has it's own config file. I'm about to do that, except if someone convinces me not to do it :D

Because you have no way of knowing how the user has named his modfolder. So please stick with the "userconfig" folder.

Share this post


Link to post
Share on other sites
Because you have no way of knowing how the user has named his modfolder. So please stick with the "userconfig" folder.

That would be a problem only if config.cpp cannot handle relative paths (relative to the addon folder). After a first test: Eeek! Seems like it can only access things relative to the ArmA 3 directory? Then you are right, I cannot do it as I want...

Ah, I think the (unpacked) pbo is kind of in its own world, directory-wise, I guess?

Share this post


Link to post
Share on other sites

Correct.

As far as the internal path is concerned, ArmA really doesn't care where the PBO is.

The user could basically rename his addonfolder to whatever he pleases and you (your addon) would never know about it.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×