bad benson

just letting you guys know about this cool script i just remembered reading this thread. not sure if it still works or if it works well but the idea is bad ass (watch the video). it basically uses minesweeper to do the disarming process. https://forums.bistudio.com/topic/173335-shoters-disarm-script/

i think the point is to have this as an option for the players once the mission has started. so i'd just use player switch to achieve this, so basically use the "selectplayer" command right before you open the arsenal. then detect somehow when teh arsenal is being close and switch back to the original player that you have stored in a variable before using "selectplayer" again.

so since you are using "this" as the unit variable i'm assuming you are doing it inside hte init line? i might be outdated here but if i remember correctly the init line has problems with that command caused by its timing in the whole execution order. try either a trigger or similar ot put this inside the init line: 0 = this spawn { sleep 1; //add this sleep, if it doesn't work without it _this switchmove "animationclassname"; };

as i mentioned. that source has been unpacked a while ago. you'd be better off unpacking those pbos (i provided the names) of your current install. might potentially fix that.

yes do that. it doesn't overwrite respawn templates from the description.ext (assuming you want to preserve revive or just respawn in general). all these event scripts do is execute once the specific event happens. here's a list and possibly more details: https://community.bistudio.com/wiki/Event_Scripts

from structures_F (CfgVehicles) class Land_Campfire_F: House_F { mapSize = 2.17; author = "$STR_A3_Bohemia_Interactive"; _generalMacro = "Land_Campfire_F"; scope = 2; scopeCurator = 2; displayName = "$STR_MISC_CAMPFIRE"; model = "\A3\Structures_F\Civ\Camping\Campfire_F.p3d"; icon = "iconObject_circle"; vehicleClass = "Tents"; destrType = "DestructNo"; simulation = "fire"; cost = 0; keepHorizontalPlacement = 0; class Effects: SmallFire { class Light1 ////////////<<<<<<<<<<<<<<<<<<<< { simulation = "light"; type = "SmallFireLight";////////////<<<<<<<<<<<<<<<<<<<< }; class sound { simulation = "sound"; type = "Fire_camp"; }; class Smoke1 { simulation = "particles"; type = "SmallFireS"; }; class Fire1: Smoke1 { simulation = "particles"; type = "SmallFireF"; }; class Refract1 { simulation = "particles"; type = "SmallFireFRefract"; }; }; }; from data_f (CfgLights) class SmallFireLight { name = "$STR_A3_CfgLights_SmallFireLight0"; diffuse[] = {1,0.45,0.15}; color[] = {1,0.45,0.15}; ambient[] = {0,0,0,0}; brightness = 10.0; ////////////////<<<<<<<<<<<<<<<<<<<< intensity = "3500*(power interpolate[0.1, 1.0, 0.4, 1.0])";////////////////<<<<<<<<<<<<<<<<<<<< blinking = 0; drawLight = 0; class Attenuation { start = 1; constant = 3; linear = 0; quadratic = 22; }; position[] = {0,3.5,0}; }; should get you started. this stuff has been unpacked a while ago. so who knows, maybe it's the old shit you're looking for :lol:

i had a friend call me on skype the other day telling me that mod makers work faster, if you annoy them about release dates. he also told me it motivates them a lot. i dunno, might be just a rumor though.

tbh. i didn't really read your script. problem is that i told you to put the code at the end of the script. but the while loop blocks it. so make sure to put the setvariable stuff before the loop.

are you guys setting up everything with hidden selections? could be useful for people who want to make reskin patches and stuff.

i think you are confusing it with the halo/free fall animation. he's talking about the silly one you also do when you climb onto stuff that isn't prepared professionally (looking at you BI) inside the model (unwalkable).

afaik optics are engine controlled 3d dialogs. so you could go ahead and use something like this (pseudo code): _modelpath = getText (configfile >> "CfgWeapons" >> _tankweap >> "optics" >> "model"); //not a real path...pseudo...too lazy to look it up lol and then create a dialog that has that model in it. alternatively ctrlCreate could potentially be enough to make it show up. haven't tested that with 3d stuff. get this for working examples of 3d controls in dialogs: http://steamcommunity.com/sharedfiles/filedetails/?id=287378519

that's one of the great things about it. aside from the gear stuff all you need is some entries inside your description.ext this page has all you need: https://community.bistudio.com/wiki/Description.ext but here's also a simple example for a quick test. respawn = 3; //not sure if revive is restricted to certain types but this one works for sure respawnDelay = 5; respawnTemplates[] = {"Revive"}; //this is the crucial one, the rest is jsut what i use in my mission respawnOnStart = -1; respawnButton = 0;

i really like the BIS one. only drawback i could find so far is the lack of dragging wounded people and gear being reset when you get downed. can be easily fixed by doing this though: OnPlayerRespawn.sqf: _unit = _this select 0; _unit spawn { _unit = _this; sleep 2; if (animationstate _unit == "acts_injuredlyingrifle02_180") then { [_unit, [missionNamespace, "SavedInventory"]] call BIS_fnc_loadInventory; }; }; _unit addEventhandler ["Killed", {if (local (_this select 0)) then {[_this select 0, [missionNamespace, "SavedInventory"]] call BIS_fnc_saveInventory;}}]; kinda ripped out of my mission and untested liek this but should give you an idea.

you need to store the lights preferably with setvariable on the vehicle. but make sure to not set it to global so you can save the lights local to each client locally on the same vehicle (probably confusing as fuck lol). and then do the same as above with a function that deletes those lights. so at the end of the sqf you have above you add this: _car setvariable ["lights", (_leftlights + _rightlights)]; //saving all lights into one single array on the vehicle now you make a second sqf like this _car = _this select 0; _lights = _car getVariable "lights"; //retrieve light array { deletevehicle _x; } foreach _lights; ///delete all lights and that script you run the same as you ran the other one inside he addaction. like so: [[_car], "lights_OFF.sqf"] remoteExec ["execVM", 0, true]; //or [[[_car], "lights_OFF.sqf"], "BIS_fnc_execVM", true, true] call BIS_fnc_MP; none of this is testing like the stuff before but should give you an idea about what i mean.

you could attach an object with a roadway lod right under the feet of the unit and make it invis. i tried that in soem context a while ago. should work just fine.

try this: _car addaction ["Lightbar On", { [[_this select 0], "lightbar.sqf"] remoteExec ["execVM", 0, true]; }]; //or _car addaction ["Lightbar On", { [[[_this select 0], "lightbar.sqf"], "BIS_fnc_execVM", true, true] call BIS_fnc_MP; }]; both aren't tested but based on the wiki stuff i found. here are some source links. https://community.bistudio.com/wiki/remoteExec https://community.bistudio.com/wiki/BIS_fnc_execVM https://community.bistudio.com/wiki/BIS_fnc_MP that should get you started at least.

here's a shitty hack that might get you somewhere. not taken care of shooting but only aiming so far. _agent = createAgent [typeof player, [0,0,0], [], 0, "FORM"]; _agent moveingunner vehicle player; _target = "Box_NATO_Wps_F" createVehicleLocal [0,0,0]; _target allowdamage false; [_agent, _target] spawn { params ["_agent", "_target"]; while {true} do { _target setpos (positioncameratoworld [0,0,100]); _agent lookat _target; sleep 0.1; } }; run this in the consoel after entering an empty tank as a driver. you can use free look to aim the turret. it's just a simple test but works good enough already. check these to make the firing happen: https://community.bistudio.com/wiki/doFire https://community.bistudio.com/wiki/doTarget this could also help when confused in combat: https://community.bistudio.com/wiki/disableAI your "animate" idea is great too. just not sure how universial it would be or if you'd need special values for each single tank. i'd imagine the approach would be similar. getting the camera vector and then using the aniamte command to align the turret with it. EDIT: this works great for making the gunner fire: player addaction ["FIRE", { vehicle player action ["UseWeapon", vehicle player, gunner vehicle player, 0]; }];

i think you should also post this inside the dev branch scripting discussion thread. https://forums.bistudio.com/topic/151099-scripting-discussion-dev-branch/page-47

i think overall you already got the right idea. especially that one line of yours pretty much sums up my personal approach: "use both scripts for functions and mods for contents" (the word content could also be replaced by the word "assets" here to make it clearer) imho the biggest benefit of mods is additional data. or what you call it "content". new weapons, new units, new terrains. basically anything that requires new models, textures, animations. and of course all the config changes that others have mentioned. sounds can be done inside a mission and addon so they kind of fall out of this. if you see a small mod that adds some scripted functionality, you should always think about the possibility of making that feature (or similar) yourself inside the mission. and among those "functionality" mods you also should divide between things that are potentially integral to a mission or, if it's an optional addition that doesn't interfere with or break the mission. so you should not try to make core functionality of you mission dependant on some addon, if you can avoid it. i personally am a big believer in doing gameplay as much as possible in the mission but also using methods that adapt to the addons that happen to be installed on the server. that means for example reading available enemy unit classes from the config and then spawning from that pool. similar to how BI's Arsenal automatically shows you all weapons (inlcuding mods) that are available. another similar example would be spawning of random loot. i would never make huge arrays of all stuff but rather have functions that can spit out just what i need from everything that is available (every mod installed) on the fly. it all depends on what you're trying to do though. i've seen mission with huge lists of mods and i understand that the mission maker might want to recreate a certain look and thought there's no way around 4 different weapon addons. i personally would never play those missions though since i'm simply to lazy and it's way to inconvenient for something that might not be good and i'd have to play it first (including downloading the full list) to find out. as a final note i'd add that CUP and RHS at this point could be considered vanilla since most people already have that downloaded, so i'd not be too worried about using those.

this is a great mission 10/10 recommended to everyone who's tired of missions with big build up that never deliver on the actual gameplay side. this shit is legit fun.

not strictly DEV build related but does anyone else get frequent game crashes with memory related errors? i got a feeling it's related to the memory stuff that was added. is there a setting in the launcher that would fix that?

this mod is pure gold. i encourage everyone to try it out who hasn't yet. most balanced overall sound mod i have seen in arma. and all sounds have a great unique character and all fo the guns have this powerful "pop/snap" or whatever. i mean i'm a fanboy, but still. don't miss out on this!

isn't that kind of a grey area? like, sure it depends on the license in question but think about all those missions with custom intro songs. technically that's like uploading a song to a file hoster, so illegal. but in reality i can't imagine someone really caring unless you take let's say a whole book and put it into a mission in text form or a whole movie as an intro movie (i know, why woudl you?). i'd even say (more like guess since i'm not a lawyer :lol: ) that even direct sound and vid bits fall under the above. an example would be youtube videos using movie scenes in a meme like fashion cut into the video. kind of a similar situation and not something i can see someone having a problem with. EDIT: grain of salt implied...

very cool and creative. loving it.

such great colours, right amount of wear on the metal, great wrinkles on the clothes too. really top notch stuff. can't wait to use all that stuff. such consistent quality. this gun be gud!