m0nkey

UPDATE: November 2, 2015 Beta Version 2 10.25.2015 MKY_Snow_Script - beta v2 this is the full script version. * add - sample mission * add - batch file to create mission file for all winter maps * modify - use sound instead of music for audio * modify - only use one sound now * modify - many tweaks made to the blizzard effect * fix - many small issues I found 10.08.2015 MKY_Snow_Script - beta v1 this is only one snow effect, not the entire script So here is a beta version of the particle effects for a blizzard I have been working on. I've got a larger version than this one which does more than just blow snow. There are two missions here, exactly the same. One uses Meaty Reskins for the snow camo, the other is vanilla. There is a marker on the map with a dozen opfor/csat patrolling the small area. Just go there and kill, nothing special. I've ran it through a few times, no issues so far. Feedback desired. And yes, the framerates will be affected. Its a blizzard and uses a lot of particles to create this effect. Its better than it was but without better particles, it is what it is. In my testing though I've not seen any performance issues other than lower than normal fps. Get the sample missions here https://app.box.com/s/01bryqosrfqyp0nfvemxnyozpa3h4wa9 UPDATE: Beta 2 is now finished. Here is a video montage of all the maps except thirsk. There is a readme and a batch file. You should de-pbo the mission if you are going to use it, as there are both the mission init.sqf and description.ext as well as a very simple basic-int.sqf to use as an example. Its not complicated at all. Well, if you are used to scripting in arma, it shouldn't be hard at least :) I would greatly appreciate any feedback. I have not finished the addon version yet. I have not looked at stopping snow in buildings yet. Also have not looked at a proper sound solution. Real life is keeping me busy ;) So while I cannot say your requests will ever be fulfilled, I still would like feedback to improve it as I get time. The only bug I have seen so far that I have not fixed is sometimes when you load a mission/map, the snow comes down in a line rather than spread out, like a wall. Subsequent starts of the mission do not exhibit this behaviour. I have not figured out why it does this. Also, the JIP and dedicated portion need more testing than I can give it in my house. Oh, and I don't know how to put times in or whatever on the youtube video, like bookmarks or something? I would edit it so those are available if someone told me what to look up or what its called. Here are the times of each clip, in order 1:24 1:26 1:24 1:39 1:45 1:38 2:05 2:02 2:22 1:23 1:16 5:41

Oooh... nice. It's come a long way since the last time I used it for sure! But it still works really well.

Is this due to the particles or just too many loops and activities? I went out of my way to code things in the most effective way possible, and it helps a lot. But particles, well, you have to use them carefully. That's a lot of objects lol. I've thought that Arma doesn't seem to use gpu as well. Maybe it's just me. Seems more cpu dependent to me.

EDIT: Jan 19, 2016 V 003 Sample Mission on Shapur_BAF using my sand EFX script Dependencies - none, although the sample mission requires AiA_TP or CUP Core/Terrain addons Steam http://steamcommunity.com/sharedfiles/filedetails/?id=604564772 Box https://app.box.com/s/aqvn0gz0mvw4mh2vouvz829vk8pk4l65 * fixed a few server related issues * added some documentation * tweaked the particle emitter values a bit for visual presentation improvements * modified units in group to be playable for coop test Still a WIP at this point, but here are some videos of what I am working on for desert maps. I have learned a lot since I started on the snow maps. The more I learn, the more tricks I "think" I am finding to keeping the effect good while reducing resource footprint. You just have to be creative.. and read a bunch and experiment even more.. basically you don't play the game at all, you just code for it... hmm. ;)

I've only recently began turning my computer on. lol, I don't recall everything that I did as of yet. I'm not even sure if it works yet, as there have been a lot of changes. Last version of the game I recall using was 1.56 or something. I documented it all, that much I remember. It is scripting, so you have to actually follow the directions. I would love to make it an addon but I never got to that point, and now I have to start over to a degree. After I figure out why my favorite coop mission is giving errors with Zenophon's coop framework, I will incorporate my snow/sand into it and I will find out if it works. I have also seen a few other snow scripts I will check out. All of these can be CPU intensive, maybe someone figured out a better algorithm. The real problem with these effects is that if you travel fast enough, you can travel out of the effect and you have to wait for it to catch up.

Been a long time since I've messed with computers or games. A little something called a divorce grabbed my attention, not to mention older kids needs. Anyhow, I was itching for a little ArmA action, and decided to update one of my missions with the latest framework. I don't remember all the sqf stuff I used to know, but enough. I am encountering a similar issue as described above. Perhaps you can elaborate on your fix you mentioned, regarding a unit that is referenced but now null. It happens when calling AddGiveMagazine. It appears to be that an array of named objects (playable units) is passed to CheckArguments or ConvertToObjectArray (or others) is found by ZCA (check args) as OK, but a later call there are null objects (dead units), so ZCA fails with (usually) a void (typeName) error. Example errors (I have been adding code to track it, but there's a lot of calls going on) 20:45:37 "-->>>> FUNC respawn - Begin call Z Add Giv Mag !! the unit is :: x12 :: <<<<--" 20:45:37 "---->>>> FUNC Begin - Z Add Giv Mag - :: [[x12]]" 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[[x12]],[[""VOID""]],[],1] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "------>>>> FUNC Begin - Z Con To Obj Arr - _this is :: [[x12]] :: <<<<..." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[[x12]],[[""VOID""]],[],1] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "------>>>> FUNC End - Z Con To Obj Arr - _return is :: [x12] :: <<<<..." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[[x12]],[[""ARRAY""]],[],1] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[x12,[]],[[""VOID""],[""VOID""]],[],2] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "------>>>> FUNC End - Z Con To Obj Arr - _return (remove dupes) is :: [x12] :: <<<<..." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[""Zen_Action_ID_PWMi].pav?"",[x12]],[[""STRING""],[""VOID""]],[],2] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "------>>>> FUNC Begin - Z Con To Obj Arr - _this is :: [[x12]] :: <<<<..." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[[x12]],[[""VOID""]],[],1] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "------>>>> FUNC End - Z Con To Obj Arr - _return is :: [x12] :: <<<<..." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[[x12]],[[""ARRAY""]],[],1] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[x12,[]],[[""VOID""],[""VOID""]],[],2] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "------>>>> FUNC End - Z Con To Obj Arr - _return (remove dupes) is :: [x12] :: <<<<..." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[""Zen_Action_ID_PWMi].pav?""],[[""STRING""]],[],1] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[[""Zen_Action_ID_PWMi].pav?"",""<t color='#2D8CE0'>Give Magazine</t>"",""Zen_GiveMagazine"",[],[1,false,true,"""",""((_target == _this) && !(surfaceIsWater (getPosATL _this)) && (vehicle _this == _this) && {(({(side _x == side _this) && ([_this, _x, 120] call Zen_IsFacing)} count (((getPosATL _target) nearEntities ['Man', 3]) - [_this])) > 0)})""],[x11,<NULL-object>,x13,x14,x21,x22,x31,x32,<NULL-object>,x12,x12],[],[]],0,5],[[""ARRAY""],[""SCALAR""],[""SCALAR""]],[],2] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[[x11,<NULL-object>,x13,x14,x21,x22,x31,x32,<NULL-object>,x12,x12,x12]],[[""ARRAY""]],[],1] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[x11,[]],[[""VOID""],[""VOID""]],[],2] <<<<<....." 20:45:37 "__>> FUNC End - Z Chk Arg == return (_match) is :: true <<<<<....." 20:45:37 "__>> FUNC Z Chk Arg - Begin !! == _this is :: [[<NULL-object>,[x11]],[[""VOID""],[""VOID""]],[],2] <<<<<....." 20:45:37 "----->>> FUNC Z Chk Arg - typeName !! == is :: <NULL-object> && OBJECT <<<<<....." 20:45:37 "-- Zen_CheckArguments Error --" 20:45:37 "Argument 1 is void (typeName)" 20:45:37 383.533 20:45:37 [<NULL-object>,[x11]] 20:45:37 ["Zen_CheckArguments",[<NULL-object>,[x11]],383.533] 20:45:37 ["Zen_ValueIsInArray",[<NULL-object>,[x11]],383.533] 20:45:37 ["Zen_ArrayRemoveDuplicates",[[x11,<NULL-object>,x13,x14,x21,x22,x31,x32,<NULL-object>,x12,x12,x12]],383.533] 20:45:37 ["Zen_InvokeAction",["Zen_Action_ID_PWMi].pav?",[x12]],383.533] 20:45:37 ["Zen_AddGiveMagazine",[[x12]],383.533] You can see that each unit is valid, yet at times not. I don't think a check of player==alive or similar would work, as the whole call begins on a respawn handle, so the unit/body has already been spawned/created by the engine? The last time I was doing anything with Arma I was using your version 5/6/15 lol. It does not give this error, but then ZCA is different. I'm no slouch in program logic, but without having to reinvent the wheel here, what were you eluding to in the form of a cleanup of code to fix the issue which sounds a lot like the post above. Pretty please?

Hello. I'm just your typical hardcore geek who knows a little about a lot, but not enough about arma scripting. Trying to bring myself up to speed as it were. One thing that is pretty different in arma, compared to basic script languages like vb or autoit (lets not even get into dos/batch lol) is the array. Its typical to init an array - _myArr = []; and to init with values - -myArr = ['boy','girl','dog']; and also fairly typical in the forEach loop and even the less popular for "_i" type loops. I've used all these. I understand what arrays are, etc etc. In looking at the code optimisation page, I can see right away how you can append a value in the fastest method by using set and count. Its easy to understand, set will set the value at an index. And when used in conjunction with count its saying, in a basic form $array = ['one','two','three'] $array[ubound($array)] = 'new value' Which is just not subtracting 1 from the last index value, like you would do if you were going to step through an array with a loop. Its also redim'ing the array at the same time by +1 But I also see that count is faster than forEach, when stepping through arrays. The reserved variable _x will reference the "value" of the current index in the stepping. forEach actually gives you the indice if you want it. But for sake of creating optimized code, here is an example I have been struggling with. Its of no bearing other than its something I chose to play with. define an array of squad mates _squadpeeps = group player; define an array publicly arr_livepeeps = []; now the goal is to step through the array of members of squad, see who is alive and not the player, then add/append them to the blank array. Something like this: { if (alive _x and _x!=player) then {arr_livepeeps set [count arr_livepeeps, _x];}; } forEach units _squadpeeps; this appear it would step though the members of the group, referencing _x and if alive and not player, resize the array by +1 and put the object handle to the player in the array (I think its an object handle anyway). What I don't get is how to use count in such a situation. I see count as having one function, to return a count, although it does reference _x. So you can: _var = count _array; _var = {_x == 'boy'} count _array: But I don't get how to use count rather than forEach. This is strictly academic. I've a fast computer and noticed that some maps/missions are so slow that my fast computer seems like a turd. Reading and experimenting show me too many objects at once, misconfigured servers and too many scripts or too heavy scripts or just scripts that aren't optimized seem to be the main culprits. So, since I am sick and tired of the way other FPS games are going, I'd like to figure out how to make my own missions in arma for me and my buds that don't suck the performance out of our machines and kill the experience. Thus, time to learn arma script language, and frankly I've too much experience to just copy/paste blindly. I know how much little bits of optimization can help. Anyone care to teach a noob? PS: where is the best resource for how arma is actually doing things, like what files/scripts are loaded first, order of events etc, and a guide for how to properly code multiplayer missions to properly utilize the order of events, things of that nature. Arma is so spread out its quite frustrating finding good infos ;)

Unfortunately no. I looked quite deeply at every particle effect I could find, and the values/parameters of them. I could not find anything to use without some (possibly) really complicated stuff which I don't know how to do. Meaning, not billboard particles. I am pretty sure that the character model clips the particles, and when in a vehicle, its a model when you are in it (at least as driver in a truck). As a passenger it might not be a "player model or character model, whatever its technically called". Anyway, I tried lots of things like placing models above the players position (such as in a building) that might "clip" the particles. I even tried creating a body of water like a pond X meter in size above the character, because the particles clip on surfaces like water. But that did not work. I also tried using a circle emitter, in which to make the snow fall outside the model of the building in a circle. That would work, but the math was pretty tricky because the model spaces were so hit or miss (bounding boxes etc). I gave up on that because it was going to take forever to test it and I felt it would only be a partial solution (similar to particles moving properly with vehicles). There just aren't enough particles available to achieve certain effects, or if there are its just too many for many systems. Killzone Kid has the only working example I have seen of it not allowing particles in building models. I PM'ed him but no reply, so I can assume he is still cooking something up and doesn't want to share it yet. I can't blame him for that, its what I would do too. So, the short answer I guess is no. :)

Roger that. 3 is the level of snow. If you use the boolean "true" as the second parameter, then it will not vary. The strength of the effect then can be controlled by the scripter if so desired. IF you will note in MKY_Snow_Client.sqf, around line 260, that the "heavy" effect will use by default a dropInterval of 0.03. As the MKY_Snow_Server.sqf script runs, it would choose a random value (around line 79 in that file) UNLESS you set that 2nd parameter to true. And I will state the obvious that it does not choose a random value to vary the effect, but stays at 0.03 indefinately. You might also note at the bottom of MKY_Snow_Server.sqf I have commented that the global variable "varSnowData" can be used to change the snow effect. A server could set this then publicize it, or the client could do it. There are a few different global variables you can modify if you really want to fine tune it. Hope that gives you some fuel lol.

Latest version is 100. It has both sand and snow. Its on my steam workshop. Nomenclature for whiteout etc has changed to simply "light,moderate,heavy". I made a very simple mission as an example. De-pbo the mission and look at the init.sqf file for use. I commented things quite a bit. If you still have questions after that, glad to help. You can also look at my older versions as I commented those quite a bit as well, but have done so much scripting on both these EFX and so many others that I don't really remember off-hand the exact syntax.

I will try to take a look at it this week. I have a vr scenario I think that I used. At worst I can share it and you can compare the changes I made to get an idea. I modified it to work with bis respawn as well. See what I can do.

It works. It works really well if you modify it for your specific mission. I love this script. I've got it working nicely, but its really not "easy" because much depends on your mission.

My script should work in SP as well. I have tried it in the past, cannot remember if I did with this v100 or not. If it does not, its a very small thing to fix it so that it will I am sure. I almost always use MP because I only do coop really. And I rarely use the editor, its almost all scripting for me.

Very weird. I downloaded the v003 from armaholic. I extracted it and then cut/pasted it to C:\Users\mky\Documents\Arma 3 - Other Profiles\m0nkey\MPMissions\MKY_Sand_v00333.Shapur_BAF I then opened arma, went to multiplayer, clicked <<new 3d editor>>, then clicked open, highlighted the v00333 directory and clicked import. I then previewed the mission (in eden editor) and it worked just fine. I cannot say why you two have that error. And in fairness to yourself, I just put that new version up yesterday because of the issues reported in this thread. I might have been premature in that, time will tell. But I don't think the syntax and structure are going to change any time soon, so might as well adopt it if you like the EFX it gives :)

Here is a link to the script files. https://app.box.com/s/29x5lllol4wxs6j610rhpl1m1n89cvnv I personally de-pbo missions with mikero tools. I don't like how the editor can muck things up, so I do it manually. If I am going to edit something, I de-pbo, rename directory, and place it in mpmissions (userprofile, not game root). Then I can edit it without issue, and all files are in place. If I saveas, it only copies the mission.sqm, so I must copy the files from the original mission directory into the "new copy" directory. Thus, I find it easier to do it myself. Anyway, this script is pretty simple to get working. If you look in that zip file, you will see what is needed in the init.sqf. Define 2 global arrays the script will use. Exec a script to get world data.. Wait for the script to finish, which exposes a global variable. Define your desired EFX settings in an array (one for snow, one for sand). Initialize the EFX. I do include audio, so note in the description.ext file the use of CfgMusic. Some have stated music might not be the best method, but I have not had time to change it and I cannot remember now why I switched to music anyway. The only other thing you "should" do is look at is the MKY_fnc_getInfoWorld.sqf file. In it I define what worlds get snow or sand. Other than that, it should just work. There are of course things you can micro-manage, but that should all be in the comments in the files. I guess as a script (and me using and creating scripts) I always read them, and always like commented code so that I can understand (or remember haha) what is going on and what options are. Regular text files or readme's usually confuse me.. I like the really geeky stuff for some reason. I am happy to provide more info if needed.

Okay, I uploaded two missions to my steam profile or whatever, workshop thing..., one on Takistan for the sand and one on Abramia for the snow. Missions are the same, just a couple squads to shoot at while the snow/sand comes down. The snow and sand scripts are both in each mission. The init.sqf is very basic (no parameter array stuff this time). Read the script files, I commented much of it. I don't believe I have released this version yet, so it should be fairly different in syntax from the previous ones. I am not even sure I was done with it to be honest. I just don't have the time right now to dig into it and refresh my memory. That will have to wait till late summer. But, they both worked, so its going to have to do for now. Besides, in my limited time testing I already have a better vision of a sand effect. I really don't play this game at all, I just code. Ha. Enjoy.

My goal is by the end of this weekend. We will see if that happens :)

Check your pm @general. Seen the youtube comment as well. I messed with latest version last night, looking for last minute bugs. hope to release that (which is part of my heavily modified All Out Warfare version) very soon.

Have not had any pc time for about a month really. Too busy. @hammer The error is saying that the variable "paramsArray" is not defined. The only reason it would not be defined is if the description.ext file is not existing. This can occur if you open a mission in editor and then save it. Editor saves missions in %userprofile%\arma3\mpmissions\mission_name.map_name. If it was not there or was renamed, it will NOT save anything except mission.sqm. My bet is all dependency files are missing from where it is located. Put those files in that directory, and all should work. @thegeneral From the shapur_003 files, there is no snow, only sand. I have a new snow that does not require wind changes. . I think the last version of snow was MKY_sand_snow.thirskw. Syntax might be slightly different as I cannot recall whether sand or snow introduced the current syntax first... I will endeavor to release the latest versions soon. But I have to refresh myself with what I was last doing, its been so long...

I have not looked extensively at this topic much, but I have had to modify my own and others code to fit engine changes. The most current change I came across was when using a modified version of =BTC= quick revive from Cruoriss's "All Out Warfare" scenario. In it I found that version 1.56 update actually removed the BIS_fnc_reviveSetStatus function. If you don't know, when a player is killed with the endgame revive/respawn mode turned on, the "killed" EH triggers and you would normally escape it if the variable BIS_revive_incapacitated is true. In the modified =BTC=qr script Cruoriss (I presume) was using the above function to set the players state back to alive and the function took care of propagating that knowledge to clients. When player is killed, and is in the incapacitated state, and that function is ran, the player "turns back alive" without triggering the "killed" EH again. If however the player is "revived" by holding down the spacebar, the "killed" EH is triggered again. Anyway, v1.56 removed this function. I archive all versions, so I went back into v1.54 and sure enough, it exists in the function viewer. I was stumped on what to do as a replacement as there is no documentation on this that I could find. I ended up digging in the marksman pbo files and found the solution. ["",1,_unit] call BIS_fnc_reviveOnState; _unit setVariable ["#rev", 1]; Those two lines will, even when ran from command console, "revive" a player who is incapacitated. Just a big FYI in case you wanted to know how to do that ;)

This is what I made. Works for me for what I need. I either call it when I feel its needed, or I put it in an endless loop on a timer, like every 5 minutes or something. All depends on the mission I guess. f_server_Refill_Ammo = { // refill all AI ammo (keeps engagements going) 0 = [] spawn { { if !(isPlayer _x) then { if ((handgunWeapon _x) != "") then { _mag = (getArray (configFile >> "CfgWeapons" >> (handgunWeapon _x) >> "magazines")) select 0; _x addMagazines [_mag,3]; }; if ((primaryWeapon _x) != "") then { _mag = (getArray (configFile >> "CfgWeapons" >> (primaryWeapon _x) >> "magazines")) select 0; _x addMagazines [_mag,8]; }; if ((secondaryWeapon _x) != "") then { _mag = (getArray (configFile >> "CfgWeapons" >> (secondaryWeapon _x) >> "magazines")) select 0; _x addMagazines [_mag,2]; }; }; sleep 0.5; } forEach allUnits; (true); }; (true); };

Personally I remove pistols and bino/laserdesig from AI. They go around using binos for no reason and are bad shots with rifles, so pistols only make it worse. Then, I make a function that fills AI ammo. It could be all AI or only one side or only my squad. Its not about cheating or unlimited ammo, but about keeping a firefight/mission going. It depends on the situation.

I use Notepad++ but also scite/scintilla. I normally have both open, because I like the difference in display styles. I also use beyond compare quite a lot. And qdir browser. And I also use dngrep a lot, like, all the time with arma missions. Those are about it.

After many hours messing with this, and hopping back and forth among all the different script packages, I am nearing completion of what I wanted. I don't have a list of what I've done yet, but its fairly extensive. Most of it is fine tuning it for a more immersive feel. Here is a video. Its just showing spawning of marksmen/snipers as an immersive effect for a given zone.

Not sure why someone else hasn't noted this, but there are some errors cropping up. First is a local variable _cfg_map_pos is wanting to be used in a different script (briefing). I changed it to cfg_map_pos and it solves the issue. There are also numerous errors that occur because initPlayerLocal fires before init.sqf does. There are some calls being made that I don't implicitly know the order of, so I put the code from initPlayerLocal into init.sqf prior to (isServer) section, and now there are no issues at all. It is also worth noting that if you use this as a template for a different world, that in the init.sqf file, there is a while {true} loop in the (isServer) section, so any custom code you wish to run needs to be prior to this or in an exec/call. These are not major issues by any means, and I've had a good time so far on this mission. Good job. EDIT: Actually I see that there are better fixes. In globalfnc.sqf I add this at the bottom bGlobalFncFinished = true; In init.sqf I modify this [] call compile preprocessfile "battlezone\global\globalfnc.sqf"; to be this if (isNil "bGlobalFncFinished") then {[] call compile preprocessfile "battlezone\global\globalfnc.sqf";}; Also in init.sqf I find this line missionNamespace setVariable ["cfg_map_pos", _cfg_map_pos, true]; and add this after it publicVariable "cfg_map_pos"; Finally in initPlayerLocal.sqf, once inside the if (hasInterface) brackets, I also add if (isNil "bGlobalFncFinished") then {[] call compile preprocessfile "battlezone\global\globalfnc.sqf";}; and a few lines later, I find this [] execVM "battlezone\scripts\briefing.sqf"; and add a line, like this waitUntil {sleep 0.1; !(isNil "cfg_map_pos")}; [] execVM "battlezone\scripts\briefing.sqf"; That seems to fix the issues on dedicated as well as hosted, so far anyway. Its all about how each file executes in order, and whether variables exist or not, especially on dedicated.