Jar72

Thank you. Regarding the HOJ, I'm sorry, after several evenings of research, I cannot find any official information. I took it for granted as many many peole mention it, but I have no evidence to show.

Dear ED teams, I have seen recently a post regarding incorrect mass after recent API update. I took the liberty to further dig into the subject after being hit by shots in HOJ mode by F-4 with Aim-7F. The F-4 was notching at 90-110° (so no lock on me) and I still got hit without RWR warning. Track is 90 Mb, so I can share with separate file if needed. My understanding is that irl HOJ (without aircraft guidance) is functional on -MH and -P versions only. But it seems -F and -M are equipped with HOJ also. I looked into the file "aim7_family.lua" and found the line "hoj = 1" for all these versions. I guess this explains it. By doing comparison on data (I tried to reverse engineer to understand, but I don't to be honest), I also found differences on other parameters. On versions -M and -MH, there are parameters set as "sensors", with height error lower than on "seekers" parameters. I assume these are for shorter distance, with better guidance or proximity fuse. The "sensors" parameters do not exist for the -P. Also, same reasoning for paramerters such as "gimbal" and "ap", they are not there for the -P. So I guess missile -P has a default behavior for these missing parameters, and thus behaves worse than -M and -MH in specific areas. Areas that I don't know about. I am not sure if all this is correct, nor do I know if that is realistic. But I saw it, so I thought I could raise it and maybe help to fine tune the missiles without too much workload, that is: removing hoj for -F and -M, and adding the missing parameters for -P. If that is indeed correct. Thank you very much in advance for taking care of Fox-1, many cold war enthousiasts like me appreciate it very much. JAR. Example Aim-7 M sensor = { delay = 0, op_time = 80, FOV = math.rad(12), sens_near_dist = 100, sens_far_dist = 60000, ccm_k0 = 0.2, aim_sigma = 4.0, height_error_k = 25, height_error_max_vel = 60, height_error_max_h = 300, hoj = 1, }, seeker = { delay = 0.6, op_time = 75, FOV = math.rad(120), max_w_LOS = math.rad(20), sens_near_dist = 100, sens_far_dist = 30000, ccm_k0 = 1.0, aim_sigma = 5.5, height_error_k = 100, height_error_max_vel = 138, height_error_max_h = 300, hoj = 1, }, aim7_family.lua

I confirm, same for me, fast repair and Marianas is downloaded and working fine. Thank you very much ED for the very quick fix, during a weekend !

Hi. Same problem. Same messages. Terrain folder also disappeared from hard drive. Full re-install of DCS does not solve it. Thank you in advance for your support.

Hello guys. I have been flying since 3 years, almost day to day, on this dream-come true F-14. And today, practicing landing in Blanker's mission, in the F-14 A, I started a sh... hot break. I got myself a sweet 3-wire, on speed + on altitude + on center line from close. The rare kind if you know what I mean. And guess what Jester said for the 1st time? "Cobra would be proud of you". Such a cool easter egg !!! I had not known it existed. Heatblur team, hurray !!! Cheers. JAR

After training since... forever with your mission. I decided to try what would happen with a sh... hot break in the F-14. Thank you for this nice EASTER EGG in this must-have mission !!! I did not know it existed I also got a cool easter egg from Jester by the way, who said for the 1st time : "Cobra would be proud of you". (Cobra is in HB team).

Oh man, you are killing me! Lol. Of course, fully agree. I googled it quickly, I don't know where the - 24 came from then ! I was in south atlantic map for the tests though... 44 degrees celcius not common there. I don t remember exact reference temperature, but still pretty similar results between dcs and the tas calculator. Anyway, i think I got the answers I needed, no need for me to re do accurate tests to prove dcs is rightly modelled or not. The point of this thread was to understand where the difference came from when assessing bandit ias based on closure rate. I believe we all made good points, don t you agree? Thanks. Jar.

Sorry but I kind of disagree about the standard day being rare, or about not being standard model in the t'as calculator. If you want to be purist, let me clarify what I had in mind then please. To prevent misinterpretation of the limitations, or rather non limitations in this case, of dcs. I was referring to temperature of air varrying with altitude. When designing aircrafts for instance, you use standard atmosphere model, with a temperature gradient based on altitude. I tend to think dcs has a kind of a model for the atmosphere as well, based on the standard, with variation of the reference point depending on weather conditions. These standard models are pretty representative of real conditions, when setting the ground pressure and temp to match actual weather values. In the calculator, if I use the standard temperature at 12 000 feet, around -24 degrees celcius, I have the same values for tas than the ones I measured in dcs, with similar weather conditions than standard. So I m happy, all seems consistent. The screenshot above shows a temperature of 20 degrees at 12 000 feet. Therefore it explains the difference with my tests in dcs. For the fun of it, making the calculation with 20 degrees celcius at 12 000 feet means you will be in a really hot atmosphere, like 60 degrees celcius on the ground. I don t think this place exists yet. If the calculator and dcs do work as I think now, I m happy, all is consistent. And this shows dcs is actually quite representative of what an aircraft sees in real conditions. And we surely can close the topic. If not, then huh huh. I m still missing something. Thanks and see yah!

Strange, I did not find the same results. I had twice less... EDIT : Got it! Strange as it may, you have to change the temperature by yourself in this tool. It is not per standard atmosphere model, or so it seems.

Hello again, Definitely spot on @Dragon1-1. I went back to theory, and indeed, TAS (True Air Speed) depends on altitude (pressure). I totally forgot about all that. As we are doing a substraction to assess his speed, we don't mind about wind, and therefore ground speed difference will be equal to true speed difference (unless we have a different wind at each's location !!!). Assessing the bandit speed is a bit more tricky than what I thought then. I'm sure there is a formula, the same kind of thing as for Mach depending on altitude. But I did a quick test in DCS to get rough numbers and define a rule of thumb. My findings : At sea level, TAS = IAS. At 10 000 feet, 300 knots TAS = IAS +45 knts At 10 000 feet, 500 knots TAS = IAS +60 knts At 20 000 feet, 300 knots TAS = IAS +100 knts At 20 000 feet, 500 knots TAS = IAS +125 knts So, to evaluate bandit's speed based on closure rate, my rule of thumb will be : Sea level : bandit = closure - my_speed 10 k : bandit = closure - my_speed - 100 20 k : bandit = closure - my_speed - 200 This way, you know if bandit is slow or fast, and you can choose 1 or 2 circle. Thanks again, it felt good to go back to "good old physics laws". JAR Thanks !

Right, but not sure the difference between ias, tas, gs would be so much, specially with no wind. We were a bit high, around 12k feet. At sea level, it should be very close (the same ?) if I remember well. I ll play the replay and double check with ground speed indicated in tid in both aircraft. I ll keep you posted. But I think you are spot on. Thank you for your quick reply. It helped me moving forward on my issue.

Hello all and Heatblur team, I was doing some BFM training with friends. I was assessing bandit's speed to verify he was on the target briefed speed. I checked radar on TID and the closure rate. There was approximately 100-150 knots difference compared to what I calculated. My formula is simple : bandit speed (IAS) = closure rate - my speed (IAS). Is my formula incorrect ? Is it something normal ? Maybe I did not read the numbers correctly ? Ex : me = 460 kts, closing rate = 1050 kts, bandit calls on the radio he is at 460 kts. Not 590 ??? Thank you for your help. I did not find anything on the forum nor Internet. JAR PS : We do have 1 mod installed on our server : "range targets mod". Would that introduce a glitch possibly ? PSbis : track file is 110 Mb, I cannot send in the forum, but I'll be happy to share a link for download.

I recommend it. Beautiful drawings and nice tribute.

Ejection handle is now operational. Easy and cheap with a pull lever switch. I can share the 3d prints design if some are interested. I hate to admit, but it is useful sometimes...

Hi Horns. Don t worry, no offence taken ! Thanks a lot for apology and taking the time to write back. Thank you also for wanting to answer my question on the first hand. My apologies on my side also, as sometimes we can be quick to react on forums. We are all aviation enthusiasts after all. See you!

Well, sometimes, one does not read every post of a thread in detail... Sorry, I don t understand math symbols the way your are using them. Writing a sentence usually is better for understanding, or a simple sketch. Yeah, I m old school. Anywhooo, thanks Joe, much appreciated sharing your library. I did not know a lot of them.

Agreed about the "sterile discussion". Thanks for your reference, the perfect answer to this post. Are you referring to "the pentagon paradox" ? I found several other books. Would you recommend to read it for a tomcat enthusiast? Or is it off subject? Cheers.

Your statement depends about what you consider. Bombcat is more superior than Hornet whithout a lantirn for instance, for precise bomb delivering. But it cannot deliver Harpoons, harms...

I disagree with the #6 versatile stuff. Bomcat in Afghanistan scored 90% hit rate during the first 3 months. Also, it actually lasered targets for hornets, as these did not have lantirn (EDIT : Hornet had Nighthawk pod, which had a lower resolution) ! And they can carry more payload and farther than hornet. And also for the #4 good dogfighter. Good pilots in tomcats can rip F-15s. A nice unofficial picture shows it, with an F-14 piper right on a F-15 pilot.

I know he never answered my message some months ago... Not sure he is willing to share anymore (that s his right of course).

Ahah. Indeed, The room used to be my daughter's. I thought : first the pit, then we will see to decorate.

Apart from a few details, it is complete and fully operational. The real fun begins and it s awesome.......... @AusMumbles thanks for sharing your initial model, and of course, to HB and ED, for basically everything. @AusMumbles

This also led to interference with my computer mouse…... So. When you were pushing the Cat, the mouse ran away ?

Hi @Nightdare, Here are my rotary encoders. https://www.amazon.fr/dp/B07SV5HHM5?ref=ppx_yo2ov_dt_b_fed_asin_title And here is how I mounted them on the panel on the pic below. Nothing fancy. There is just enough space to tighten the nut with pliers. Works like a charm. Cheers. nullJAR

Hello, I'm using DCS-BIOS to bind the switches to the game. I could not find these bindings for the F-14, but they are really convenient. For the AP engage and the X/Y tacan mode, these bindings exist with a rotary encoder instead of a switch. Here is the code I added in the F-14.lua file, in MOD\Script\DCS-BIOS. Also, I removed this original line : defineFixedStepTumb("PLT_TACAN_CHANNEL", 47, 3336, 2043, 2, {-1, 1}, {-1, 1}, nil, "TACAN PILOT", "PILOT TACAN Channel XY") It works for me. Hope this helps, thanks. JAR PS : Of course, in your Arduino code, you need to define new functions with the sentences passed ("ON_THE_BALL"...). Ping me if you need a hand, as it is not that obvious at first. -- Carrier "Tomcat on the Ball" definePushButton("ON_THE_BALL", 2, 3749, nil, "Communications", "Tomcat on the Ball") -- Carrier departure "Salute" definePushButton("SALUTE", 18, 3023, nil, "Communications", "Salute") -- Cockpit open canopy definePushButton("CANOPY_OPEN", 12, 3183, nil, "Cockpit", "Open Canopy") -- Autopilot Engage defineToggleSwitch("PLT_AUTOPLT_ENGAGE", 22, 3041, 2112, "Autopilot", "Engage autopilot") -- Tacan X_Y defineToggleSwitch("PLT_TACAN_CHANNEL", 47, 3336, 2043, "Tacan", "Mode X_Y") What a mess. 2 sides done, 1 more to go with the center.