Has anyone tried loading up their profile namespace with a ton of data?

[dreadedentity 278]

What happened? Where there any adverse affects to loading times from it? Are there any limits? I'm considering writing up some debug tools and saving them to my profile so I can have access to a range of tools with a simple

call (profileNamespace getVariable "dread_debug");

EDIT: Quick update, I just saved a few addActions to my profile and it's magnificent. I'd still like to hear from others, however

Edited December 7, 2014 by DreadedEntity

[fn_Quiksilver 1636]

What happened? Where there any adverse affects to loading times from it? Are there any limits? I'm considering writing up some debug tools and saving them to my profile so I can have access to a range of tools with a simple

call (profileNamespace getVariable "dread_debug");

EDIT: Quick update, I just saved a few addActions to my profile and it's magnificent. I'd still like to hear from others, however

It is handy and I haven't noticed any adverse effects. Perhaps there is added execution time if there is a lot of data in there, but for runtime use, no, no issues.

I use it for debugging, instead of using all those if (_debug) then { type things that people put into their code.

If you're putting it into an MP scenario, ensure you qualify it however, behind a getPlayerUID check or similar security measure. If you don't I can then write whatever I want to my profileNamespace and use your profile namespace call as a back door.

Example security measure:

in a client file exec from initPlayerLocal.sqf, something like:

"receiveProfileAccess" addPublicVariableEventHandler {
       _arr = _this select 1;
       [] call (_arr select 0);
};
requestProfileAccess = [player]; publicVariableServer "requestProfileAccess";

in a server-side file called "serverpveh.sqf":

DE_dreaddebug_UIDs = ["234709148792347","31984729347219348"];    // your server-stored UIDs that you allow access to profile namespace

"requestProfileAccess" addPublicVariableEventHandler {

_arr = _this select 1;
_uid = getPlayerUID (_arr select 0);
_cid = owner (_arr select 0);

if (_uid isEqualTo [DE_dreaddebug_UIDs]) then {
receiveProfileAccess = [profileNamespace getVariable "dread_debug"]; _cid publicVariableClient "receiveProfileAccess";
};
};

in initServer.sqf:

[] execVM "\serverpveh.sqf";

Edited December 7, 2014 by MDCCLXXVI

[dreadedentity 278]

If you're putting it into an MP scenario, ensure you qualify it however, behind a getPlayerUID check or similar security measure. If you don't I can then write whatever I want to my profileNamespace and use your profile namespace call as a back door.

It took me a minute to understand what you meant, but that makes sense. In my case, if I did something like that, instead of being called through scripts in MP, it would remain a debug console-execution only situation, probably

[fn_Quiksilver 1636]

It took me a minute to understand what you meant, but that makes sense. In my case, if I did something like that, instead of being called through scripts in MP, it would remain a debug console-execution only situation, probably

Aye, debug is an easier execution method I think. I edited the post with an example of how to put it into a MP PBO in a reasonably safe way.

Let me know if you come up with anything interesting to do with profileNamespace ... Its an area I just dont have the time to look into much.

[Tajin 349]

I'm considering writing up some debug tools and saving them to my profile

I don't see much sense in saving functions in your profile. You could just put em in scriptfiles in your game dir and call em directly.

However, using profile-variables like 1773 said can be pretty useful.