Default Loadouts, specifically fuel tanks
-
Because of his attitude, Demer is gonna by by. (I do not why he is running nuts!?)
But pay attention to what he said, he is missing many things and is mainly off!
Do not touch the F/R DB ⌠it is extremely âDANGEROUSâ.
Under estimating it = many a/c will crash before able to rejoining the homeplate.
Over estimate it = early mission abort and miss computation of the mission fuel requirements.The Fuel Rate is a REAL tricky stuff and MANY things has to be considered.
There is a process to evaluate it ⌠but nothing is perfect unfortunately and the good compromises are extremely difficulte to find.⌠In any cases, you canât do it properly it on your side because you need to activate a debugg label which doesnât exist on the 4.32. This label is displaying the AI instantaneous fuel rate and has to be used because the AI doesnât burn the same amount of fuel than a human (for instance, depending on actual drag factor and altitude, for an F-16 the difference is about 30 to 40 lbs/min = 1800 to 2400lbs/h!)
Many other parameters HAS to be set accordingly also (the move speed, Max Range wich is directely comming from the F/R and the move speed), average mission alt, max alt and maximum common drag factor) all has to be carefully taken into consideration and have a huge impact.
I will try to write (when I will have the time) something about it.
So my advice: do NOT touch it.
In the future theater DEV will have the hands on the defaul fuel tank loading. But the Fuel Rate will remain a VERY touchy area. Do never play with this without the full picture about what you are doing and ALL the concequences.
-
I understand that it is a challenge to match 2D to 3D to real life. For the most part I think fuel is well done in BMS. My only annoyance in practice is AI bingo is very cautious and AI ATM is not. For a flight plan that takes 7100 lbs to land with 1000 lbs reserve ATO tasks as fine but in practice itâs very delicate. For shorter missions itâs OK and longer OK too. The edge cases are the worst.
Another tendency that seems less than real is too many stores. Campaign makers keep A-10 squadrons low because they are âoverpowered.â I can see why they take off with lots and lots of weapons. This is overpowered if they can use them all and too vulnerable if contested or having to do a million passes on targets.
-
Many other parameters HAS to be set accordingly also (the move speed, Max Range wich is directely comming from the F/R and the move speed), average mission alt, max alt and maximum common drag factor) all has to be carefully taken into consideration and have a huge impact.
Some of those values (other than fuel-rate) are values to make the AIs fly in more proper humanly combat performance envelopes âŚ
But as you said⌠don´t touch them if you don´t know what implications come with the changes.For starters (little OT), it would be wise to finally have all those DB values in SYNC with the same values in the .dat files under the Sim folder.
-
I understand that it is a challenge to match 2D to 3D to real life. For the most part I think fuel is well done in BMS. My only annoyance in practice is AI bingo is very cautious and AI ATM is not. For a flight plan that takes 7100 lbs to land with 1000 lbs reserve ATO tasks as fine but in practice itâs very delicate. For shorter missions itâs OK and longer OK too. The edge cases are the worst.
Another tendency that seems less than real is too many stores. Campaign makers keep A-10 squadrons low because they are âoverpowered.â I can see why they take off with lots and lots of weapons. This is overpowered if they can use them all and too vulnerable if contested or having to do a million passes on targets.
100%
-
Another tendency that seems less than real is too many stores. Campaign makers keep A-10 squadrons low because they are âoverpowered.â I can see why they take off with lots and lots of weapons. This is overpowered if they can use them all and too vulnerable if contested or having to do a million passes on targets.
Those issues (A-10 âoverlaodâ) i have addressed in Redflag i.e.
Don´t forget, that KTO serves more or less as an UNIVERSAL TEMPLATE THEATER (at least this is how i see it), where all options are available at max quantities, and that more defined or more specific optimized theaters (for different puroposes) will always need editional editing work and optimizations. Hence, saveX.cam and database access or edits are ESSENTIAL theater-creation requirements - like an advanced TE builder, but just for campaigns or theaters instead just for TEs. -
@A.S:
For starters (little OT), it would be wise to finally have all those DB values in SYNC with the same values in the .dat files under the Sim folder.
Unfortunately, this would be valid only if the common weapon loads and common drag factor are the same. As soon as you change something in the weapon DB, the F/R values might be (most of the time, will be) unvalidated ⌠and hence the max range also. Same problem as soon as you modify the move speed. As soon as you are modifying the DB, those values might be scrubed and break the 2d fuel requirement computation, and the 3d dynamic bingo. All this pain because we canât evaluate the F/R on a clean a/c (DF 0) because the code is unable to know what is the a/c drag factor at the time the mission is created a d fuel requirement is computed. Same in 3d ⌠the code canât take your actual drag factor in consideration âŚand this is why we have to âchooseâ a given drag factor (usually the highest most common observed in campain) for the fuel rate elaboration (which has to be measured in 3d and canât be calculated as suggested by Demmer.) Everything at FL150 for an AI flying at its DB move speed. Any deviance can have big concequences ⌠but in some cases, are mandatory. Remember that we have to make it work for all a/c type, for all mission type, all profiles, all configurations by using a signle computation routine and onlyone value of fuel rate. Obiviously it is a delicate challenge and compromises are unavoidable. Defining those values properly canât be intuited without the âfullâ picture. (and even with a good picture is is extremely trikky and time consuming sine each single a/c entrie has to be evaluated in 3d ⌠each varients individually.)
-
I understand that it is a challenge to match 2D to 3D to real life. For the most part I think fuel is well done in BMS. My only annoyance in practice is AI bingo is very cautious and AI ATM is not. For a flight plan that takes 7100 lbs to land with 1000 lbs reserve ATO tasks as fine but in practice itâs very delicate. For shorter missions itâs OK and longer OK too. The edge cases are the worst.
Another tendency that seems less than real is too many stores. Campaign makers keep A-10 squadrons low because they are âoverpowered.â I can see why they take off with lots and lots of weapons. This is overpowered if they can use them all and too vulnerable if contested or having to do a million passes on targets.
Not is the only problem that A-10 is ridiculously OP but the same Su-25 is very, very weak. Also in my MOD I allowed very limited qty. of A-10 and I also tried to limit the qty. of weapon in campaigns.
-
This post is deleted! -
Toucheâ
Attitudes expressed, applied\implied recently, including yours, leads me to believe that my attitude is correct.
Araâ please correct my syntaxâŚâŚLOL!Now Pee Off Dude, I do not have the time left to get into a Frugs\Delphi debate anymoreâŚâGet It???â
demerwww.benchmarksims.org/forum/showthread.php?7541-Tom-s-Cat&p=302774#post302774
-
www.benchmarksims.org/forum/showthread.php?7541-Tom-s-Cat&p=302774#post302774
LOLâŚâŚyeah!!!
A real big one, at thatâŚCheers,
demer -
Unfortunately, this would be valid only if the common weapon loads and common drag factor are the same. As soon as you change something in the weapon DB, the F/R values might be (most of the time, will be) unvalidated ⌠and hence the max range also. Same problem as soon as you modify the move speed. As soon as you are modifying the DB, those values might be scrubed and break the 2d fuel requirement computation, and the 3d dynamic bingo. All this pain because we canât evaluate the F/R on a clean a/c (DF 0) because the code is unable to know what is the a/c drag factor at the time the mission is created a d fuel requirement is computed. Same in 3d ⌠the code canât take your actual drag factor in consideration âŚand this is why we have to âchooseâ a given drag factor (usually the highest most common observed in campain) for the fuel rate elaboration (which has to be measured in 3d and canât be calculated as suggested by Demmer.) Everything at FL150 for an AI flying at its DB move speed. Any deviance can have big concequences ⌠but in some cases, are mandatory. Remember that we have to make it work for all a/c type, for all mission type, all profiles, all configurations by using a signle computation routine and onlyone value of fuel rate. Obiviously it is a delicate challenge and compromises are unavoidable. Defining those values properly canât be intuited without the âfullâ picture. (and even with a good picture is is extremely trikky and time consuming sine each single a/c entrie has to be evaluated in 3d ⌠each varients individually.)
stupid idea maybe but on the other hand easier then doing 10000 tests:
couldnât the code âlearnâ for example on the FO server and gather for each a/c each mission type some of these values under certain sharp defined circumstances - > letâs say while fence in after reaching cruise alt and complete load out minus small fuel burned already. over time the code would have self generated lookup tables that are getting better and better. -
Not a valid approach. And would require a code and database overhaul ⌠Even more time consuming and less precises.