blakeace

This will actually do both, you specify the maximum angle with the value in front of the Max Gradient comment currently set at 0.3 below, the higher the value the greater the slope is allowed to be. Set the local variable _preview to equal the object you want to move, and it checks to see if there is room to place it. To see how it works, place in a loop that uses a hint to show the returned value in _isFlat, and set the position on yourself. Make _preview something bigger like a warfare building and run around. It will save the position values [x,y,z] in _isFlat only if the criterea is met. So I check the count _isFlat > 0 to tell me if it is returning a valid position. _isFlat = (_start) isflatempty [ (sizeof typeof _preview) / 2, //--- Minimal distance from another object 0, //--- If 0, just check position. If >0, select new one 0.3, //--- Max gradient (sizeof typeof _preview), //--- Gradient area 0, //--- 0 for restricted water, 2 for required water, false, //--- True if some water can be in 25m radius _preview //--- Ignored object ];

No idea, I am not a scripting guru sorry, but just took Xeno's code and just changed when each part kicked in. Instead of when you die, let you choose when to save and restore your gear. So I really have no idea about this, and would have to bump it up the knowledge chain sorry. Re ACE stuff, even more out of my range sorry. Oh well was worth a try. Sorry it didn't solve your problem.

Yep sorry I was on the phone while doing this and didn't really test it. It seems to be the choice of variables, which I just changed from local to global. I forgot to rename them as they are reserved words. Works multiple time now sorry. This one should work, though I am no scripting guru so no promises. SecureGear.sqf _p = _this select 0; weapons1 = weapons _p; magazines1 = magazines _p; removeAllItems _p; removeAllWeapons _p; _p removeaction actionid; actionId = _p addAction ["UnSecure Gear", "UnSecureGear.sqf", ["", 8], 1, false, true,"" , " _target == player"]; UnsecureGear.sqf _p = _this select 0; removeAllItems _p; removeAllWeapons _p; {_p addMagazine _x} forEach magazines1; {_p addWeapon _x} forEach weapons1; _primw = primaryWeapon _p; if (_primw != "") then { _p selectWeapon _primw; // Fix for weapons with grenade launcher _muzzles = getArray(configFile>>"cfgWeapons" >> _primw >> "muzzles"); _p selectWeapon (_muzzles select 0); }; _p removeaction actionid; actionId = _p addAction ["Secure Gear", "SecureGear.sqf", ["", 8], 1, false, true,"" , " _target == player"]; Try that, as I said I haven't tried on a dedicated. But I think it should be ok as the action would be performed local.:butbut:

For most purposes in Arma 6 figures are more than enough. Though it all depends on what you are trying to designate with the reference. In our group, even when we are calling in artillery fire missions, we generally still use 6 figure, because we like to adjust fire, with the accuracy of the maps, generally using more detailed coordinates just eliminates that part of the fun. That said, trying to describe a non descript building to someone who you want to lase the building for you, there could be half a village within a 6 figure reference. We may even only use 4 figures if trying to quickly describe where on the map we looking. "Sorry where did you want to have the landing zone" "Grid 07 07 Just west of Novy Sobor. @Rattus, square metres is different to metres squared. An area that is 100m by 100m is 10,000 square metres, or 100m². 10,000m² describes an area of 10 km by 10 km Above is from the link below. http://simple.wikipedia.org/wiki/Square_metre So Pteradon generally for the majority of Arma players anything more than 6 is not really required for how we play and what we emulate in game. That said if you have somebody who creates a J-Dam addon, you would need a minimum 8 figure reference for the pilot to program in otherwise you are just aiming at half a village.:eek::D

Ok this is just an adaptation of Xeno's code in the link in a previous post of mine. Not tested on a Dedi. Just quickly tested local. If you are using revive or respawn you will loose all your gear if shot while swimming unless they are set to giving you the gear you had at the start. Place this in your players init line actionId = this addAction ["Secure Gear", "SecureGear.sqf", ["", 8], 1, false, true,"", " _target == player"]; SecureGear.sqf _p = _this select 0; weapons = weapons _p; magazines = magazines _p; removeAllItems _p; removeAllWeapons _p; _p removeaction actionid; actionId = _p addAction ["UnSecure Gear", "UnSecureGear.sqf", ["", 8], 1, false, true,"" , " _target == player"]; UnSecureGear.sqf _p = _this select 0; removeAllItems _p; removeAllWeapons _p; {_p addMagazine _x} forEach magazines; {_p addWeapon _x} forEach weapons; _primw = primaryWeapon _p; if (_primw != "") then { _p selectWeapon _primw; // Fix for weapons with grenade launcher _muzzles = getArray(configFile>>"cfgWeapons" >> _primw >> "muzzles"); _p selectWeapon (_muzzles select 0); }; _p removeaction actionid; actionId = _p addAction ["Secure Gear", "SecureGear.sqf", ["", 8], 1, false, true,"" , " _target == player"];

Plastic container/Plastic bag was just something to give meaning to the action. You could say secure gear before swimming, So you don't lose every thing. Visually can't help you. Unless you use a boat instead ;) More seriously, possibly you could get fancy with using the attachto script to pin the weapon to your back?

Firstly nice looking adon Bon. If you wanted to get a little more realistic, here is how a very basic fire mission would be called. First Initate a Fire Mission Gun Battery (Callsign) this is Forward Observer (Callsign) Fire Mission Over Grid 112 111 Altitude 146 Direction 180 Troops in woods 1 round HE over Ok so the grid is where the target is. Altitude is the height of the target. Direction is the angle from the forward observer to the target. Once the first round has landed you can then adjust fire. Usually the most basic form is Add Drop Left and Right, all relative to the Forward observers perspective. This is why the direction value is included in the call. That way if the first round falls inbetween the target and the FO and slightly to the left the adjustment would be Add 100 Right 50 or the like. Once the forward observer is confident he is on target you would call for Fire for Effect, where all guns in the battery would fire. Bsoii6d58vc Ignoring the carry in the vid does have an adjustment call. Here is a link of an excel calculator I did to use with Jones artillery mod. It wouldn't work ingame as it calculates all the solutions using massive numbers of calculations, but you might find it useful as a reference to what information is required for your dialog. It would at least contain the formulae for calculating the adjustments relative to the Forward Observer. If you were being proper the Battery radio operator would be saying everything back to you to ensure all inforamtion is correct. http://www.armaholic.com/page.php?id=2892 Would be nice to have something realistic in game for calling for fire. Hope this helps. Another quick vid. AyGi7-2UhnI Here is a Wikipedia entry showing a simple fire mission comms. http://en.wikipedia.org/wiki/Fire_discipline

Depending on where you are calling this, _nul is a local variable and is alright in a script. If you were calling it from a trigger it has to be a global variable, so cannot start with _ If you don't need to pass anything then exclude the this component which would need square brackets if it was needed anyway. So from a trigger nul = execVM "bomb.sqf" From a script you could use _nul = execVM "bomb.sqf"

Don't know anything re intro's, but if you create an object I used an ammocrate, place this in the init line this setPos [ getPos this select 0, getPos this select 1, (getPos this select 2) +80] Call it lookhere In the D30 name it gun1 create a trigger and in the activation gun1 dowatch lookhere When the trigger is tripped the gun will look up at the ammo crate as it is placed really high. The ammo crate objects won't fall either. Hope that helps.

All I do which I found somewhere in these forums is either. Create a trigger Civilian Present once Condition this and isserver Activation GRIM_CivKilled = 0; publicVariable "GRIM_CivKilled"; {_x addeventhandler ["killed", {GRIM_CivKilled = GRIM_CivKilled + 1; publicVariable "GRIM_CivKilled"}]; } foreach thislist; Make sure there are no animals in the trigger area, an this will add an event handler to each civilian that when killed adds 1 to the public variable GRIM_CivKilled. Easist way to add to a whole town of civs. As well you could just add this to individual civilian init lines. this addeventhandler ["killed", {GRIM_CivKilled = GRIM_CivKilled + 1; publicVariable "GRIM_CivKilled"}]; Easist way to add to individual civs. Both will work in the same mission as long as they are applied to seperate groups. Then create another trigger none present once Condition GRIM_CivKilled > 5 Activation tskObj8 setTaskState "FAILED" In this case I have it as after more than five civilians have been killed it registers the task as a fail. You could put anything in the activation to register the failure, I use the tasks system, where I setup the task as being a sucess for the startof the mission and it will only change to a fail here. You could also set multiple levels of failure with more triggers that are set to different numbers killed, starting with a handslap, right up to informed you are to be court marsheled and hung for your crimes against humanity. From the variables pos credit to someone named GRIM?

Ok just looking at this a different way, haven't tested or anything, and not sure how it would go with the backpack of ace. What if you adapted these scripts to create a pack gear into waterproof plastic bag/container script using an add action. Then swim your river, after getting out of the river have another addaction to take your gear out of the imaginary plastic bag and rearm? http://forums.bistudio.com/showthread.php?t=76731&highlight=save+gear Just a thought.

I haven't played with these for a while, but I think the * cos component dictates the side to side. If I am wrong, which wouldn't be hard concidering how tired I am at the moment! Have you tried using the modeltoworld command? http://community.bistudio.com/wiki/modelToWorld

If you use the enableSimulation false will stop the bouncing, but then i becomes impossible to exit or enter the vehicle so I am not really sure if this is helpful. I used it for getting a deck lift to move up and down with a jet on a LHD, though had issues in MP with it and scrapped the idea. enableSimulation was the only way I found to stop the bouncing. I hope it at least points you in the right direction. Edit: Ok just did a quick test in game by attaching a helicopter to a humvee, but I had off set the heli about 30m up. The heli was perfectly smooth. Maybe in your script have the object you are attaching to at ground level so that the two objects are not "colliding" which is what causes the bouncing. Then alter the height of the offset to lower, then after raise the heli to a safe height to detach and fly away. this attachto [c1, [0,0,30]] Above is what I placed in the heli init to test. would need to tweek the attachto moment so not to cause a big jump in position when initially attaching. Hope this helps.

If you are refering to Norrins script from http://forums.bistudio.com/showthread.php?t=73630&page=2 then the scripts are to be located in a sub directory of the mission directory. Directory Name = mountOnC130 nul = [this,"car"] execVM "mountOnC130\mount_vcl_init.sqf"; As you can see from the call to the script above.

Try using a Trigger with the seized by option. http://community.bistudio.com/wiki/trigger. Below is how I generally use them, but the same principal can be applied to your problem. The hardest part is playing with the timeout values so that the trigger fires before your side is completely hammered. I use these all the time to trigger when an area is dominated by the player team generally. It is great because you never have to go searching for that last survivor. Also the team still have to be careful because even though they have "secured" the area, it doesn't mean there is one enemy lurking or hiding still.

nul = [this,"M119"] execVM "mountOnVcl\mount_vcl_init.sqf"; By the variables passed. In this case the script command is place in the vehicles init line. So "this" is refering to that particular vehicle, the second parameter is what the script looks for to carry. Note different objects have different positional requirements meaning you would have to adjust the attachto offset in the mount script. I looked at this a while ago, but can't find the scripts atm. If I remeber Norrin uses a variable to save the current state of the script. _vcl setVariable ["NORRN_mountOn_vcl_pos0", [false, _toAttach], true]; I believe this was it. My "bandaid solution was to create a second script, where I changed NORRN_mountOn_vcl_pos0 to NORRN_mountOn_vcl_pos1 in the second script. Not very elegant but created two positions on a truck. Though I am going by memory here so could be off the mark!

From here http://forums.bistudio.com/showthread.php?t=86016&highlight=artillery&page=3 Sorry for the slow reply.

Thanks FreeFire, very nicely done! Will be definately recommending this to our guys!

I created this script for a dom mod I was playing with. Though it doesn't have anything to prevent you from jumping out at to low or on the ground. You die if you choose this while on the ground. // HALO action By [ZSU]Blake //www.zspecialunit.org // Place this in the aircraft to add a seperate HALO menu item. //null = this addaction ["HALO","Halo.sqf","",0,False,True]; _pln = _this select 0; _plyer = _this select 1; _plyer setPos (_pln modelToWorld [0, -12, 0 ]); [_plyer, (getpos _plyer select 2)] exec "ca\air2\halo\data\Scripts\HALO_init.sqs";

Gh0st are you using the carrier script, which creates the carrier for you. I was playing with a mission, and tried to use this, but all the vehicles and players I placed on it would fall through at mission start because they would get created before the carrier. You can either try the addon version as the LHD pieces should be created at the same time as the other objects. What I did though was to hand piece the LHD together (painful yes) so that I didn't have to organise a new addon to be allowed on the server. That solved all the falling through issues. Otherwise you would need to place the vehicles etc elsewhere and move them onto the LHD after the script has finished?

Thanks shk, that was the right path to fix this. I have got it to work on our dedicated server, though sometimes the whole rig points north when loading. But the Gun always loads right and unloads flat. Might look funny on steep inclines didn't test to be honest. I usually slightly raise the gun barrel before loading to make it look better. // mount_vcl_init.sqf // © JUNE 2009 - norrin (norrin@iinet.net.au) /* Name playable units and vehicle in the editor Put this in the init line of the vehicle in the editor: nul = [this] execVM "mountOnVcl\mount_vcl_init.sqf"; */ _vcl = _this select 0; _typeOfVcl = _this select 1; _c = 0; _load = _vcl addAction ["Load bike on truck", "TankTow\mount_vcl.sqf", _typeOfVcl, 0, false, true]; _unload = _vcl addAction ["Unload vehicle", "TankTow\dismount_vcl.sqf","", 0, false, true]; _toAttach = objNull; _vcl removeAction _load; _vcl removeAction _unload; if (isServer) then { _vcl setVariable ["NORRN_mountOn_vcl_pos1", [false, _toAttach], true]; sleep 2; }; while {alive _vcl} do { if (!((_vcl getVariable "NORRN_mountOn_vcl_pos1") select 0) && _c == 0 && count (nearestObjects [_vcl, ["man"], 10]) > 0 && count (nearestObjects [_vcl, [_typeOfVcl], 10]) > 0) then { _load = _vcl addAction ["Attach Gun", "TankTow\mount_vcl.sqf", _typeOfVcl, 0, false, true]; _vcl removeAction _unload; _c = 1; }; if (((_vcl getVariable "NORRN_mountOn_vcl_pos1") select 0) && _c == 1) then { _unload = _vcl addAction ["Release Gun", "TankTow\dismount_vcl.sqf","", 0, false, true]; _vcl removeAction _load; _c = 0; }; if (count (nearestObjects [_vcl, ["man"], 10]) == 0 || count (nearestObjects [_vcl, [_typeOfVcl], 10]) == 0) then { _vcl removeAction _load; _vcl removeAction _unload; if (!((_vcl getVariable "NORRN_mountOn_vcl_pos1") select 0)) then {_c = 0}; if ((_vcl getVariable "NORRN_mountOn_vcl_pos1") select 0) then {_c = 1}; }; //hint format ["%1", (_vcl getVariable "NORRN_mountOn_vcl_pos1")]; sleep 0.5; /* if(speed _vcl >= 20 and _c == 1 ) then { _vel = velocity _vcl;_dir = direction _vcl; _speed =5.3; comment "Added speed"; _vcl setVelocity [(sin _dir*_speed),(cos _dir*_speed),(_vel select 2)]; }; */ }; if (!alive _vcl) exitWith {}; // mount_vcl.sqf // © JUNE 2009 - norrin (norrin@iinet.net.au) _vcl = _this select 0; _caller = _this select 1; _typeOfVcl = _this select 3; _dir = getdir _vcl; _mountVcl = objNull; _blogs = 0; _c = 0; globaldir1 = 0; if (count nearestObjects [player, [_typeOfVcl], 20] > 0) then { _mountVcl = nearestObjects [player, [_typeOfVcl], 20] select 0; }; if (vehicle _caller != _caller) then {_caller action ["GetOut", vehicle _caller]; sleep 1}; if (!((_vcl getVariable "NORRN_mountOn_vcl_pos1") select 0)) then { globaldir1 = getdir _vcl; _vcl setvehicleinit "this setdir 0;"; processinitcommands; _mountVcl attachTo [_vcl,[0,-6.4,-1.2]]; _mountVcl setvehicleinit "this setDir 180; this setVectorup [0,-0.15,1];"; processinitcommands; _vcl setvehicleinit "this setdir globaldir1;"; processinitcommands; sleep 0.1; _vcl setVariable ["NORRN_mountOn_vcl_pos1", [true, _mountVcl], true]; }; if (true) exitWith {}; // dismount_vcl.sqf // © JUNE 2009 - norrin (norrin@iinet.net.au) _vcl = _this select 0; _caller = _this select 1; _mountVcl = (_vcl getVariable "NORRN_mountOn_vcl_pos1") select 1; _vclDir = getDir _vcl; if (vehicle player == player) then { detach _mountVcl; _mountVcl setvehicleinit "this setDir 180; this setVectorup [0,0,0];"; processinitcommands; _vcl setVariable ["NORRN_mountOn_vcl_pos1", [false, objNull], true]; }; if (true) exitWith {};

@NouberNou My first response One reason why you shouldn't post stuff when really tired! The inner loop is actually emulating the projectiles path. deltat actually specifies the change in time between reading positions of the flight. The smaller value you have in deltat will generally give more accurate results. One thing you could try is to make the value of deltat larger until the accuracy drops off too much. Larger values mean the emulation process takes less time. Eg double the time jump, halve the number of calculations.

In which parts, as far as I know we have yet to have a problem with the BIS arty module? Except remembering to add a HE mag for the MLRS for some reason which the other arty pieces don't require? I would like the ai to move after a HE barrage though, rather than keep standing there. I might have to look at creating a trigger after a barrage with a random move for all units inside. Though that pos will stuff any existing waypoints up? Will have to investigate. Yep that is the real hog there, would be much faster using a system of halves(can't think of the real name atm). Where you select half way and see which half is correct then half that etc until it is refined down to the right value. May look at it over summer. That would reduce the amount of calculations massively.

Sounds cool look forward to seeing it. I must say my algorithms could be improved to reduce the total amount of calculations, I know they are not very effient, but I was prototyping and haven't got the time to improve on them, or the energy tbh.

To CarlGustaffa, Sorry to be honest at the moment to much to try and answer properly (just home from work after horrible day!). Quickly though, re ai arty, and my scripts. One thats why I at least like the framework modular method, keeps a lot of the important stuff away from having to redo. Also by making the rounds fly from the arty unit to the target, as long as your ai are not just holding a position and moving, looks alright. Re against real players, I generally keep the amount down, surviving massive barrages also as unrealistic I think. Though surviving a small harrassing fire still gives real emersion. One it makes your team keep their spacing. I think though have no proof that the 81mm mortar rounds are less powerful than the M119 105mm rounds in game, to lessen the impact on players? Re ai FO, that is hard, I have searched for a way to get the ai to keep using the binoculars but have yet to find anything other than fake animations that take the ai totally out of the ai. The best I found was I could get him to intermittently use his binoculars that a sniper could possibly pickup on. I too would love a way to get them to focus with binos, or a radio handset animation or the like. Re player arty. If you want really real like try using Jones artillery and use my excel program to calculate the trajectories. What we do if we only want to be half way there is to use the built in BIS arty module use the target cursor. I have mapped my joystick for aiming the guns, and use the map screen to get accurate bearings on where I am aiming the gun. Then we use communications to call in intially 6 figure grid references, we don't use markers. Then call adjustments from that. Generally instead of calling adjustments reletive to the FO we correct them and calll them as North south east west for ease while still getting the sense of using arty realistcally. If you don't want to even use players on guns, we have used the BIS artillery module to call in arty, but with a twist. An FO calls for strikes back to one of the leaders who then calls the arty using the click on map. That way someone is not stuck on the guns all the time, but stops and recieves fire missions using grid references and corrections which is the best part, we make sure no calls reference markers etc only grids or adjustments, our group also doesn't have map markers on, so unless the FO has a gps he needs to work out where he is and where he wants the rounds.