[Soldier_Fortune]

Hi again J_W.

Originally Posted by Jeremiah_Weed

Soldier_Fortune
With regards to using the game's internal clock, yes, you are absolutely 100% correct with that. I couldn't agree more. In fact, I had thought of doing that. My keyboard, a logitech G105, has several keys which are programmable and will allow macros to be preprogrammed to include several keystrokes. Also, the games internal clock, which can be accessed with the console command, >tod, reads out to 6 places which is 3.6 milliseconds...MORE than accurate enough to run the test. My thought was to program a macro key which drops the bomb, pauses the game, and then accesses the >tod command in one keystroke, then, program another to pause the game and access the >tod command when the bomb impacts. As time permits this weekend (I'm at work now) I'll set that up and run some trials. I'll also post the results.
...

I suggested you to use the "in-game (onboard) clock" by a technical reason which surely you know.

Simulators must perform many calculations by time unit, being this time unit the frame out of a given fps rate. Normally 30 fps is a good choice... but it depends on the platform's power and quality.

IL-2 is not a "professional simulator" built with specific hardware and software, but a game to be used with home/general purposses computers. Also this simulator must admit to be played on-line among several players.
Considere that the first sim of this serie was IL-1 Sturmovik (released at Xmas. 2001): you can read its minimal and recomended reqieriments in Wikipedia... if you can keep from laughing (Damn it..! Surely your today's smartphone is more powerful than those computers...!).
Therefore we are talking about a game which is 12 years old!
Since IL-2 Forgotten Battles (March 2002), the game has been improved with a great amount of expansions and patches... But probably the game's engine remains untouched since 11 years ago.

One only and dedicated computer might be tuned to gives the best visual outcomes in real time while it runs a sim. But it is more difficult to obtain identical outcomes with a wide variety of computers models and performances.

Imagine that you and me are playing a cooperative bomb run on-line; you are the flight's leader an I'm your wingman. We're flying He-111 with the same payload (i.e., a 1600 kg bomb). Both have the same keyboard's stop watch to measure the elapsed time between the drop and the hit. But you have a high performance computer (where IL-2 runs like a silk), and the mine is a crap where IL-2 runs choppy (almost like a slide show).
Both will release our bombs simultaneously at your command, and our stop watches are programmed to start when the the bombs are being released.
Your computer runs the sim at 30 fps, but the mine runs it at 20 fps.
Thus, probably you'll see both bombs hitting the ground at the same time and you stop your watch at that instant.
At that instant I already am seeing both bombs falling and my stop watch still is running. Finally, I'll stop it when I see both bombs hitting the ground.
Obviously, when we compare our respective stop watches readings, surely we see a difference of several seconds between them.
But I'm pretty sure that we must have identical readings from our respective "in-game/on-board clocks".

Corollary: Into "IL-2 world" all the clocks are sincronized and the events must be seen at the same time by any "internal" observer (player), regardless of the computer's quality each one uses.

But the observers live in the real world. So: How are the time inconsistencies between both worlds solved?
With a lag for the slowest observer's computer.

This is why I suggested you to measure times with the on-board clocks. Your stop watch or the internal clock are fine and very accurate... but they belong to the real world, not to the "Il-2 world".

Also, with regards to your equation. I agree that it would calculate the correct TAS for this type of aircraft and those types that operate in the flight envelope common for this type of aircraft. (There are several formulas for specific flight envelopes; high-subsonic, trans-sonic, supersonic, etc., and for those aircraft with high compressibility) But I don't think it would generate the correct figure to use on bombsight TAS for all aircraft across the board. Russian planes, like the Pe-8, TB-7, IL-4, and the SB 1M, require a higher value than actual TAS and bombs fall long if this higher value is not used. Also, other planes like the Ju 88, the He-111 H-2, the SM.79, require a lower number than actual TAS and bombs fall short if the lower value isn't used. That's why I was including a "velocity factor" to compensate.

About this matter...

During my tests I performed the following experiment with the Russian bombisght to see diferences of settings between the usual inputs, and those for manual targeting.
The tests were done with and without wind: without wind I used TAS and altitude as usual inputs, and with wind I used GS and altitude.
For manual targeting I calculated the BS_EA (Bombsight Elevation Angle) using the classic equations for parabolic motion.
As you know, in the OPB-1 the usual inputs are processed by the BS and the outcome is an elevation angle indicated by its triangular marker.
The BS-EA for manual targeting must be set with the hollow marker.
If everything worked well, both markers should match.
But I observed that the calculated BS_EA, for given TAS and altitude, was greater than that set in the normal way. ALWAYS.
Without wind the difference was around +3º.

I used the ring target (object #181 in the FMB) as target and I've got hits inside the ring with manual targeting.
What if I had used the usual settings?
Surely my bombs would fall long, as you know.
Why?
Because the aiming angle obtained with usual settings is less than the needed and, therefore, the bombs would be released later.

Why the German bombs fall short?
There is not problems with German bombs. In fact, the same happens with American an Japanese bombs (the latter only when the bomber is a 'Betty').
And it happens because German, American and G4M11 bombers share the same type of bombsight: the Lofte/Norden type.

With these bombsights, the same experiment described above can not be done . But I guess that they share the same algorithms.
Leaving aside the Lofte/Norden BS is designed for auto targeting & drop, and the OPB-1 is not, what other difference between both types we could see?

Well... In the OPB-1, when you increase the elevation angle, the marker moves counterclockwise. In the Lofte/Norden occurs the contrary: the marker moves clockwise.

Probably those algorithms don't calculate angles, but values which represents angles on the screen. And perhaps somebody has forgotten to include a (-1) factor somwhere in those algorithms, to distinguish between one type of BS and the other.
Therefore, the Lofte/Norden has the same error than the OPB-1... but the Norden/Lofte should adds that error with the contrary sign than the OPB-1, because its angles scale is inverted.
Thus, the outcome is a greater elevation angle than the needed, which produces an earlier drop, and the bombs fall short.

I must repeat again: the Laws of the Mechanics work correctly in IL-2. The failure is in the bombisghts, and perhaps they should be reviewed and reworked by TD.

Of course, each player is free to experiment better ways to achieve the best accuracy for precision bombing from high altitudes, or to correct externally the actual issues about bombsights. But he shouldn't miss this concept: The simpler the better.

Well, duty calls...so back to work.

Yeah... I know that feeling.

See you soon!