A bit of reading

https://www.falcon-bms.com/articles/systems-weapons/aim-120-bms-acquisition-model/

new approach completed

ok

Thanks to your repro case the bug has been identified.

We have a maximum time to attack defined, if the AI has not passed to the final attack status before that max time, it jsut abort and select next waypoint.

This is a protective measure in case bad thing happens in the DigitaBrain in order to not loose AI and allow it to move on.

In this specific case, the Leader starts the attack very very very far away from the target, the timer is started at the start of the attack, which is not the case for the wingmen who start their timer ONLY after beeing commanded by the leader to do so…

that is why Lead abort while wingmen attack

if you want to solve it
put
set g_nGroundAttackTime 20

in your cfg

On the code side, i will try to make things more clever

Lets be clear

without your REPRO Case, NO WAY i could have found that one alone

one more squashed…=> next

This thread is dedicated to Falcon 4.0 history (and before BMS 4.32 era).

Any pictures or videos that have been made after falcon BMS 4.32 release are not welcomed until next decade.

Start archeology on your hard drives , enjoy the journey and the satisfaction to remember where we come from

Long Live falcon

PS: Please post only Falcon 4.0 related stuff (nothing else - Falcon Allied Forces isn’t Falcon 4.0)

Okay problem definitively solved in next patch

Good news

This repro case has revealed two very serious bugs
(The release bug was fixed already) - in particular one about arming delays and the other critical about NaN spreading all over the code

We will work on them

The F16 rolls around its velocity axis (fpm) , not the roll axis

This is one of the fundamental of the F16 (and most of modern fighters ) and is made possible thanks to the ARI

This has be designed to reduce the alpha indicied impact from the side sleep angle during roll at high AoA

It’s explained partially in my FM / FLCS article Please read page 11 of

https://www.falcon-bms.com/wp-content/uploads/2021/08/FM_Developers_Notes_Part_4.pdf

The con is that it provokes inertial coupling

Please read the nasa TP1538 if you want to understand it fully

https://www.cs.odu.edu/~mln/ltrs-pdfs/NASA-79-tp1538.pdf

Page 14 of the document , quote :

“The control system of the F-16 incorporates an ARI and a stability-axis yaw damper which attempt to make the airplane roll about its velocity vector throughout i t s normal flight envelope.”

With BMs you are flying the closest FM to a professional f16 simulator , you can be sure I wouldn’t have made a mistake of that kind

But I have no merits , all the merits goes to the NASA engineers that have modeled this simulator , I just improved it with HFFM and real FLCS

Guys, please stop speculating… what you see in the video is just the result of high speed engagement with TW capable aircraft. with the exact same engagement parameters every time

On the To Do List:

• Include a randomness factor for LEVEL turn instead of vertical for Aces and Cadet : 25% chances for aces , 50% chances for Cadets (this was supposed to be in the code already but for whatever reasons i forgot to make use of it at some point)

• I might try to add a merge reversal in the equation for AOA angle fighters….when oppoentn is not AOA angle fighter …no promises here.

Probably the runwayDimList rectangle is crossover

Okay problem definitively solved in next patch

OK

I must make a more complex code then as there is no easy solving, no problem , i’m on it

ok

Thanks to your repro case the bug has been identified.

We have a maximum time to attack defined, if the AI has not passed to the final attack status before that max time, it jsut abort and select next waypoint.

This is a protective measure in case bad thing happens in the DigitaBrain in order to not loose AI and allow it to move on.

In this specific case, the Leader starts the attack very very very far away from the target, the timer is started at the start of the attack, which is not the case for the wingmen who start their timer ONLY after beeing commanded by the leader to do so…

that is why Lead abort while wingmen attack

if you want to solve it
put
set g_nGroundAttackTime 20

in your cfg

On the code side, i will try to make things more clever

Lets be clear

without your REPRO Case, NO WAY i could have found that one alone

one more squashed…=> next

@Trigger thank you,

i can’t find the radar Site, please provide your TE File

@Trigger said in 4.37.8 testers needed:

@Mav-jp Lol I mean I don’t mind testing. I spend more time testing than flying anyways. But now that I know what you need for a REPRO case I will give you every detail you requested. I will try to change things on my own and let you know what the out come is of each try but I will start with a base reproduction.

ideally a simple TE (with less AI possible) is great, so i can filter out easily in code the DigitalBrain

@Trigger

BTW, sorry i thought i was in the 4.38 Btest room , the “8” of 4.37.8 confused me, so i understand you are not official Btester hence i understand better that you dont know what “repro case” means

Thank you for your report, would be cool if you have a repro case though

@Trigger said in 4.37.8 testers needed:

@SOBO-87 So aggregated would mean in this case visible? Meaning if it’s aggregated it’s outside my my gods eye view bubble right? And then if something becomes deaggregated it’s now in my gods eye view or bubble? If I’m understanding that correctly if I can see it and shoot at the target then that means the AI don’t share my bubble and they can’t see it?

If I’m understanding that correctly ok that would explain them not using long range weapons at mine (the players) range because they can’t see as far as me but AI controlled flight member can shoot at 50 miles so I know for sure they can see or the target is deaggregated by then. So why does the None AI controlled flight fly into the teeth of the enemy with the same long range weapons when the AI can for sure see them at 50 miles? This isn’t just cruise missiles either they are just the platform I discovered this behavior of AI flight leads not dropping there weapons which seems to trickle down and affect the other members of the AI flight. Todays flight over the Balkans an F-15E loaded with 5 JDAMS flew directly over the target lead peeled off dropped zero ordinance and two followed that dropping all of his weapons and then the flight went home.

there was a bug where AI was unable to deaggregate units by themselves, therefore if player was too away from the target, the AI couldnt launch anything, especially long range weapons

This is fixed in next iteration.

however, it’s not the only issue, to REPRO Case is still needed

DEAGGREGATED means that you can see the VEHICLES attacked with the camera “6”.

@Trigger said in 4.37.8 testers needed:

@Mav-jp I’ve seen this behavior on multiple setups with multiple planes. OCA strike, DEAD, Strike, etc. Not just bombers. AI flights specifically the flight lead struggles release weapons on ground attacks against runways, buildings and units alike. Almost always number two, three and four will be the ones to release the weapons while 1 will just over fly the target not release and cause the remaining flight members to circle endlessly either releasing weapons slowly on multiple passes or they just outright RTB without doing anything. The targets are very much alive units very much in place when this happens. Sometimes flight lead will do the job but out of 8 attempts he usually will release 1 or twice.

This behavior is not just limited to the bombers. I’ve seen Strike eagles, nighthawks, f-18s all do this. Of course the f-16s seem to avoid this behavior. This is all AI and not AI controlled flights.

OK obvioulsy you understand that i cannot reproduce the issue here on my rig, else that would be too easy.

There are multiple reasons whythe AI could refuse to launch.

The only way for me to debug is to have a reliable repro case, that means a perfectly identified pattern that i can reproduce step by step to trigger the bug.

EVERYTHING Matters :

weather, time of the day , theater , Team , number of aircrafts in the flight , Type of units , position of the player relatively to the Faulty AI, type of mission, type of weaponds, altitude at attack, IP position from the target etc etc etc …

So saying “there is a bug” , i CANNOT find it… i need a repro case, which is a CONTROLED environement where the bug is described step by step so i can reproduce it.

Is is more clear ?

The ROle of the Btester is to find bugs, AND to search for reliable repro case for the coders to debug…saying that there is a bug is step 1 of the process and it’s the easiest part