Modifying function location issues

[anfo 118]

Reading a bit about functions and scripts I am learning why functions are more efficient to use over scripts. An issue I note however, for housekeeping purposes I find it more improbable to move a function's scripts to a custom folder (e.g \scripts), where execVM scripts are happy to do this (with various path editing).

 

With more functions appearing in our clan's custom script framework, is it not possible to customise the location of where a function normally resides in the mission folder? I apologise if this is vague question, but we have two scripts from two different authors in the form of functions and they both don't prefer occupying anywhere but the root, especially if I don't want path errors.

 

In the end if I have no choice but to allow them to reside in the root folder then I will accept begrudgingly.

 

Thanks for any insight.

[Larrow 2799]

If you are using the functions library to compile your functions then it provides a file attribute so you can specify where the file can be found. Read more about the functions library.

[serena 150]

I use such rather flexible and convenient approach:

// Abc.sqf
Abc_FuncX = {...};
Abc_FuncY = {...};
Abc_FuncZ = {...};

// Def.sqf
Def_FuncX = {...};
Def_FuncY = {...};
Def_FuncZ = {...};

// init.sqf
call compile preprocessFileLineNumbers "Abc.sqf";
call compile preprocessFileLineNumbers "Def.sqf";

// Somewhere in mission:
... call Abc_FuncX; ... call Def_FuncZ;

 

[Tajin 348]

@serena the functions library has all that flexibility aswell, and more.

https://community.bistudio.com/wiki/Functions_Library_(Arma_3)

 

 

I usually do it like this in the description.ext:

class CfGFunctions
{
	#include "functions\myscript.hpp"
	... and so on
};

 

In the functions folder I have hpp files for each script that define functions for that script, like so:

class TAG
{
	class myscript_tools
	{
		class init {description = ""; postInit = 1};
	};

	class myscript_generic
	{
		class something {description = ""};
		class someotherthing {description = ""};
	};
};

 

The folder structure would then look like this:

• [functions]
  • myscript.hpp
  • [myscript_tools]
    • fn_init.sqf
  • [myscript_generic]
    • fn_something.sqf
    • fn_someotherthing.sqf
• description.ext

 

and a functionname would look like this:

TAG_fnc_something

 

Thats just one example though, there are different ways to organize this.

New scripts (that are configured like that) can simply be copied into the mission and then added to the description.ext, no need to call them in the init or anything like that.

 

[pierremgi 4739]

I'm not sure you have to postInit something if you call the functions from your mission scripts. On my mind, you postinit (init) when you need to run something at start, like for addon.

I'm using:

- config.cpp , with a postinit starting function, then other sub-functions are automated, for mods (so, any mission)

- description.ext  where all functions are declared, then called by scripts like init.sqf of else (for one scenario)

[Tajin 348]

37 minutes ago, pierremgi said:

I'm not sure you have to postInit something if you call the functions from your mission scripts

Well of course not.

 

I just prefer to do it that way instead of running it from the init. Both works.