Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[WxTech]

I've raised this subject a while back...

It's so common as to be ridiculous that certain aircrew bail in pairs and thus have their chutes collide upon opening, then staying collapsed as the poor little silicon lifeforms plummet to their doom.

A particularly humourous example occurs for the TBD-1. The navigator and gunner always leap together, appearing to almost hold hands as they face each other. And of course dying in this last act of comradely mutual support when their chutes fail to open. 

This pairing reminds me of gun classes and their bulletscluster property which ties two or more bullets together. If there was a way to disentangle this bailing in pairs, or as an alternative to have a different chute opening delay so as to have some chance of separation and hence no collision.

Even when altering the position with respect to the plane where the bailing crew first appears, those tied together as a pair are relocated as a unit, thus gaining nothing for the effort.

Is there some way to grapple effectively with this stupidity? I plan to conduct some experiments...

[gunny0134]

I think this problem as a chronic problem in 1946, which must be solved.

I often see it when I'm doing a large Airborne operation or when the crews of bomber bail out, and that makes me so frowned upon.

I'm not in a position to provide a way to help, but I really hope this will improve.

Always grateful !!

[WxTech]

While looking at the paratrooper scene, in Paratrooper.class (B.A.T. 4.0) I see a scheme which controls the height above ground level (AGL) at which the chute opens. In brief:

- At 500m AGL and below the chute opens immediately.
- At 4,000m and above the chute opens at a random height AGL between 2,000m and 2,400m.
- When starting between 500m and 4,000m, the opening height envelope varies linearly with height at the low end between 500m and 2,000m, and at the high end between a bit over 500m and 2,400m. For example, if the paratrooper leaps out at, say, 2,400m AGL, his chute will open between roughly 1,300m and 1,600m, randomly determined.

The randomness that is applied ranges between a factor of 1.0 to 1.2. This means the lower altitude of chute opening for a given terrain height is limited to the calculated value; a random addition of up to 20% higher can occur.

These heights seem a bit on the high side. Certainly so for drops from high altitude over mountainous terrain. If the ground under the little silicone life form at the time of his jumping were to be 1,500m, and he hit the silk more than 2km above that ground, his chute would open some 3.5km ASL.

Because this algorithm is based on the height above ground, I think at least an extension of the chute opening floor to lower heights via randomness should be permitted. Instead of a 2,000m AGL hard floor for high alt drops, easily halving that to 1,000m makes sense to me. That is, increase the range of randomness in height over which the chute pops. Instead of a randomness range of 1.0-1.2, 0.5-1.0 is more appealing to me. Except, of course, for leaps at only 500m AGL and less, where opening should be immediate.

Is there any reason why my thinking is wrong? More regimented Falschirmjaeger behaviour is desired? Well, on that front drops from lower altitudes already have pretty restricted randomness that wouldn't cause too obvious a scatter in height at opening.

My thoughts here are more concerned with bailing aircrew or otherwise non-organized drops.

Anyone have thoughts? Are there any paratrooper mods I should be aware of? (This is an area I've not delved at all thoroughly into.)

[WxTech]

The code which sets the chute opening height is shown below. The original lines have been REM'd out with preceding "//" characters, and I've made some alterations. I have added notes which I'llexpand upon a bit here. In this first stab at it I've reduced the highest opening altitude AGL range from an envelope of 2,000m - 2,400m down to 1,000m - 2,000m. This 2:1 range linearly decreases with decreasing altitude, such that at 500m the range is 400m to 500m. (Below this the chute opening is as immediate as the timing permits.)

For the intermediate range of leaping height AGL between 500m - 4,000m I've devised two algorithms for the lowest (floor) and highest ( ceiling) limits at given height. This is to obtain a linear variation of differing slope for each so as to provide no discontinuity at the upper and lower extremes.

Paratrooper.Master():

Code: [Select]

public Master(Actor actor)
{
super(actor);
actor.pos.getAbs(Paratrooper.p);
float f = (float)Paratrooper.p.z - Engine.land().HQ((float)Paratrooper.p.x, (float)Paratrooper.p.y);  //f = height above surface
if(f <= 500F)
turn_para_on_height = 500F;  //original; no randomness is applied! Immediate chute opening is a must
else
if(f >= 4000F)
//                turn_para_on_height = 2000F;  //original; 2,000-2,400m with randomness (does not extend low enough)
turn_para_on_height = World.Rnd().nextFloat(1000F, 2000F);
else  //500 to 4,000m
{
//                turn_para_on_height = 500F + 1500F * ((f - 500F) / 3500F);  //original; ~500 to 2,000/2,400 (too high)
float floor = (1000F + 2000F * ((f - 100F) / 5000F)) * 0.395F;  //400 to 1,000
float ceiling = (500F + 1500F * ((f - 500F) / 3500F));        //500 to 2,000
turn_para_on_height = World.Rnd().nextFloat(floor, ceiling);  //400/500 to 1,000/2,000
}
//            turn_para_on_height *= World.Rnd().nextFloat(1.0F, 1.2F);  //original


[WxTech]

Another issue I have with our silicone lifeforms descending by parachute is this. When bailing at low altitude, the time it takes for the horizontal speed to drop to a safe level is ridiculously long. You've doubtless seen your pilot reach the safe terminal vertical fall rate after the chute has successfully deployed. But then it takes some silly amount of time for the horizontal drift to decrease to a safe level. If the human touches the ground at a horizontal speed above some threshold, it's guaranteed death. And stupidly so at that surprisingly low speed. Upon deceleration to a safe vertical speed, by definition the horizontal speed cannot result in a meaningful vector addition for then the chute must be still oriented well from vertical and still in the process of decelerating. Once the terminal vertical velocity has hes been reached, only in a serious wind would the person be in some danger. Our slowly descending human, having already reached terminal velocity under the chute, should no longer be subject to death via some silly horizontal drift.

I've only just now looked at the following snippet from Paratrooper.class. I have yet to determine the animation section identifiers, here as variable "st".  When st == 2, I think it refers to the period while the chute is in the process of opening. If so, during that time the X/Y velocity (in the horizontal plane, where Z is vertical) of the human is scaled more aggressively with a reduction factor of 0.01 per tick. At other stages in the animation, such as when the canopy is fully deployed, a scaling factor of just 0.001 is applied to slow the horizontal speed.

Now, this factor of 0.001 would seem to apply similarly for other stages in the animation. Such as before chute deployment, while the human is falling? I'm not yet sure on these details. It might be worthwhile to at least isolate the stage of the animation when the chute is fully open and the human is settling to the new, lower terminal fall speed. A somewhat more aggressive factor for slowing in the horizontal than 0.001 could then be tried. In this way the silly but deadly horizontal drift that persists for some time after the vertical speed has settled to a steady rate can be made a thing of the past.

Code: [Select]

Paratrooper.p.scaleAdd(Time.tickLenFs(), speed, Paratrooper.p);
speed.z -= Time.tickLenFs() * World.g();
if(st == 2)
{
if(speed.x != 0.0D)
speed.x -= (Math.abs(speed.x) / speed.x) * 0.01D * (speed.x * speed.x) * (double)Time.tickLenFs();  //original factor = 0.01
if(speed.y != 0.0D)
speed.y -= (Math.abs(speed.y) / speed.y) * 0.01D * (speed.y * speed.y) * (double)Time.tickLenFs();
} else
{
if(speed.x != 0.0D)
speed.x -= (Math.abs(speed.x) / speed.x) * 0.001D * (speed.x * speed.x) * (double)Time.tickLenFs();  //original factor = 0.01
if(speed.y != 0.0D)
speed.y -= (Math.abs(speed.y) / speed.y) * 0.001D * (speed.y * speed.y) * (double)Time.tickLenFs();
}


[WxTech]

In AircraftState.bailout() we have the following, which sets the position with respect to the bailout hook at which the bailing crewmember/paratrooper appears.

This line is the original, which has the starting position of 0, 0, 0 exactly at the hook. The remaining 3 values (one of which is randomly set to be between -45 and +45 degrees) set the initial direction the human moves away from the hook.

Loc loc = new Loc(0.0, 0.0, 0.0, World.Rnd().nextFloat(-45.0F, 45.0F), 0.0F, 0.0F);


This is a test I just did. I've randomly set the X and Y components both to be + or minus 4m distant from the hook, and the Z component (height) to be between 0 and -6m. This puts the jumper as much as SQRT(4^2 + 4^2 +6^2) = 8.24m away from the bailout hook.

Loc loc = new Loc(World.Rnd().nextDouble(-4.0, 4.0), World.Rnd().nextDouble(-4.0, 4.0),World.Rnd().nextDouble(-6.0, 0.0), World.Rnd().nextFloat(-45.0F, 45.0F), 0.0F, 0.0F);


Testing with the TBD-1, which I've mentioned has the two aft crew leaping simultaneously and nearly holding hands, now has those two guys sometimes start out with enough separation to have their chutes not collide and thus survive.

This does have the guys sometimes suddenly appear a bit of a distance outside their crate, which is a disadvantage of this position adjustment scheme. Particularly if one is making a movie using paratroopers.    I'll try some further experiments, tweaking also the emission vectors

[gunny0134]

This does have the guys sometimes suddenly appear a bit of a distance outside their crate, which is a disadvantage of this position adjustment scheme. Particularly if one is making a movie using paratroopers.    I'll try some further experiments, tweaking also the emission vectors

This means that unless the problem is fundamentally solved, it will be better to make a long shot of the video rather than a close-up.

But I think it would be better than watching the poor sight of two parachutes falling together endlessly without spreading them out...

[WxTech]

It seems that even for crew jumping as a pair at the same time, they are treated as separate entities nonetheless. A big contributor to the problem was the stock same minimum height for all chutes to open when leaping at lower altitudes. This caused a pair of crew to stay close together as they fell and then open their chutes at the very same instant. Almost a guarantee of the canopies coming into contact and hence death.

I've added some randomness for the height at which chutes open all the way down to the surface (the range of height randomness does decrease as the jumping-out altitude decreases.) Formerly I had retained the stock scheme whereby from jumping altitudes AGL from 500m on down the chutes opened after the same time interval passed after jumping (meaning a crew pair had their canopies open at the same instant). Now there's some randomness, so that a pair of crew have some chance of one popping his chute sooner, allowing some vertical separation to accrue before the second guy pulls his ripcord. That alone makes a BIG difference, with chute collisions being significantly reduced.

On top of that, just moments ago I've implemented a new scheme to apply an immediate slowing of the crew upon bailing, to simulate their being quickly slowed by the strong relative wind. (Think on how the bailing crew in IL-2 GB quickly fall back in the wicked slipstream.) I apply a bit of a randomness to this slowing, which further permits separation to develop between a crew pair. It looks good to see the boys slipping to the rear right away.

These measures should permit to bring the crewmember position at least much nearer to the hook, obviating my idea of applying a not-small random displacement that can put the crewman some distance outside the plane upon first appearance.


Looks like a solution has been found!

[WxTech]

I went back to the default (stock) starting position for the bailing crew, that being at the location of the bailout hook. At low altitudes, where the margins don't permit to wait a long time before opening the chute, there are some instances of crew pairs still having their chutes to touch and hence collapse. But the number of instances is very much reduced, to a degree satisfying enough to not feel I must introduce positional displacements from the start, thereby retaining the best behaviour for proper paratrooper drops (and cargo drops I should imagine.)

While I'm at it, here's the relevant part of AircraftState.bailout() which sets the starting position of the bailing crew and the velocity (taken from the plane's speed.) I keep the stock positioning, but leave here the experiment I tried in which a random positional offset was applied to each of the X, Y and Z axes relative to the ExternalBail hook. The 4 new lines take the plane's velocity vector, multiply it by a random value of between 0.85 to 0.95, and apply that reduced speed to the paratrooper.

Code: [Select]

try
{
Hook hook = actor.findHook("_ExternalBail0" + (i - 10));
if (hook != null)
{
Loc loc = new Loc(0.0, 0.0, 0.0, World.Rnd().nextFloat(-45.0F, 45.0F), 0.0F, 0.0F);  //original
// Loc loc = new Loc(World.Rnd().nextDouble(-2.0, 2.0), World.Rnd().nextDouble(-2.0, 2.0),World.Rnd().nextDouble(-2.0, 0.0), World.Rnd().nextFloat(-45.0F, 45.0F), 0.0F, 0.0F);  //experiment
hook.computePos(actor, actor.pos.getAbs(), loc);

Vector3d v = new Vector3d();  //these 4 lines are new code to apply an initial retardation to simulate the strong slipstream
v.set(aircraft.FM.Vwld);
double SpeedScale = TrueRandom.nextDouble(0.85D, 0.95D);
v.scale(SpeedScale);

// Paratrooper paratrooper = new Paratrooper(actor, actor.getArmy(), i - 11, loc, aircraft.FM.Vwld);  //original
Paratrooper paratrooper = new Paratrooper(actor, actor.getArmy(), i - 11, loc, v);  //to get paratroopers to start out slower than plane, falling behind in the slipstream
aircraft.FM.setTakenMortalDamage(true, null);
if (i == 11)
{
aircraft.FM.CT.WeaponControl[0] = false;
aircraft.FM.CT.WeaponControl[1] = false;
}
if (i > 10 && i <= 19)
EventLog.onBailedOut(aircraft, i - 11);
}
} catch (Exception exception)
{
/* empty */
} finally
{
/* empty */
}
if (astateBailoutStep == 19 && actor == World.getPlayerAircraft() && !World.isPlayerGunner() && aircraft.FM.brakeShoe)
MsgDestroy.Post(Time.current() + 1000L, aircraft);


[WxTech]

I should add that it looks much better to see chutes opening at different times/altitudes. Previously at lower altitudes the almost robotically regimented chute opening at the same altitude induced low-grade aggravation due to the unnaturalness. 

[WxTech]

Here's what I've settled on in Paratrooper.class as the determinant for the range of height AGL at which the chute opens, as a function of the height at the moment of jumping.

Code: [Select]

class Master extends ParaNet
{

public Master(Actor actor)
{
super(actor);
actor.pos.getAbs(Paratrooper.p);
float f = (float)Paratrooper.p.z - Engine.land().HQ((float)Paratrooper.p.x, (float)Paratrooper.p.y);
if(f <= 500F)
turn_para_on_height = f * World.Rnd().nextFloat(0.67F, 1.0F);
else
if(f >= 4000F)
turn_para_on_height = World.Rnd().nextFloat(1000F, 2000F);
else  //500 to 4,000m
{
float floor = (550F + 2000F * ((f - 100F) / 5000F)) * 0.475F;  //337 to 1,000
float ceiling = (500F + 1500F * ((f - 500F) / 3500F));        //500 to 2,000
turn_para_on_height = World.Rnd().nextFloat(floor, ceiling);  //337/500 to 1,000/2,000
}
nRunCycles = World.Rnd().nextInt(6, 12);
Class class1 = actor.getOwner().getClass();
Object obj = Property.value(class1, "cockpitClass");
if(obj != null)
{
Class aclass[] = null;
if(obj instanceof Class)
{
aclass = new Class[1];
aclass[0] = (Class)obj;
} else
{
aclass = (Class[])(Class[])obj;
}
for(int i = 0; i < aclass.length; i++)
{
int j = Property.intValue(aclass[i], "astatePilotIndx", 0);
if(j != idxOfPilotPlace)
continue;
Actor actor1 = ((Aircraft)actor.getOwner()).netCockpitGetDriver(i);
if(actor1 == null)
continue;
if(Mission.isSingle())
{
driver = (NetUser)NetEnv.host();
break;
}
if(actor1 instanceof NetGunner)
driver = ((NetGunner)actor1).getUser();
else
driver = ((NetAircraft)actor1).netUser();
break;
}

}
testDriver();
}
}


A graph of the resulting envelope of chute opening height. This provides a good chance of crew pairings popping each chute at a different height and thereby reduce instances of chute collisions/death, even at pretty low jump altitudes.