Default Loadouts, specifically fuel tanks
-
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.