anfo 118 Posted October 18, 2017 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. Share this post Link to post Share on other sites
Larrow 2800 Posted October 18, 2017 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. Share this post Link to post Share on other sites
serena 150 Posted October 18, 2017 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; Share this post Link to post Share on other sites
Tajin 348 Posted October 18, 2017 @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. Share this post Link to post Share on other sites
pierremgi 4739 Posted October 18, 2017 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) Share this post Link to post Share on other sites
Tajin 348 Posted October 18, 2017 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. Share this post Link to post Share on other sites