blakeace

Try this, Gives an brief insight into CAS, artillery etc. http://www.fas.org/nuke/guide/usa/doctrine/dod/t0302060.pdf

Cheers will have a look at that.

Yep exactly as I read it thanks, though as I read it I believe his main issue is that Ok so I placed below in the init area of a vechile (hummer) HANDLE = this addeventhandler ["HandleDamage",{diag_log text format ["T=%1 : %2", time, _this];_this select 2;} ]; Unlike the "infantry object" the results from the handler were All values of the component damage recorded, and not applied to the object were very low. So if you added them all up and applied them via a setdamage they shouldn't kill a vehicle in three shots. Is it only one specific vehicle or all? Try as AZCoder suggested with the sidechat to see all the damage values you are recording then applying as damage in the script.

I haven't really used this, but when I first was reading about this event handler I remember in the description that one shot could result in multiple hit "events". Below is quoted from the below link in the BIS wiki. It shows two shots at a soldier, once head, once torso. Overall it results in 5 hit events for each shot. Looking at the damage values some are actually greater than 1. Looking at your script it looks like you are adding each of these up. Not sure of the difference when it is a vehicle you are shooting. But if each wheel can be damaged say upto 1 then a couple of shots into the wheel could result in a large accumulation of damage values. I'm not at my arma machine to test sorry. You prob need to look at those damage values and apply them differently. http://community.bistudio.com/wiki/ArmA_2:_Event_Handlers#HandleDamage

I'm using a Eulers method to try and predict the impact point, factoring in a constant air friction coefficient. Similar to how I was calculating the artillery shells with my excel calculator. When I use 9.8 for gravity and 0 air friction the bombs land way long. The closest approximation I have achieved so far are the earlier values I posted. Though with values that impact correctly at lower altitudes result in long shots at higher altitudes. Looking at the results of dropping bombs from a stationary platform (thanks Maturin). Which from above looks similar to how those base jumpers with the wing suits, maybe there is a small lift calculation that is translated into a forward thrust? To get impacts at higher altitudes correct currently involves reducing the air friction coefficient, which I imagine would be similar to a higher coefficient, that has an opposing force that is increasing its forward velocity. The above is just guessing mind you. Below is a video of the script doing the calculations, though very much wip. You can see on the first run at a higher altitude the shot is a little long, though when performing a low level run it calculates quite accurately. Note bomb release was calculated by the script so that removes human timing on hitting the fire button. Lj7YoKWquc8 Edit: Ok I wrote and quick and dirty acceleration monitor for the bombs. Then added it to a hind, climbed to a height and released a bomb while in auto hover mode. Initial acceleration is straight down at @ 16m/s^2. Vert accel then drops to basically zero, while a forward accel increases to @ 5m/s^2. Once the forward accel stabilises at @5 the vert component then drops again to around 9-10 m/s^2. These then slowly drop as I assume air resistance play on then. I don't pretend to be a physics whiss, so here is the code I used to test for others to confirm. This would imply I believe that the grav is actually around the 9.8 mark, and it is this other component that changes things in my calculations as I am not taking it into consideration. It does seem to be some sort of lift that is converting into a forward component by the looks of it. this addEventHandler ["fired", "Bomb1 = _this select 6"]; SR1 = [] spawn { waituntil {!isNull Bomb1}; _dt = 0.01; _oldvel = [0,0,0]; while {true} do { _vel = velocity Bomb1; _accx = ((_vel select 0) - (_oldvel select 0))/_dt; _accy = ((_vel select 1) - (_oldvel select 1))/_dt; _accz = ((_vel select 2) - (_oldvel select 2))/_dt; hintsilent format ["%1 %2 %3" , floor _accx,floor _accy,floor _accz]; _oldvel set [0, _vel select 0]; _oldvel set [1, _vel select 1]; _oldvel set [2, _vel select 2]; sleep _dt; }; };

If i place this in an initialization area of an object in the editor. SPR1 = [this] spawn { _dude = _this select 0; _i = 112; _dude setVariable ["index", _i]; hint format ["Var is %1", _dude getVariable "index"]; }; Results in "Var is 112" Now if i place this in SPR1 = [this] spawn { _dude = _this select 0; _j = []; _i = _j select 0; _dude setVariable ["index", _i]; hint format ["Var is %1", _dude getVariable "index"]; }; I get "Var is <null>" So it could be to do with where and how you are assigning _i it's value. This might help if it is an array issue. http://community.bistudio.com/wiki/Array Good Luck Blake

Same with a harrier hovering. Never noticed this in any of my experimenting, though I will admit I never really looked at a stationary delivery platform. Values from my previous post still seem ok if the vehicle has a reasonable forward velocity. Eg the hind at @130 was tested and the bombs impacted as predicted.

From my experiments with the ballistic behavior of the unguided bombs, I have found using a gravity value of 5.2, and the drag coefficient at about 0.000275 yields reasonably close prediction to their flight path. Edit: My testing was done prior to the latest 1.56 patch.

Try writing your sleep commands like sleep (5 + (random 10)); This will ensure the value component is evaluated fully first before applying that value to the sleep command. At the moment arma is evaluating sleep 5 before evaluating the random component. You can confirm this by placing the below in the player init field. SR1 = [] spawn { while {true} do { hintsilent format ["%1",time]; sleep (5 + (random 10)); }; }; Then try it with SR1 = [] spawn { while {true} do { hintsilent format ["%1",time]; sleep 5 + (random 10); }; };

Try copying and pasting the code below into one of the vehicles initialisation area in the editor. Add a marker named cc which will mark the centre point of the area the convoy will patrol. Alter the value of _PatrolD to set the patrol areas diameter Deletethe line (leader _grp) setSpeedMode "LIMITED"; if you wanted the vehicles to travel at full speed. You could add a marker named tt if you wanted to check the scripts destinations while tesing. This could also be easily coverted into and sqf file for neatness, this was just my quick and dirty solution for a similar effect. Hope it helps. nul1 = [this] spawn { _car = _this select 0; _grp = group _car; _grp setFormation "COLUMN"; _centre1 = getmarkerpos "cc"; _PatrolD = 20000; _destfound = 0; private ["_drop","_dest","_Point"]; while {alive (leader _grp)} do { _destfound = 0; while {_destfound == 0} do { _drop = [( _centre1 select 0) + (random _PatrolD/2) - _PatrolD/4,( _centre1 select 1) + (random _PatrolD/2) - _PatrolD/4,0]; _dest = _drop nearroads 50; if (count _dest > 0) then { _destfound = 1; _Point = getpos (_dest select 0); (leader _grp) move _Point; (leader _grp) setbehaviour "SAFE"; (leader _grp) setSpeedMode "LIMITED"; "tt" setmarkerpos _Point; }; sleep 1; }; while { (leader _grp distance _Point) > 20} do { sleep 60; (leader _grp) move _Point; }; };};

A link to the stand alone version of the one in ACE2, as refered to by Hank. http://www.armaholic.com/page.php?id=9060&highlight=RAV+LIFT

while {alive player and name player == "Blakeace"} do { _list = nearestObjects [player, ["CAManBase"], 500]; sleep 1; for [{ _listpos = 0 },{_listpos != ((count _list) -1 )},{_listpos = _listpos + 1}] do { player reveal (_list select _listpos); sleep 0.05; }; }; No idea about the sphere class name?

Yep you could do that. I just used the spawn option as a quick copy and paste to see if this option was even viable to your mates specific eye condition. Note this option will only highlight one enemy at a time. Note I added a check for what your cursor is actually pointing at, so that if like me your mate likes an aiming deadzone then the target will always appear above any known targets he is actually aiming at or trying to track. Another possible tack that would play in with this style of script is utilising the reveal command on any objects within a certain distance from the player. That way it wouldnt matter which side you are playing for. Possibly using another script that checks for the nearestobjects of type CAManBase and reveal them. (Not verified though). Hope this helps. if (isDedicated) exitWith {}; _targetMark = "Training_target_EP1" createvehicle [0,0,-100]; while {alive player and name player == "Blakeace"} do { _pos = screenToWorld [0.5,0.5]; _enemyobj = player findNearestEnemy _pos; if ((player findNearestEnemy getpos cursortarget) == cursortarget) then { _targetMark attachTo [cursortarget, [0,0,2.2]]; } else { if (!isNull _enemyobj) then { _targetMark attachTo [_enemyobj, [0,0,2.2]]; } else { detach _targetMark ; _targetMark setpos [0,0,-100]; }; sleep 0.001; }; };

nul1 = [] spawn { _targetMark = "Training_target_EP1" createvehicle [0,0,-100]; while {alive player and name player == "Blakeace"} do { _pos = screenToWorld [0.5,0.5]; _enemyobj = player findNearestEnemy _pos; if (!isNull _enemyobj) then { _targetMark attachTo [_enemyobj, [0,0,2.2]]; }; sleep 0.001; }; }; Maybe use the players name to ensure it only runs for him like above? The reason I used nearest enemy is I am unaware of an alternative that doesnt involve some fancy coding to, one find your sided, then determine the enemy then ist them all. Maybe if you only play as west side you could use nearsest object searching for soldierEB objects? Though I am not an arma guru so it doesnt mean there isnt an easy way.

Just a quick script to allow you to at least test the suitability of this approach with your friend. It will place the target above the nearest "known" enemy closest to the point in the world the centre of the screen is currently over. So looking in the sky may have not reveal the desired unit. nul1 = [] spawn { _targetMark = "Training_target_EP1" createvehicle [0,0,-100]; while {alive player} do { _pos = screenToWorld [0.5,0.5]; _enemyobj = player findNearestEnemy _pos; if (!isNull _enemyobj) then { _targetMark attachTo [_enemyobj, [0,0,2.2]]; }; sleep 0.001; }; };

You could try using toarray and tostring. There is parseNumber as well. I was only using them to change strings around, but it would allow you to search through the string and pull out each element. You could then do a check with the unicode values to see if they are numeral types plus decimal point and minus sign to then convert into a number with parseNumber. Not tried it to this depth, but could be a solution for you. Or a start maybe. Hope it helps. http://community.bistudio.com/wiki/toArray http://community.bistudio.com/wiki/toString http://community.bistudio.com/wiki/parseNumber

Try http://community.bistudio.com/wiki/setVectorUp http://community.bistudio.com/wiki/setVectorDir as discussed here, http://forums.bistudio.com/showthread.php?t=85962&highlight=level+object or from the functions module as discussed here, http://forums.bistudio.com/showthread.php?t=88977&highlight=level+object

Don't know if this would help, we use it in all our missions to give a much more realistic feel when facing RPG's. It doesn't do anything in the sense of armour penetration, but affects the ability of the ai AT firer. Makes using light armour a lot more fun and emmersive. More near misses to give crews a chance to react. Though slow and close will still nail you generally! http://www.armaholic.com/page.php?id=8967&highlight=AT+ADJUST

To be honest I don't know what Beagle changed, but I copied his sensitivities and found it to be a really nice setting for my X52pro. http://forums.bistudio.com/showthread.php?t=103127

Thanks Beagle, changed as per your first post, I have an X52 pro and your settings are very nice!

By overlay I am refering to the use of displayctrl to add a GUI object. It is the system used to create the likes of dialogs etc. Here is a link to a tuit that Hendo made that prob is the easist way to get started. I haven't used these much more just played around with, but http://community.bistudio.com/wiki/User:Hendo:Tutorials:Display Below BIS dialog control page. Showing the different types that can be displayed including pictures. Note that one limitation is that arma can only disply one cutRsc and one titleRsc at a time. So whether something you create conflicts with something else? http://community.bistudio.com/wiki/User:Manny/Dialogs_%28Work_in_progress%29#Pictures So I am far from an expert with these so take the above with a grain of salt!:eek::D

Ok I'm no expert on eyesight, so whether this direction is even useful will depend on your friends specific condition. Przemek_kondor made a mission where you can adjust some sliders that manipulate the colorcorrection values. You could run this for your friend to see if there is a better setting for him? Then you could have a unit added to missions that has this(the derived values placed in a colorcorrection command) added to his units init. Would need to include an event handler if you use revive or respawn as well. http://forums.bistudio.com/showpost.php?p=1491732&postcount=18 If you need to actually highlight enemies, then some trial and error with some sort of overlay could be possible, though trying to find a nice balance between going from frustratingly hard to being to easy would be the issue. You would also need to consider line of sight issues which an overlay would probably not allow for. Hope this helps.

If you are injured, you will get a heal option. Try in the editor by setting your units health to less than full via the health/armour slider.

Remove the space character before the last double quotes. [c1,"USBasicWeapons_EP1"] call BIS_fnc_supplyDrop;

Use a PBO prefix file. http://community.bistudio.com/wiki/CMA:DevelopmentSetup http://forums.bistudio.com/showthread.php?t=85642&highlight=%24PBOPREFIX%24 What it does is use the source files, so that you can test update fix etc without needing to restart Arma after every change. Though files like your config.cpp can't be updated without restarting i think. You still need the pbo's, and you need to make sure your paths are setup correctly. Use the links above. Ensure you don't have -noFilePatching in your startup line as this disables the above to force arma to use the pbo's http://community.bistudio.com/wiki/Arma2:_Startup_Parameters