ACE » A.C.E. 2

Should be a deceleration process, preferably slightly random to avoid stupid stunt like behavior for players. By random I mean "a parachute doesn't deploy equally each time", meaning you always want to employ at safe altitudes rather than at the absolute minimum.

IIRC the minimum safe distance is used IRL is around 1200 ft. Ill have to confirm that with my HALO buddy though.

I have been able to land with a normal combat load (less than 25kg) by opening the chute at 60m, but even then I landed a bit too fast.
With the current model, as long as a character is falling at around 48m/s and the chute is opened at 80m, there's just enough space to decelerate and maneuver a little on a flat surface, which should not be that unrealistic.

Maybe what Spyder meant whas that there are people jumping with the Mc-5 at 30m and managing to open the chute in time?
If that is the case, it could be made so that the Mc-5 requires a minimum speed to open properly.
More information would be useful for the Devs, though.

No I think he means in response to this video

Ukrainian HALO Jump from Battleday #4 ;)
http://www.youtube.com/watch?v=KCkpO_8AmhU
Watch it in HD!

You need to have the time it takes to deploy the chute, then the time it takes to go from the speed your were falling at to the speed you need to be at to land uninjured. Plus you have to take into account that ArmA has a worthless wounding system. I doubt you could land when you chute just opened at 80m.

One thing to consider also, is that, your main can sometimes fail to open, such as if you were falling too fast. Which is why HALO parachutists pop at around 1200 FT, it gives them enough time to activate and deploy their reserve parachute.

As far as the bare minimum safe, as in, if I pop below this I'm going to break my legs, is going to be around 600-800 FT, especially considering that, mostly everybody doing this in Arma2, is going to be loaded down with equipment and not have anything on them.

I mean, a static line jump at 600 FT with 80 lbs of gear on you is going to be a really rough landing as my knees will tell you.

Who knows if this can be scripted in some sort of fashion though, I'll try and check it out this weekend.

I see what you guys are talking about: he opened the chute at less than 40m and managed to land safely, which is absurd.
Have you noticed, however, that when the player opened his chute, the indicated altitude changed from >40m to around 120m?
Apparently when opening the chute, the character model is teleported several meters upwards, allowing him to survive a landing where he would have died.

New system is great, but I understand the exploit here. Tis a wee bit frustrating at times. Adding a small amount of randomness to the chute opening would be a reasonable solution in my mind. S2's information is pretty much spot on. I have a set of less than happy knees to support these claims myself. ;)

A quick fix might be to have the chute auto deploy at ~1000m. Then not allow the player to cut the chute.

A thousand metres might be a tad much considering S2 says you can deploy at 600 feet (~200m)

Quote:

Typically it will be between 2-3000 ft AGL.
Ballistics of the chute require approx 300 ft for full deployment of the chute.
Minimal opening is 1500ft and still allow time to deploy a reserve chute, should it be necessary.
Static line drops are usually 3000ft for trainees and 1500-2000 for experienced jumpers,
Lowest allowed for combat jumps is 800ft AGL
Source(s):
Retired AF SNCO, Instructor Flight Engineer,
Dropped many HALO personnel

As a fast workaround...

Pull Rip Cord is only available above 200m, Cut Chute above 300m.

Yeah Im so used to using meters, meant ft tho

Instead of removing the "pull rip cord" under the hight of 200m,
why not put in a random delay of a few seconds after pulling the cord. That way you might drop 200m before you can land safely.

Removing the "Pull rip cord" under 200m I think is a bad workaround.

Thanks for your feedback. Not a bad idea. That is probably how we intended to do for the final solution. However, what we did was a quick fix.

Another suggestion - if possible.

Limit the deceleration of the parachute. That way a person opening low can cheerfully plow into the ground.

Agent_Wolf wrote:

Instead of removing the "pull rip cord" under the hight of 200m, why not put in a random delay of a few seconds after pulling the cord. That way you might drop 200m before you can land safely.

Removing the "Pull rip cord" under 200m I think is a bad workaround.

I almost did this originally, but opted not to because of gameplay reasons; due to BIS's "fixes" with the functions in A2, sometimes script execution can be delayed when lots of other scripts are running. It would be a dumb nuisance if it ever caused you to die. :\

Evil Echo wrote:

Another suggestion - if possible.

Limit the deceleration of the parachute. That way a person opening low can cheerfully plow into the ground.

this is already happening actually (or at least it was when I implemented it), but back in Feb/March when I did it the wounding module was still W.I.P. so I couldn't implement damage based on impact speed. That's why you can always land safely... damage simply isn't applied at the landing.

TY for the update HJ, speed-based damage would go a long way to help out. Having a ripcord disappear feels clunky and unrealistic.

I tested this last week and noticed that if I pulled my rip chord around 280m, I never landed properly. Sometimes I died which I would of course expect, however sometimes I didn't die and I got stuck in the ground with no avatar. I checked the ATL of my body and it was every decreasing -100, -200, -300 LOL. Thus I had fallen through the earth and I was still falling. LOL.
Still finding the time to work with HomerJohnston on that.

did some testing and digging with Vipermaul this evening - I decided on a couple of things:

1) diag_ticktime is probably not a good command to use for anything except something which relies on time external from the game - example; you could use it to determine FPS, or you could use it to determine how much the sun has rotated outside your window. But you should never use it for a gameplay-based-delay such as reload-time, how long your parachute takes to open, etc... Reason: if the gamespeed doesn't stay consistent, then you should want your gameplay-based-delays to adjust accordingly. "Sleep" will adjust accordingly, keeping the game events consistent.

Also quite interesting: using diag_ticktime will continue to increase and allow scripts to loop even while the game is paused - and it generally caused some strange calculation (rounding?) issues in the parachute steering which caused view-jittering issues, so I don't think it "talks" accurately with the game.

2) after replacing diag_ticktime with traditional Sleep commands, there is still issues when lots of other scripts are running (full missions with DAC, etc). The steering script only loops a few times per second, which causes it to break and cause larger-scale view-jerking, different from diag_ticktime. I think this boils down to the shitty new ArmA2 scheduler, (I'll try not to complain too much about that thing!), so I am going to throw the scripts into an FSM and see if that brings things back to the way they should be. Hopefully we'll know this by Friday, or even tomorrow with some luck.

Hopefully more news in the coming nights...

aww, you broke it....

It was working smoooothly until you added the 'chute-open-realism' it really does stutter now -
I'm very disappointed ( I HALO a lot you see) truth is I liked opening my chute below 100

One request tho. Is it possible to add that when we eject we are well clear of the aircraft? say 10 metres or something?
We get injured a lot - plus I can put static C130's on uneven terrain. Because at present I have to find level terrain for 'attachto C130's' to avoid injury. Cheers.

@palyarmerc, the chute open thingie has exactly nothing to do with the problems HALO is/was facing. It'll be fine with ACE 1.3.0

No more reports since a month, supposing issue is fixed.