Possible active radar missile bug (very serious issue)
-
The effect of chaff can be controlled via DB values. What I cannot accept that this part simply does not work. When will be fixed it can be talked about other issues. BTW this is a requirement for 3rd party creation…
-
The effect of chaff can be controlled via DB values. What I cannot accept that this part simply does not work.
Maybe there is a reason for that
-
@A.S:
I get your point, don´t get me wrong, but in order to “improve” something first deliver real data how. I have docs on that matter and maybe i re-digg this topic again just out of curiosty.
You still need to evaluate what effects real chaffs have on real ARHs …. only then we can proceed the discussion, compare the picture and look for probable integrations or solutions (in respect to what the F4 environment permits) Molni.
Right now it´s just a report about a discorvery about something which supposidly is not working the way you expected it to.You’re holding opposing side of the argument to a very high standard.
There’s a bug. There’s no talk of data needed from BMS team members. But molny has this burden imposed by you to provide some data.
What gives?
Also, talk of “integrations and solutions”, why are you making a roadmap the BMS team’s members are unlikely to ever adhere to?
-
Nothing to do with “high standards” at all. BASIC FUNDAMENTALS FIRST.
Tell me sthalik, how is anyone supposed to simulate anything properly without even understanding how it works in reality? If those questions are not addressed first then any other debate or attempt to simulate the same is rubbish.
Is there a “bug”? Maybe. Maybe its a “workaround” for the time being, maybe it is intentionally as it is for reasons unknown to the end-user. Or maybe it just doesn´t ****ing work at all.
Or maybe the chaff effectiveness is not defined in the DB afterall, but somewhere else, even if it is present in there? Or maybe you guys just don´t understand how things are simulated globally afterall?Right now it is just an “observation”, that if “played” around with DB values no variable results can be observed…but THAT`S IT - at best.
So, will a suggested “fix” of the so called “bug” make matters more realistic or worse; and what is realistic?
Or how can it be simulated more properly and how is it simulated at the moment? THOSE are questions to be asked first instead of shouting out “it dooooesnt woooork”.I am long enough in this bussiness and have seen many other countermeasure simulation “fails” before with FATAL results, because not many could bother to address basics first while overly confident rushing into editings and moddings based on self-proclaimed expertise and without being evaluated by others.
You guys point to a “problem” or “bug”… that´s fine with me… and i am not interested in arguing about it, but if so, please present well educated reasoning of WHY plus alternatives of better solutions based on FACTS of reality.cheers
PS: And also keep in mind that 4.32 is friggn old, so don´t kill yourself over it. Leave the guys a bit more space with more faith … and wait for 4.33.
-
To be fair to all sides, nobody has provided real-world data on either side of this debate.
-
To be fair to all sides, nobody has provided real-world data on either side of this debate.
And nobody will, otherwise, I close thread and delete it.
Real word data are not public on this specific area.
-
I simply cannot accept the current ARH code.
This is actualy another point. My initial remark was about chaff effectiveness on ARH seekers and your statement about their immunity to chaff.
-
This is actualy another point. My initial remark was about chaff effectiveness on ARH seekers and your statement about their immunity to chaff.
What I cannot accept is the buggy state. That is all nothing else…
-
What I cannot accept is the buggy state. That is all nothing else…
But now, since we “know” that immunity is not a bug, what are the other the problems?
-
Does this mean that what I experience is inentional that chaff chance value in DB ARH is just an ornament while in all other ever Falcon version have purpose. In this case the value of BMS4 is strongly reduced me in AMRAAM era… I planned to make '90s variant of my MOD but in this case I never will do because totally pointless. I cannot accept holy weapons in any simulator. Anyway it is quite “funny” that small and very limited capability radars on missiles are immune to chaff wihle far more capable aircraft radars are not…
It is also funny to hear that something cannot be jammed or 100% resistant while the RL have proved the opposite…
-
IMO better wait for the next release… and check again.
But basically yes, ARH must be nearly totally immune to chaff. (No information about how it is modelled in the code and what is the relation with the database.)
-
Does this mean that what I experience is inentional that chaff chance value in DB ARH is just an ornament while in all other ever Falcon version have purpose. In this case the value of BMS4 is strongly reduced me in AMRAAM era… I planned to make '90s variant of my MOD but in this case I never will do because totally pointless. I cannot accept holy weapons in any simulator. Anyway it is quite “funny” that small and very limited capability radars on missiles are immune to chaff wihle far more capable aircraft radars are not…
It is also funny to hear that something cannot be jammed or 100% resistant while the RL have proved the opposite…
I agree, even aesa radars are not immune for jammers …
-
But basically yes, ARH must be nearly totally immune to chaff. (No information about how it is modelled in the code and what is the relation with the database.)
“Must” be? From DB perspective? I don’t see why 0.0 can’t mean totally effective chaff and 1.0 no effect. And linearly on that interval.
Back that up, no offence intended but code and modelling complex chaotic events with many unknown variables in reality according to some idealization isn’t your area of expertise.
The fellow with a grudge against me, @Mav-jp is the expert here.
-
The problem with modding is… if modder or theater-maker nameX, nameY and nameZ make all different:
- sam missile performances
- FMs
- a2a missile performances
- chaffs and flare values
- radar values
- jammer values
- etc.
- etc.
in 3 different theaters (X,Y and Z), because each theater-builder has his own opinion how things “should be”… then NO pilot out there has a consistent and globally applicable tactical trainings environment anymore.
I completly understand that open progess is important, but progress can also be destructive if done wrong, because what one trains in theater X will not work tactically in theater Y anymore and so on and so forth.
Like we had it with FreeFalcon and OpenFalcon; Chaffs, notching, groundclutter… fekk, the whole BVR was different in one and completly different in the other… thus me going back to AF tbh.
This is very important and also a reason imo., why changes on performances should be set as global standards, meaning made by BMS itself. May it be due to suggestions by or by the help of modders or not. If “bugs”, “fixes” or suggestions are really valid and well elaborated… then they will make it more likely into the brains of others and also into a release.@Molni: S!
Molni, we are theater makers and we have the freedom to take what is given and to create awesome theaters out of it, but i think we also have a responsibility in how far we can (or should) change things. Difficult, because responsible openness, communication and coordination required here…while our ego is put aside. Of course, me too have some other thoughts and certain ideas how i could change much more than i do, but i have to ask myself, if that is good or bad on a global perspective, meaning while trying to improve something for myelf i might ruin it for all accidently. This is why i never “touch” (or “change” for the better choice of words) performance related values at all.
If it is just a private offline test theater than there are no problems, but as soon it is published, many pilots out there will be confused why certain tactics work in theater A but not in theater B.I hope this makes sense.
-
well this is the beauty of it.
No one can ever say for 100% sure this is right this is wrong.
Specially in this area where most data are classified and most data edits are done by info from “trusted” sources. Now those “trusted” sources in some case might be misleading, not on purpose but cause of lack of information or they think they know all.
Since for now the system can’t ever simulate things 100% we r good at what we have best from sources by trusting them.
Now others say no this is not correct this is wrong etc… Well we r walking on an area where we know nothing. And most of us know that official numbers many times ain’t true and hard to find.
BMS is giving the base to work on. If u want to alter those values based on your sources u r free to do so. By having alterations from theater to theater this is ok I believe. What is more accurate? no one knows. For sure every airforce has differences and uses different tactics and approaches on the same subject.
The trick ain’t only to “play” by the numbers but tactics. Numbers r there, x or z or y the differences we all talk here ain’t that vast and u learn them quickly… The thing is how u react and when on those numbers.
-
Since for now the system can’t ever simulate things 100% we r good at what we have best from sources by trusting them.
This is why should controlled even the “immunity” via DB values and not only by the code…
-
well this is the beauty of it.No one can ever say for 100% sure this is right this is wrong.
And no one will. Falcon 4.0 doesn’t aspire to simulate a complex, chaotic universe. It can be “good enough” but never will be “right”. It’ll always remain “wrong” as it is now.
In another words, you’re missing the point.
The trick ain’t only to “play” by the numbers but tactics. Numbers r there, x or z or y the differences we all talk here ain’t that vast and u learn them quickly… The thing is how u react and when on those numbers.
Tactics that work in a situation or adhering rigidly to some SOP (of which half doesn’t apply anyway due to sim scope) adapted from real life?
-
Tactics that work in a situation or adhering rigidly to some SOP (of which half doesn’t apply anyway due to sim scope) adapted from real life?
Yes and No.
-
The issue is that the radar seeker code for ARM reaquires a lock after X time (this is not editable in DB , I don’t think there RL data on this so going to be hard to model.
The other issue is how seekers scan angle , mimic’s the AC platform radar deg for many weapons, so seeker has 60deg which is more than RL but the code can’t handle real life data from what I remember .
So its very easy for missile to reaquire even with heavy turn/break etc . -
And no one will. Falcon 4.0 doesn’t aspire to simulate a complex, chaotic universe. It can be “good enough” but never will be “right”. It’ll always remain “wrong” as it is now……
Well, that’s why it’s a ‘simulation’. Someone said (Gillman Louie or Bonanni) that to perfect the simulation, you have to build the airplane. I’m looking, but I don’t see an F16 parked in my living room.