Print

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

[WxTech]

UPDATE: May 19, 2023. I may have inadvertently included an experimental Wind.class, which would exhibit weird behaviour. The archive has been updated, to have the rocket oscillatory flight action behave as intended. The only changes are to Wind.java, Wind.class and hashed file 96F4C2FA0F2B0FD0.

======================== end of update ======================


This might be considered a WIP, as it might eventually come to pass that a more elegant bit of math might be devised. In the meantime you can enjoy unguided rocket behaviour which more resembles the real thing. You can install and try it immediately before adding the [Mods] section conf.ini entries (default values for the two aim point error sources will be implemented.)


Get it here:

https://www.mediafire.com/file/od4wx4kkrk2irau/%2521%2521%2521_0_WxTech_Rocket_Turbulence.7z/file


From the included readme file:

Enhanced unguided rockets, by WxTech


For B.A.T., at least from 4.0. May work for 4.12?

Be sure this folder sits above any folder containing any of the classfiles listed at the bottom of this document. The two rocket classes here are present in my big Effects pack, in the ROCKET classes folder, and supersede those older versions. And likewise if you use a mod having the Wind classfile. Finally, I include here the few related effects and their resources which are present in my Effects pack; these supersede those older ones.

I anticipate including all of this work presented here in my upcoming Effects pack v1.7...


This project is inspired by the very commonly seen behaviour of aerial launched unguided, bob spin-stabilized rockets in film clips, from WW2 to the present day. And that is a bit of a divergent flight path and an oscillatory motion which departs from a rail-like straightness of flight. You now have full control of the two principal sources of aim point variation:
- Rail or tube mounting skew.
- Random departures in direction at launch.

On top of this are the random oscillations which can impart an additional small devergence from an otherwise smooth flight.


=============================================================================================================

The stock rocket behaviour has long needed improvement. In the discussion below, note that a rocket's aim point is NOT necessarily coincident with the center of the gun sight (if present)! From plane to plane there will be some variation in the basic aim point with respect to a sight's boresight. But for a given plane and rocket group, this basic aim point is constant, being potentially altered by the conditions to be described.

-------------------------------------------

The older additional smoke effect generated briefly upon rocket motor firing was eliminated from Rocket.class at some point, certainly in B.A.T., and possibly earlier. In the rocket weapon classes this property is named "smokeStart". I've reinstated it. This smoke has a somewhat higher density and a more reddish color than the main smoke. The effect is

  3do\Effects\Rocket\RocketSmokeWhiteStart.eff

-------------------------------------------

The second smoke effect accompanying the main smoke was also eliminated from Rocket.class. In the rocket weapon classes this property is named "smokeTile". I've reinstated it. The two smokes have slightly differing size and color, making for a more lively and organic appearance. The effect is:

  3do\Effects\Rocket\RocketSmokeWhiteTile.eff

-------------------------------------------

The implementation of the difficulty option "Realistic Rocket Spread" is unsatisfactory. It appears to apply the same aim point offset for all rockets belonging to a group of rails or tubes. The result is that all missiles of such a group fly off into the blue on the exact same flight path. For example, all left wing rockets might go low and out, while all right wing rockets might be fired upward. While the setup varies randomly from mission to mission, during a given mission all rockets in a group have the annoyingly same, predictable aim offset.

I have implemented a control over this. The difficulty option "Realistic Rocket Spread" is still active, which you can choose to enable or disable as usual. But now the magnitude of the possible offset is fully under your control via a [Mods] section parameter in conf.ini. In Rocket.class there is code to read a property from the rocket classes called "maxDeltaAngle." It defines a limit within which the actual value is randomly selected. But this property is not (yet) implemented in any of the rocket classes. In the absence of a value in the classes individually, a fixed, base offset angle limit of 3 degrees was set in Rocket.class (In my estimation, this is unrealistically large.) Now this property can be set by you to anywhere between 0 and 3 degrees, as set in conf.ini, via the entry "RocketMountTilt". If there is no [Mods] section entry, the value of 0.5 degrees is the default, which is 1/6 the extent previously set as stock.

-------------------------------------------

The flight path of rockets, outside of the usual downward arcing drop under gravity, is far too precisely 'straight' and unvarying. Real unguided rockets do not fly on such 'rigid' courses; they suffer small alterations in trajectory from a number of causes. I have implemented a simple method to impart a random fluctuation in the flight path. This 'wiggling' tends to average out in the main, although occasional, systematic, small changes in the mean flight path do occur, due to the natural Poisson statistics. Just like Nature decrees. The conf.ini control in the [Mods] section is named "RocketAimDisp", and values between 0 and 1 are permitted. If no entry is present in conf.ini, the default is 0, meaning no departure from the intrinsic aim point. A value of 1 permits the maximum possible deviation from the flight path of up to 12 m/s.

This behavior remains in effect even when the difficulty option "Wind and Turbulence" is off. This scheme does not use the actual calculated turbulence that acts upon aircraft; moreover I wanted the flight path fluctuations to be in effect at all times. In something of the way mechanical turbulence varies with altitude, so does this effect on rockets. For a given magnitude of the dispersion as set, it is at maximum at 300m above ground level (AGL), at 2/3 of maximum magnitude at ground level and at 600m AGL, falling to 1/3 of maximum magnitude at 2,000m AGL.


=============================================================================================================

Add the following 2 lines to [Mods] section in conf.ini:
-------------------------------------------------------

###################### add below this line ######################

RocketAimDisp=0.5  //0 to 1 = none to full amount applied to rocket in flight; if no entry, default = 0.5
RocketMountTilt=0.5  //0 to 3 = base rail/tube group tilt angle in degrees; if no entry, default = 0.5

###################### add above this line ######################

- RocketAimDisp: This is rocket aim dispersion, the parameter which controls the magnitude of the potential offset in the initial launch direction with respect to the rail/tube. If set to zero the rocket will leave the rail/tube with no initial aim error. A value of 1 permits the largest possible offset from the aim point, randomly calculated for each rocket launched. A value of 0.5 (half the maximum dispersion) works pretty nicely for my own tastes. The difficulty options "Realistic Rocket Spread" and "Wind and Turbulence" have NO effect here. If no entry is present in conf.ini, the default value is 0.5.

- RocketMountTilt: This controls what we can consider as the rails/tubes of a group being mounted askew (at least some small, inherent alignment error is to be expected). The value you set here determines the maximum offset for that which is randomly assigned from mission to mission. The permitted range is a base angle of 0 to 3 degrees. I like a smaller value of 0.5 degrees, which is of course added to by the aim dispersion if the latter is > 0. If no entry is in conf.ini, the default value is 0.5, which represents a 1 degree circle having 2X the apparent diameter of the Moon (or Sun). Because no rocket classes define their own offset, and all are given a fixed base value of 3 degrees, the difficulty option "Realistic Rocket Spread" no longer has a role to play here. If no entry is present in conf.ini, the default value is 0.5.


=============================================================================================================

Classfiles altered:
------------------
Ballistics.class   (NEW method, updateUnguidedRocket())
  E229439084352048

Rocket.class      (reinstate 2 smokes; implement controllable aim dispersion, flight path oscillation, mount offset)
  8CFCD632574D5B72
  DE884656886D47DE

Wind.class      (NEW method, getVectorRocket())
  96F4C2FA0F2B0FD0

I include the unhashed classes, as well as the Java files.


=============================================================================================================



WxTech
May 19, 2023

[Knochenlutscher]

This is cool, will definitely use. A very cool effort to work this out.
I watched a reel from SAAF attacking Zenica, Central-Bosnia.
My real fathers ancestral Hometown.
It's part of a wider Series of good camshots showing this effect.

It's usually to be traced very distinct at wider distance attacks.
A jerk off effect, not all of the rockets, a few tend to have a near perfect flightpath.
I found it too subtle on other shorter range attacks Movies, but that might be my sight shortcomings.


Thanks alot for the care and work

Best wishes
Tobias

[pied]

Ola Glenn! Tried this newest mod in latest BAT, seems to work as intended. I felt that the default values were too large so I'm trying smaller values.

Thanks for all you do! Get some rest man...

Pied (ed)

[WxTech]

I do impart a fixed baseline range of velocity impulse during flight, the full envelope being 12 m/s. This determines the amount of 'wiggling' exhibited by the rocket in flight. It also plays a role in setting the initial launch direction divergence (randomly applied), but modified by one of the conf.ini parameters (defaults to half of 12 m/s, or an envelope of 6 m/s.)

Maybe I should consider making this in-flight oscillation controllable as well...

Lets's see what you folks say after some try-outs.

[pied]

So after flying several missions with rockets, and reducing both parameters to 0.1, I've concluded that rockets are probably pretty frightening to the ground targets but very ineffectual at actually destroying ground targets. I'm thinking that this is probably historically accurate!

Pied

[WxTech]

UPDATE: May 19, 2023. I may have inadvertently included an experimental Wind.class, which would exhibit weird behaviour. The archive has been updated, to have the rocket oscillatory flight action behave as intended. The only changes are to Wind.java, Wind.class and hashed file 96F4C2FA0F2B0FD0.

[pied]

OK, now I am able to hit the target more often!

Pied

[WxTech]

I've been experimenting further, with an eye to damping the larger jumps in the in-flight oscillations. My new current approach is to keep track of the previous X, Y and Z vector values, and compare them against the newly calculated ones. If the difference exceeds 6 m/s (which is 1/4 the full range of vector values of +/- 12 m/s, or 24 m/s), I begin to subtract from the new value so that it does not make as big a jump as it otherwise would.

For small differences between old and new up to the 1/4-of-envelope threshold, no change to the new vector is applied. At the far extreme, where the old and new values span the full width of the envelope, the new value is altered so that it jumps only half as far as it would otherwise. In between these extremes of instantaneous change the amount subtracted is applied linearly.

For example, the biggest jump would have the old vector at 12 and the new vector at -12 (or vice versa). This 24 m/s alteration would manifest as a quite apparent hard jink. By halving the change, the new vector would be placed midway, or at zero, making for a smaller 12 m/s jump. A difference between old and new of 0 to 6 m/s results in no change being applied to the new vector. A difference of 15 m/s, which is in the middle of the envelope of 6 to 24 m/s differences in which to apply a reduction, would have 6 m/s subtracted from the new vector.

This certainly makes for an improvement. The effect is of a generally smaller average deviation in the flight path, with the largest instantaneous excursions occurring less frequently and less violently.

[WxTech]

Still refining things. I've added a user control for the amount of in-flight oscillation. But before releasing an update I'd like to alter my currently very simple algorithm to slow down the rate of oscillation. To see what I mean, slow down time to 1/4 while firing rockets.

The idea I have:
- Generate a set of 'key frame' XYZ impulse values every 4th game tick (nearly 1/8 sec).
- The future randomly generated 'key frame', 4 ticks into the future, is compared against the just-reached last 'key frame'.
- For the next 4 ticks, the XYZ values are interpolated linearly in steps of 1/4, so as to smoothly transition from one 'key frame' to the next.
- Repeat.

This will pose a bit of a challenge for this Java chimp. Anyone with suggestions?