TJ_au

Is there a more elegant way to do this. I tried the first method but find it doesn't register quickly enough. However the AI respond almost immediately by lying down. There must be a way of detecting the AI change of state?.

tried this:- rspl moveindriver he3 rsg1 moveinturret [he3,[0]] rsg2 moveinturret [he3,[1]] where he3 is a UH60 everytime the script gets to that point ArmA locks up and CTD.

The first one works well for what I'm trying to do. Thanks.

thanks... easy...

Hi, Does anone know the name of the second gunner position on the UH-60. Ie if I create one how do I move a guy into the second gunner position. thanks

Hi, Is there a simple way to tell if a group is taking fire. Not nessecarily bieng hit but bieng fired at?. Thanks

Fasad, thats why I did the experiments between 500-1000m. The time for 1000m is 15+ seconds I can't believe the scripts would be out by 25% in time especially when I'm watching the explosion of the item hitting the ground.

Donnervogel, nice work on the plotting. However i think the time frame on that test and the distance the results are viewable to doesn't prove it. The flight of the round to the distance apparent in the image would be maybe 0.5 seconds. You're not going to notice the difference between 7.35 and 9.8m/s over that time frame. What would be interesting is if you could do the same test from the top of one of the tall mountains (firing with 0 elevation to the shot) and look at the difference between the 2 traces at the end of the flight rather than the begining.

using a looped script that looks for the object height to go below 1 m. I take the time at the creation and the time at the impact and the difference is the fall time. I tried this with objects ranging between 500 and 1000m above ground. Thing is I got consistant results which tends to reinforce the findings. Doing this from these sort of heights the possible delay on the script executing shouldn't effect the results also. Ie on a fall of 20m the 0.5 second script update time could possible effect the timing, as the fall distance gets higher the 0.5 second script update will have very little impact on the timing.

I tested it by creating objects at set heights above the ground then timing how long they took to fall and comparing it with a predicted fall time. the equation I used for predicted fall time was PT = sqrt((2*height)/gravity) which is a standard fall time prediction equation (to the best of my knowledge). To get predicted time to match fall time I had to use a value of 7.35 for gravity. This was done with streamlined objects such as bombs and rounds so that air resistance wasn't a major factor.

Gday, Been doing some experimenting and charting and there appears to be a major error in the speed of gravity in ArmA. This might be whats responsible for some of the ballistic wierdness. Using a couple of tests and ArmA seems to use a value of around 7.5m/s for gravity which is about 25% below the 9.8 - 10m/s that real gravity has. This seems a bit of a glaring error and is odd that such a mistake should be made.

Try setting them to fly in at a higher altitude. I think a lot of the problem comes from 2 things. 1. The aircrafts flyinheight is relative to the terrain so as the terrain height changes so does the aircraft. This causes the long and short problem with bombs 2. The aircraft tries to maneuver to avoid high terrain etc which gives you lateral variance on the bomb run. I've had some successes trying to do this with aircraft with a 500m flyinheight and on a careless order.

thank you

I'm mainly trying to make a way of restricting the use of a radio trigger to a side. I thought there was a way of finding out in OFP.

Excellent. Thanks