Posts made by Jags
-
RE: FSSB-R3(L)-Warthog HOTAS Upgrade.
Had an R3 for about 4 years, just upgraded it to the lighting version. Works amazing in Falcon. I also really like it for WW2 planes, but it can be tiring to the hand/arm in long dogfights, but I have a Gunfighter stick for that.
-
RE: 32” monitor
I have a 32” LG tv I use as a monitor at 1080p mounted to a Obutto at an arms length and BMS (and other games) look great, no pixelation.
-
RE: Missile aerodynamics project
The “thrust bug” was corrected with the 4.33 release, it now produces realistic results. The stock BMS aerodynamic missile data was also updated to be much better (although I still think the drag on the aim-120 is too low). I did some work on my own missile data file after 4.33 was released based on public data, but haven’t worked on it I over a year.
-
RE: New F16 starting procedure in real life?
Based on logic from other government agencies, perhaps the pilots are instructed to fly with speed brakes open to burn more fuel in order to keep their monthly fuel cost allotment the same due to the falling cost of fuel;)
-
RE: Amraams, Sparrows, and Sidewinders
So based on that handbook, we agree that total impulse is the same in the event of a varying temp? I might have a read of that whole text I think. This is interesting stuff!
Yes, according to that document total impulse only varies 3% over temp range between -57 and 76 deg C of the propellent grain temp when fired. So temp variation has very little affect on total impulse. Playing around with these values in minizap, I think the temperature variations to thrust can be ignored for the purposes of simulation within BMS. The total impulse may increase slightly with decreasing pressure (such as higher altitude). I wonder if the thrust bug is a simple mistake in the decimal point position in the code, that perhaps the intent was for thrust to increase 3.3% by 20k ft and 6.4% by 40k ft instead of the 33% and 64% currently in game.
-
RE: Amraams, Sparrows, and Sidewinders
Id be interested to see a source detailing how that works? In fairness most of my knowledge in this area was sparked by an interest in a space simulation game called KSP - and in that game, mdot does vary with altitude, while thrust remains constant. Still, that is also widely recognized as a bug in the games physics.
I went looking briefly for anything describing properties of solid rocket motors burn time varying with altitude or temperature and found nothing… all I found was talking about how thrust varies and Isp varies, and mdot being constant. So Im not sure if Ive just not found something obvious, or if the stuff Ive been reading about is only correct under certain conditions (not an unusual thing in the case of calculus and rocket physics).
Go to www.everyspec.com and search for MIL-HDBK-1211(MI) and download the 2nd result down. Then see figure 2-24 on page 41 of the pdf. This is a figure of the effects of temperature on solid rocket motor thrust.
-
RE: Amraams, Sparrows, and Sidewinders
If you have accurate normal and axial coefficients for a missile and have the correct missile weights and reference area, missiles in BMS will produce accurate flyout performance after burnout of the motor at all altitudes up to at least 20k ft(using aim-9l flyout charts), and seems to be accurate to at least 40k (haven’t tested at higher alt). However, there is a bug in the code that increases the thrust with altitude, which results in much higher burnout speeds than is real as altitude increases. So if you use accurate thrust data at sea level, you will get close to correct burnout velocity, but by 20k ft the thrust is increased by 33% in game and by 40k ft thrust is 64% greater than sea level in game. This is hard coded, so only BMS will be able to fix it. In real life, I think specific impulse for thrust stays within 2-3% of sea level value, but the burnout times increase as temp drops. So if a motor burns out at 6 seconds at sea level with 15000lbs total thrust, the total thrust at 35k ft would be roughly the same but the burnout time might be ~9 seconds (assuming the standard temp/pressure model in BMS). The axial coefficients would also be around 10% lower while the motor is burning, although that could be simulated by a touch higher thrust than real.
The only workaround now is to use higher axial coefficients at higher mach’s (mach’s above sea level burnout speeds work best) to keep speed down at the higher altitudes in order to get closer to accurate flyout performance to the chart values. I believe this does produce better results that the current data that is used stock, but I completely understand BMS wanting to fix the issue a coding level before messing with the data.
I believe BMS knows all of this and it will be addressed in 4.33, in 3-4 Falcon weeks.;)
-
RE: Missile aerodynamics project
How can you determine the difference between effect? So are you saying because of coded (?) thrust increase become too big the kinematic range in some cases and not because of the atmosphere model? As I know at the level of Falcon the thrust of solid rocket fuel can be treated as static trhust which is independent from altitude.
Yes, I am saying that if you would set a static thrust of 5000 lbs for 5 seconds in the missile data file, the actual thrust in game would be 6650 lbs(50001.33) at 20k ft and increase to 8200 lbs(50001.64) by 40k ft. This results in excessive burnout speeds/range. In fact the only limiting factor on max range in the stock missiles at high altitude is the max time of flight(battery time).
At first I thought that the excessively high burnout speeds as altitude increased was due to the atmospheric model being incorrect. However, I found that that was not the case as the missiles deceleration matched the real life flyout charts at all altitudes for both the aim-9 and aim-7, therefore the air density is correct in game at the altitudes I tested(0, 10k, 20k, 40k ft). I confirmed this using set static thrust and drag in a missile file and with the velocity generated in game plugged back into the drag equation to find the P value(air density) in game. I then set all the drag coeficients to 1 in the data file, and increased the burnout time of the sustainer thrust (1018 lbs) to 115 seconds at burnout. Then I fired the missile at distant same altitude targets at the test altitudes and recorded the velocity when the missile stabalized (thrust = drag). Since I knew that the atmospheric model was correct for density, I used the drag equation (Drag force = 0.5 x P x V^2 x Cd x A) and plugged in the in game air density,missile reference area, 1 for all Cd since I set them all to 1 in the file, and the final stabalized velocity at that altitude. I compared that force result to the actual thrust I used in the data file, which should have been equal if the game was not modifying the thrust. This is how I found the game is increasing the thrust dramatically as altitude rises, to the tune of 33% at 20k ft and 64% at 40k ft. This increase to thrust as altitude increases must be done in code, and it results in very excessive burnout speeds at high altitude. -
RE: Missile aerodynamics project
Thought I’d post an update on what I’ve learned about the missile behavior so far(after a couple thousand test firings acmi files):
- The atmospheric model(as it pertains to drag on a missile) seems accurate for various alt up to the 40k ft I tested.
- In regard to the thrust entered in the data table, in game the thrust is a few percent low at sea level, 33% too great at 20k ft, and 64% to great at 40k ft. A coded fix would be needed to correct this. The best way to overcome this currently is by using SpbGoro’s approach of using actual thrust in the data tables and then setting a “speed brake” with overly high drag in the the coefficient table at a pre-determined max speed limit. In reality, missile thrust does not increase with altitude, but due to the temp decrease, the burn times would increase similar to those percentages as altitude increased(perhaps that is what Microprose developers were going for?). However, the total thrust impulse would remain about the same as it is at sea level( probably about 3% lower above 35k ft).
- “Weight of missile” in the data table is the burnout weight and “weight of propellant” is just what it says. These 2 added together are the missile launch weight in game. The propellant weight is decreases to 0 in game by motor burn out. I do not know if this is linear over the missile burn time or varies by thrust level over burn time(my guess is linear).
- Although the stock aerodynamic coefficients are in a normal and axial format, the game actually interprets the data as lift and drag. This is plainly seen in tacview as the stock the missiles do not add show any additional drag as angle of attack increases. When the stock normal and axial data is converted to lift and drag format data, the missiles drag obviously increases with angle of attack.
- The AOA max/min and Beta max/min values do not seem to be hard limits to the missiles max angle of attack. In game the missiles can achieve just over 2 times this “limit”.
I get the feeling the Microprose developers were still working on the missiles when they ran out of time perhaps?
For those interested in how I came up with this:
I’ve created a completely new aerodynamic coefficient table(not in the file on the first page, that is stock coefficients in lift and drag format) for the aim-9 based off of some datacom data as well as an actual zero-lift drag table, and using actual sea level thrust table for the aim-9. I have then been running flyout performance tests and comparing them to an actual flyout performance charts for the aim-9l at sea level, 10k and 20k ft. This flyout chart also gives flyout data for an aim-9 “variant” missile modified with aim-120 nose and fins on an aim-9 airframe/motor. I also created an aim-7 based off a tactical missile design document intended for a college course, and compared that to the flyout data it provided at altitudes varying from sea level to 40k ft. I did tests mostly at sea level, 20k and 40k ft, and found that the flyout tests in game produced very accurate results after motor burn out. The problem is that for some reason the code increases the thrust of missiles as the altitude goes up. At sea level the thrust in game appears to be close, if a tiny bit low. At 20k ft, the thrust is 33% too high, and at 40k ft the thrust is 64% too great. I obtained those thrust % results by setting all the drag coefficients(axial as labeled) to 1 on my aim-7, the thrust to a set value (1018 lbs) for over 100 sec burn time and then obtaining the max velocity in game(drag=thrust) at different altitudes. Then I plugged the data into the drag equation (Drag force = 0.5 x P x V^2 x Cd x A) to find actual in game thrust compared to the thrust in the data table. I also found that the using the aim-7 aerodynamic coefficients with a 0.87 modifier(13% reduction) for drag used in an aim-9 missile data file(aim-9 weight, ref area, and thrust) produce flyout results very close to the aim-9 variant(aim-120) flyout tables. -
RE: Missile aerodynamics project
I have read many posts here over the years about how the RWR is too accurate and how that missiles cannot be dodged by using a “crossing turn” in front of them. So I guess I might as well throw in my 2 cents…
As to the RWR, I have never operated one in RL nor seen any manuals, as I imagine they are still classified. However just looking at the SPO-15 RWR display from a MIG 29, it seems that it is able to display the direction of a threat to within about 20 degrees of accuracy within the frontal 180 degree sphere of the aircraft (I imagine the number and placement of the RWR antennas plays a large part in accuracy/coverage), as well as whether it is above or below the aircraft. And the signal meter looks like it gives accurate signal strength data.
I have read that the French Rafale can fire missiles based on targets based on RWR data alone.
A valentine One radar detector for your car uses just 2 antennas (front and rear) and can display general direction of threats (front, rear, or sides), as well as accurate data on the signal strength data(visual meter and “beeps”) that you can use with experience to estimate range to threat based on radar type/frequency. It also used digital signal processing logic to help eliminate false alarms based on radar band, directional changes and signal strength. And that is just a $400 consumer device that has been sold for 22 years.
Based on that, it seems believable that the RWR in the F-16 could display some pretty accurate directional and distance data(based on digital processing of signal strength and radar type). My guess is that perhaps RL RWR’s also display numerous false alarms that are not real threats. Unless someone who has actually operated a modern RWR is allowed to speak on the subject though, we can only make educated guesses.
As far as the “crossing turn” method of dodging BVR missiles fired from the front goes, I do not understand why anyone thinks that this could not be effective(if not always wise). Missiles are traveling very fast and have small wings and control surfaces and therefore large turning circles. In Robert Shaw’s “Fighter Combat: Tactics and Manuevering” he describes both a crossing turn across the missile, as well as a high G barrel roll around the missile as effective defensive techniques against threat missiles fired at you from the front quarter, especially against the larger BVR missiles and at higher altitudes(page 61). Now if someone were to fire two missiles at you a few seconds apart, you would probably fly directly into the second one using those methods, or be too slow to reverse the turn(the Russian tactic of firing 2 BVR missiles a few seconds apart may not be just about using a variety of seekers). And although possibly effective, in RL you may not feel as confident turning into a missile unless you have no other option as the “escape button” on a real jet is a bit more unpleasant than on our keyboards!
-
RE: Missile aerodynamics project
Be careful, you are doing wrong assumptions
This is INCORRECT.
BMS reads Empty weight and Weigth of propelant SEPERATLY.
void MissileClass::ReadInput(int idx)
{
inputData =
missileDataset[min (idx, numMissileDatasets-1)].inputData;
weight = inputData->wm0 + inputData->wp0;
wprop = inputData->wp0;
mass = weight/GRAVITY;
m0 = inputData->wm0/GRAVITY;
mp0 = inputData->wp0/GRAVITY;
mprop = wprop/GRAVITY;
}inputData->wm0 beeing the value read in the dat file as “weight”
inputData->wp0 beeing the value read in the dat file as “propellant”So the value in dat file shall NOT be the sum of both.
The confusion comes from the fact that since the origins of falcon, the DATA developpers put in that value the sum of both and build all their missiles like that. This was a mistake of course…BUT this may not have been wrong because as they made all their calculations or in game trial with this mistake in it, they have set up their missile taking this bug into account.
based on that fact, we had 3 choices :
-
Fix all the dat files by adjusting the weigths to the correct empty weight, which would require a complete rewritten of the other values of the dat file in order to match again the correct intended behavior
-
Adjust the code , to read weight as total weight, but then that would require to keep same weight in the dat file but to change all the other values of dat fil to match again the correct intended behavior (this is VERY HACKISH)
-
Dont touch anything and keep the correct intended behavior.
we at BMS made the choice de apply “3” because we trusted SPx developpers and did not want or had the time to recheck all missiles
AF has made the choicde to apply “2” but have not changed all data files, resulting in unknown missiles performances
NOW if your intention is to set up everything properly ; you must put EMPTY valaues in there and develop your missiles FM from this.
That is INCORRECT
the missiles code takes AXIAL / BODY values , that are read in the dat file as CX, CY
/–----------------/
/* body axis accels /
/------------------/
ifd->xaero = cxifd->qsom;
ifd->yaero = cyifd->qsom;
ifd->zaero = czifd->qsom;/-----------------------/
/* stability axis accels /
/-----------------------*/
ifd->xsaero = ifd->xaero * ifd->geomData.cosalp + ifd->zaero * ifd->geomData.sinalp;
ifd->ysaero = ifd->yaero;
ifd->zsaero = ifd->zaero * ifd->geomData.cosalp - ifd->xaero * ifd->geomData.sinalp;/------------------/
/* wind axis accels /
/------------------*/
ifd->xwaero = ifd->xsaero * ifd->geomData.cosbet + ifd->ysaero * ifd->geomData.sinbet;
ifd->ywaero = -ifd->xsaero * ifd->geomData.sinbet + ifd->ysaero * ifd->geomData.cosbet;
ifd->zwaero = ifd->zsaero;WHEREAS acdata aero code read CL / CD values (wind axis)
lift = clqsom;
drag = cdqsom;
/–----------------/
/* body axis accels /
/------------------/
xaero = -dragplatform->platformAngles->cosalp +
lift*platform->platformAngles->sinalp;yaero = cyqsom((float)beta - (float)fabs(beta)yshape0.5F);
zaero = -liftplatform->platformAngles->cosalp -
dragplatform->platformAngles->sinalp;/-----------------------/
/* stability axis accels /
/-----------------------*/
xsaero = -drag;
ysaero = yaero;
zsaero = -lift;/------------------/
/* wind axis accels /
/------------------/
xwaero = xsaeroplatform->platformAngles->cosbet +
ysaeroplatform->platformAngles->sinbet;
ywaero = -xsaeroplatform->platformAngles->sinbet +
ysaero*platform->platformAngles->cosbet;
zwaero = zsaero;Sorry to say we can not trust your work at that point
Perhaps I did not explain myself very well.
It is my understanding that the way the code reads the data files, that the launch weight of a missile is the sum of the the “weight of missile (lbs)” data and the “weight of propellant (lbs)” from the data file. It seems to me that the equations in the code have been altered to take this “bug” into effect, since if you enter the actual weight of the missile at burnout into the “weight of missile” data instead of the launch weight, the resulting missile velocity is much too great. That is why I had to reduce the thrust by 25% in my data files.
To address your second point on the aerodynamic coefficients. In the missile data files, the aerodynamic coefficients are listed as Normal and the Axial coeffients for various angles of attack and machs. However, as the missiles did not show additional drag as angle of attack increases(in fact the opposite) as they should. Looking at the coefficients, this seemed odd as the normal forces increased significantly as angle of attack increased which should have also increased the drag. I then used the equations from this web site: http://www.aerospaceweb.org/question/aerodynamics/q0194.shtml to convert the stock data coefficients from normal and axial format to lift and drag format. So the aerodynamic coefficients I have in my files are the same data, just in a different format. Upon testing in game it is plain to see that the missiles now showed increasing drag as angle of attack increased as would be expected. This is what led me to believe that the aerodynamic equation in the code was set up using a “lift drag” format instead of “normal and axial” format as in the stock missile files. As to if this is the case or if there is some other error in the code, I do not claim to know.
I am quite sure that you know much more about aerodynamics than I do, and I am not a coder so even if I could see the code it would probably be quite painful for me to try to match that up to aerodynamic equations to see what’s going on, and I am sure that this is best left in your capable hands! However, I am just as sure that in stock form the missiles do not show anywhere near the amount of drag in high g turns at high angles of attack as they should(in fact almost none), which is allowing them to perform completely absurd maneuvers such as adders performing an 180 deg mach 2 turn while losing almost no energy and then running down a supersonic fighter. This is what got me looking at all this in the first place.
As to your last statement that you cannot trust my work. That is good, as I don’t trust it either! I just don’t have access to the flight data for most of the missiles to even test them properly. I sincerely hope this thread may inspire the BMS team to look into this and fix it much better that my rough data hacks can. But that being said, I am also confident that the missile behavior in game with my files is more accurate than it currently is stock and that perhaps others would enjoy using my data file until a proper, more accurate fix is made.
-
-
RE: Missile aerodynamics project
Did you characterized that on several missiles (which ones?) or based on one single conclusion (single missile test)?
The only good flyout/thrust data I could find for air to air missiles was for the aim-7f and the aim-9l, therefore these are the only missiles I can really test to known data. I tested other air to air missiles as well to see if their performance was roughly within what one should expect based on their weights/total impulse and what max speed and range data is available. Since my aero tables are only conversions of the data in the file from normal and axial force coefficients to lift and drag coefficients, I didn’t really change any of that data, just the form it is presented in for the sim to read. The manuals for the SAM Simulator provide pretty good thrust and weights values and max speeds of various older sams such as SA-2, SA-3, SA-4, SA-5, and SA-8.
-
RE: Missile aerodynamics project
thanks. anything that potentially makes the game more realistic is something i am always for. i will start playing around immediately. where did you get your information on missile performance data? i would like to take a look.
thanks for the tip on the Generic Mod Enabler. i use silent hunter as well. i didn’t know i could use that with other programs.
The missile data I have found using google. What looks like a college paper on missile design had some good data on the aim-7 for both thrust and flyout at 20k altitude. I also found a document with thrust and flyout data on the aim-9l at various altitudes, comparing it to a “variant missile”. I also found some axial/normal force charts created a South Korean university using Aero DB software for the aim-120 and aim-9. I do not believe any of it is classified, but I will not chance posting any links do to the instant ban hammer! I could e-mail these to you if that is ok.
-
Missile aerodynamics project
This all started over a year ago, when while watching recordings of my BVR adder defense practice in tacview. I noticed that the missiles bled speed very slowly, and did not exhibit any additional speed bleed when turning. The result made defense against even long range BVR shots difficult using conventional tactics such as beaming and staying at corner speed for a turn into the missile were useless. The “crossing technique”, which normally should only be used for missiles fired at your front quarter at short range as a last resort, worked pretty well. But even then I saw adders that were fired at me from 27nm do a complete 180 and run me down from behind after dodging them at full burner!
That is when I started checking the forums, and came across some updated missile data files from SpbGoro, OSD, and Molni. After reading their posts, looking at the data files, and a LOT of googling, I started doing some testing with the missile data files and came to some conclusions.
First, although the stock BMS missile aero data files are in “normal and axial force” format, it became obvious that the program was actually using the data in “Lift and Drag” format like it does for the aircraft files. Next(thanks to Molni on this one), that the way falcon BMS reads the data file, the launch weight of the missiles is the sum of the “weight of missile” and “weight of propellant”. The stock files list the total launch weight of the missiles in the “weight of missile” category, leading to much too high launch weights that affect both the decreased total velocity attained and decreased deceleration rate. Finally, even after fixing these first two problems, the missiles had too much max speed, and not enough deceleration. So after much testing, I found that reducing the thrust by 75% and increasing the drag multiplier(used to be axial mult) by 33% led to pretty accurate results(at least for the missiles I can get data on). According to the data I have on aim-7 and aim-9 flyout performances at 20k, the missiles are pretty close now. Data used was what can be freely gathered from the internet. This is by no means perfect and is an ongoing process as I do more testing and or find new data, but I think the missiles now behave much better aerodynamically.
The best part of this mod is that not only are real world tactics effective now, but that long range amraam shots at the AI are no longer automatic “magic missiles”. There is actually a good reason to wait for a closer shot, especially a shot in NEZ range if you want to have a high pk on fighter aircraft. This can result in more dogfights that you would be used to in campaigns.
To install, first back-up your Data/Sim/Misdata folder as this file is multiplayer critical! Next copy my Misdata folder to your Data/Sim folder and overwrite all files. I recommend using the Generic Mod Enabler instead, which makes enabling/disabling mods very easy. I have updated pretty much all the missiles the f-16 uses as well as the missiles that will be used against you.
https://www.dropbox.com/sh/3j5waaofakr5kr1/AAC_cGYze-X26Y4uo2ZYZbG5a
Thanks goes out to SpbGoro, Molni, and OSD for their work on improving the missiles, the RP5 manual, Google, the guy who created the documentation for the SAM Simulator(lots of data on thrust, burn times, weights and missile performance on older SAMS), and of course the BMS team and Microprose for making this all possible. This really took me an inordinate amount of time to get to this point(it really is rocket science after all;)), so I really got a better appreciation of the work these and other people put into on our sims.