mad rabbit

+1 for Huey and Mi8

+1

Also occurring for me only after a few BRM shots. Won't work in manual/auto either. I did wonder if it was related to high G maneuvers but then the TGP itself would also stop working right?

I've also been experiencing this issue with the MP chat dialog keys following the DCS v2.7 updates ...along with the infuriating introduction of freezing aircraft controls whilst this MP chat dialog is open (who even asked for this?!).

As originally posted here but reworded for this sub-forum: I regularly fly online in the Viggen, another HeatBlur module. However when I'm running v2.2. of the Waze F14 v2.2 texture mod and then get into a Viggen on a MP server, I get ejected due to an integrity control (IC) failure for a Viggen texture?! I run about 20+ mods, including Devrim's English translation for the Viggen, which seemed like the initial obvious reason. However after isolating each mod individually through OVGME, I eventually discovered its v2.2. of this F14 mod causing the Viggen IC failure. Even when I do a full DCS repair and then only run this mod and nothing else, the IC fail occurs. Notably, the IC fail only occurs when I run this mod and then also switch role to a Viggen on a MP server. I can run the Waze F14 v2.2 mod and play all other modules on a MP with no issues. The only thing I can think of is that because they are both Heatblur modules, then there must be some shared textures. However this doesn't make sense, as why would one modules textures be dependent upon owning anothers? Why am I simply not getting the IC fail for the Waze v2.2 F14 textures?! Does anybody else own the F14 + Viggen and run this mod? Have you encountered this IC issue? Sadly this is the only mod I have had to disable due to IC failure, despite being very weird and specific in origin. 2021-09-09 02:33:45.822 WARNING SECURITYCONTROL: IC fail: textures/hb_vig_mirrors_fake @ mods/aircraft/ajs37/textures 2021-09-09 02:33:45.822 WARNING SECURITYCONTROL: IC fail: textures/hb_vig_mirrors_fake_roughmet @ mods/aircraft/ajs37/textures

Love this mod but I'm encountering a really unique problem with it. I regularly fly online in the Viggen, another HeatBlur module. However when I'm running this v2.2. of this mod and then get into a Viggen on a MP server, I get ejected due to an integrity control (IC) failure for a Viggen texture?! I run about 20+ mods, including Devrim's English translation for the Viggen, which seemed like the initial obvious reason. However after isolating each mod individually through OVGME, I eventually discovered its v2.2. of this F14 mod causing the Viggen IC failure. Even when I do a full DCS repair and then only run this mod and nothing else, the IC fail occurs. Notably, the IC fail only occurs when I run this mod and then also switch role to a Viggen on a MP server. I can run this mod and play all other modules on a MP with no issues. The only thing I can think of is that because they are both Heatblur modules, then there must be some shared textures. However this doesn't make sense, as why would one modules textures be dependent upon owning anothers? Why am I simply not getting the IC fail for the Waze v2.2 F14 textures?! Does anybody else own the Viggen and run this mod? Have you encountered this IC issue? Sadly this is the only mod I have had to disable due to IC failure. despite being very weird and specific in origin. 2021-09-09 02:33:45.822 WARNING SECURITYCONTROL: IC fail: textures/hb_vig_mirrors_fake @ mods/aircraft/ajs37/textures 2021-09-09 02:33:45.822 WARNING SECURITYCONTROL: IC fail: textures/hb_vig_mirrors_fake_roughmet @ mods/aircraft/ajs37/textures

+1

UPDATE 24/01/21: Full refund through PayPal dispute resolution after no response from TrackHat.

Some relevant poor reviews of TrackHat from others, following my cross-post in reddit:

Sadly I don't think so, unlike MilesD and the PointCTRL devices (which I'm definitely getting next once he's finished V2). Even if TrackHat did have a Discord, I would hope that 2 x emails directly from a customer, in addition to an email from PayPal dispute resolution, would be a more professional form of contact than a game-centric chat program.

Oh of course the site is running. otherwise I would not have been able to place the initial order that I'm now disputing. However with no updates on the order for a month despite 2 attempts to contact them, nor updating of my online profile with said order, the "website being up" in my opinion is not clear indication that my order is being processed, let alone that the company (most likely 1 guy + 3D printer) is even operating.

Is TrackHat still operating? https://www.trackhat.org/trackhat-clip-plus I purchased a version #1 of the TrackHat Clip Plus in 2017. I received shipping information 2 days after and the product not long after that. As I have been playing a lot of DCS lately, I thought it would be better to order a second so that I can alternate charging. The version #2 also seemed promising in that it had a smaller design and better battery capacity. Placed order in Dec 2020. I never received shipping information nor was my online profile on the website updated with the order. Sent my first email at the end of Dec 2020 requesting order update. No response. Sent a second email in Jan 2021 again requesting order update and stated that if I received no response I would be seeking a refund through PayPal dispute resolution, which I sadly had to initiate today. UPDATE 24/01/21: Full refund through PayPal dispute resolution after no response from TrackHat.

Agreed that this was the solution. I'm also unsure if doing this pre- or post-INS alignment has an impact, which it shouldn't from a systems perspective in either case, and thus again only dependent on whether Jester is setting-up other systems at the same time. EDIT: pre-INS alignment works fine as well, as long as the waypoints are submitted to Jester only after each one is complete, and not during the first 7secs of the alignment when he is entering in the current position. That being said I can recall a few patches go being able to submit, if not "queue-up", several waypoints for Jester to enter at once, during INS alignment no-less, with no problems. From a coding perspective, it also seems illogical that Jester cannot be given a queue of commands which are prioritized i.e. waypoints are only entered-in after he has completed entering in stored heading for INS alignment, without them getting 'jumbled-up'.

I'm also having this problem, even after waiting for Jester to complete startup including INS alignment.

Seems to bring up the communication menu for all channels unfortunately. For those of us who routinely use SRS, it would be good to add an option in the 'Special' menu that prevents the communication menu from being opened when utilising the radio (and to a lesser degree) ICS triggers. Heat blur have add numerous options in this regard for the F14, so this should be able to be implemented.