Client side mod and server paths

[shinkicker 5]

Some examples:

P:\MyMod

P:\MyMod\MyScript.sqf

P:\MyMod\config.cpp

extract from config.cpp....

class CfgPatches {
class MyMod {
	units[] = {};
	weapons[] = {};
	requiredVersion = 0.1;
	requiredAddons[] = {};
};
};

class CfgMods
{
class MyMod
{
	dir = "MyMod";
	name = "My Mod";
	hidePicture = 0;
	hideName = 0;
	action = "http://www.mymod.com";
	version = "1.0";
};
};

In the A3 folder...

@MyMod\Addons\MyMod.pbo (containing the above config.cpp / MyScript.sqf)

in the MpMissions folder on a dedicated server..

MpMissions\MyMod.pbo

And in there.....

MpMissions\MyMod\init.sqf

Now what I want to do is execVM "MyMod\MyScript.sqf" on the client during mission loading.

So far I have tried everything I can think of (including using variations of !isServer and !isDedicated)...

execVM "\MyMod\MyScript.sqf";

execVM "MyMod\MyScript.sqf";

execVM "@MyMod\MyScript.sqf";

execVM "Addons\MyMod\MyScript.sqf";

execVM "MyMod\Addons\MyMod\MyScript.sqf";

execVM "@MyMod\Addons\MyMod\MyScript.sqf";

I pretty sure there are a few more I have missed.

I have also been messing around with PBOPREFIX, no luck there as well.

I had another look at a mod which does something similar (DayZ) and I can see this in the server init.sqf....

call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\variables.sqf";

I have no idea what 'z' refers too? Is this the drive map named rocket used? Is it some sort of reserved variable?

I would really like to get this going as I am developing and new MP mod which is content heavy and so I would prefer clients download from an off server site.

If anyone has an example which can be recreated real world they could share, that would be great!

EDIT: I should note, that perhaps this requires @MyMod on the server side too? If so I am even more confused as I want the script to run on the client?

Edited September 12, 2013 by shinkicker

[das attorney 858]

I'd like to find out the answer to this question as well.

I can init a script on the client/server with ease when using the excellent cba mod, but the method for doing it in vanilla Arma has eluded me.

@ Shinkicker - the \z\addons.... structure Rocket used for DayZ is useful when packing models into an addon (ACE uses the same structure - they use \x\addons...). It means you can integrate and binarize new models/pack new data without having to repack and repath the whole mod. (If I understand it correctly).

If you want to get it running and don't mind using cba, then try something like this:

class CfgPatches
{
class madeUpName
{
	units[] = {};
	weapons[] = {};
	requiredVersion = 0.1;
	requiredAddons[] = {"Extended_EventHandlers","CBA_main"};
};
};

class Extended_EventHandlers;   	// External class reference
class Extended_PostInit_EventHandlers
{
class madeUpName
{
	clientInit = "call compile preprocessFileLineNumbers '\NameOfYourModFolderInTheRootOfTheP_Drive\init.sqf';";
};
};

[shinkicker 5]

I'd like to find out the answer to this question as well.

I can init a script on the client/server with ease when using the excellent cba mod, but the method for doing it in vanilla Arma has eluded me.

@ Shinkicker - the \z\addons.... structure Rocket used for DayZ is useful when packing models into an addon (ACE uses the same structure - they use \x\addons...). It means you can integrate and binarize new models/pack new data without having to repack and repath the whole mod. (If I understand it correctly).

If you want to get it running and don't mind using cba, then try something like this:

class CfgPatches
{
class madeUpName
{
	units[] = {};
	weapons[] = {};
	requiredVersion = 0.1;
	requiredAddons[] = {"Extended_EventHandlers","CBA_main"};
};
};

class Extended_EventHandlers;   	// External class reference
class Extended_PostInit_EventHandlers
{
class madeUpName
{
	clientInit = "call compile preprocessFileLineNumbers '\NameOfYourModFolderInTheRootOfTheP_Drive\init.sqf';";
};
};

Thanks for the reply!

"and don't mind using cba"

- don't get me wrong, CBA is a wonderful thing, but I want to avoid using stuff if I don't need to. But it would bring a lot to the table for me.

"@ Shinkicker - the \z\addons.... structure Rocket used for DayZ is useful when packing models into an addon (ACE uses the same structure - they use \x\addons...). It means you can integrate and binarize new models/pack new data without having to repack and repath the whole mod. (If I understand it correctly)."

- does that mean you can make a change, rebinanrise while running hot (no need to shut the game down and up again?)

I'd like to find out the answer to this question as well.

Let's hope this thread brings something to light.

Edited September 12, 2013 by shinkicker

[das attorney 858]

does that mean you can make a change, rebinanrise while running hot (no need to shut the game down and up again?)

Unfortunately not. Config changes have to be done on game start.

If you don't mind reading on; there was a command introduced into an Arma 2 beta where it was possible to change config values on the fly, but so many people objected that BI dropped it. (Understandable as it would have been abused in MP).

It's a shame in a way though, because even with limited functionality, it would be really useful for the mission designer to be able to define vehicle and weapon classes in the description.ext, much in the same way as sound configs can be defined there.

Hopefully, the devs can work out how to do dynamic mod loading through steam, and then all of that will be moot.

[shinkicker 5]

Unfortunately not. Config changes have to be done on game start.

As I thought :-(

Perhaps they could have a -devMode flag, which would allow runtime injection of variables etc and a warning prompt pop up for when its used in MP. But then again I don't have a clue about the inner workings, so it might not be that simple / be a shit ton of work for BI to implement.

I wonder if its worth us reaching out to the ace team for who they do this. I caught rocket on reddit, but he may not have seen the message.

Edited September 13, 2013 by shinkicker

[alleycat 28]

If you want to call a script from an addon:

execVM 	"\@Addon\addons\server\server.sqf";

This is also very useful if you want to keep server code on the server and prevent clients from copying stuff from your addon (as long as the server files are not publically available)

In your case, you almost got the right variant. I highlighted the important slash.Try this:

execVM "[size=5][b]\[/b][/size]@MyMod\Addons\MyMod\MyScript.sqf";

[shinkicker 5]

If you want to call a script from an addon:

execVM 	"\@Addon\addons\server\server.sqf";

This is also very useful if you want to keep server code on the server and prevent clients from copying stuff from your addon (as long as the server files are not publically available)

In your case, you almost got the right variant. I highlighted the important slash.Try this:

execVM "[size=5][b]\[/b][/size]@MyMod\Addons\MyMod\MyScript.sqf";

Thanks for replying, but alas its not that simple. I think yours was one of the other ones I tried and forgot to list

[Tajin 348]

nul = [] execVM "\MyMod\MyScript.sqf";

"MyMod" <-- That part has to be the exact name of your pbo-file, NOT the name of the mod-folder.

Modfolders can always be renamed or you could put the pbo directly under "addons", it doesn't matter. Only the name of the PBO matters, as that will be the path to your files ingame.

[tonic-_- 53]

For addons you should have a file called PboPrefix.txt (Note PboPrefix.txt is a replacement for the file $PBOPREFIX$) in with your config.cpp / config.bin / whatever if not you need to create it.

When you set a prefix you are setting a file path sort to speak so for instance if you call your prefix MyTestaddon you can execute your script like so

[] execVM "\MyTestaddon\MyScript.sqf";

Note MyScript.sqf must be packed in with the PBO for it to execute as far as I know, I never did test whether or not it can work outside of it which I doubt it can.

[Tajin 348]

Script files work perfectly fine outside of pbo's.

You can put them pretty much wherever you want. The good part about that is that you can edit them while ingame and then simply run them again without having to reload. Very handy when you're testing things.

[shinkicker 5]

For addons you should have a file called PboPrefix.txt (Note PboPrefix.txt is a replacement for the file $PBOPREFIX$) in with your config.cpp / config.bin / whatever if not you need to create it.

BINpbo and eliteness automatically create PBOPREFIX which is what I have been using (as well as tweaking and creating my own). It currently has 'MyMod' in it.

---------- Post added at 13:17 ---------- Previous post was at 13:15 ----------

nul = [] execVM "\MyMod\MyScript.sqf";

"MyMod" <-- That part has to be the exact name of your pbo-file, NOT the name of the mod-folder.

Modfolders can always be renamed or you could put the pbo directly under "addons", it doesn't matter. Only the name of the PBO matters, as that will be the path to your files ingame.

For now I am using MyMod everywhere, so the PBO is called MyMod.pbo, dir='MyMod' under cfgMod, everywhere from what I can see.

[shinkicker 5]

Is there anyone at all that has actually got this to work?

I wonder if its ok to post the same to the Arma 2 mission editing board. Perhaps someone there has got this to work?

[das attorney 858]

I've done some playing about with this and got the following to work:

In the config:

class CfgPatches
{
class name_of_your_mod
{
	units[] = {};
	weapons[] = {};
	requiredVersion = 0.1;
	requiredAddons[] = {};
};
};

class CfgMods
{
   class name_of_your_mod
   {
       dir = "name_of_your_mod";
       name = "Name of your Mod";
       hidePicture = 0;
       hideName = 0;
       action = "http://www.name_of_your_mod.org";
       version = "1.0";
   };
};

Make sure to call the folder you are turning into a mod: "name_of_your_mod" (without quotes).

Inside the folder place the init.sqf file.

Then, in the mission, plop down a logic, call it "Server" (without quotes).

In the init field of the logic type the following:

if (isServer) then {0 = [] execVM "\name_of_your_mod\init.sqf";};

Then you only run the mod on the server and it still loads fine for the client.

Hope that helps.

EDIT: Forgot we were talking about client only - just change it to !isServer and then the clients will run the init, but not the server. (also then only the clients need the mod and not the server).

Edited September 13, 2013 by Das Attorney

[shinkicker 5]

Hi, I got it going too.

I am really shamed to admit this, but I was so focused on the paths being the culprit that I actually forgot to place my mod cfgpatches name into the mission file required addons list.

I will get my coat and call a taxi now.