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.

I'm also having issues with the AI co-pilot not firing the M134, even when set to free fire ROE. I've tried a new mission with the me as the pilot never lowering the pilot sight. I've even tried in a new mission moving to the co-pilot seat, lowering his sight and then moving back to the pilot seat, and he still won't fire. Interestingly in this scenario when you lower the co-pilot sight then migrate back to the pilot seat, the AI co-pilot seems to track targets with his sight, but just won't fire. === Could this be an issue with incomplete implementation of the new "show crew indicator" (picture of helo and crew in lower left of screen)? In the Mi8 this new "show crew indicator" has taken over the old "AI panel show/hide" (coloured text in lower right of screen), for setting crew ROE. In the Huey, the old "AI panel show/hide" still exists in conjunction with the "show crew indicator". In addition, the Huey "show crew indicator" does not show co-pilot ROE, nor the door gunners ROE or even presence at all. ==== I've had no issues with the Huey AI door gunners firing with either the M134 or M60. EDIT: I take it back. side gunners are not firing in MP, with either the M60 or M134. No problems so far in SP though.

Switching the Mig21 radar from standby to active causes large intermittent drops in FPS. This can be visualised by the sensor output from GPU-Z below: Note the intermittent spikes then drops in GPU clock speed and VDDC. Also note that no PerfCap reasons are specified e.g. Thrm, Pwr, etc. = does not seem to be GPU throttling due to voltage, high temps, etc. Mig21 radar on in SP: F16C radar on in SP: My specs: P750TM-G laptop OS: Win10 x64 v2004 (latest) GPU: NVIDIA RTX 2080 GPU Drivers: 452.06 (latest) CPU: i7 7700 RAM: 32GB HD for DCS install: Samsung SSD 860 EVO M.2 2TB DCS 2.5.6.52437 Have also tried disabling G-SYNC and older NVIDIA drivers. All NVIDIA driver installations done after DDU clean via Safe Mode. DCS folders 'fxo' and 'metashaders' also wiped after each NVIDIA driver installation. DCS log: https://www.dropbox.com/s/os2kast961iuhf7/Mig21.stutters.dcs.log?dl=0

Agreed. Tankers should not reveal ground unit positions.

This seems fairly complex as there is many different ways and areas to damage the runway c.f. repair which is just removal of the decals and the associated 'sink into ground' effect. However taking this suggestion further for the sake of server owners: In addition to repair, it would also be good if a mission flag could be set to allow or not allow runway damage entirely. This would flag would be beneficial for more dogfight orientated servers.

Just because it's added as a feature for mission makers to utilize, doesn't mean they have to use it.

This is needed and would very much be appreciated.

+1

A clear method I've found to avoiding this bug on MP servers where pre-aligned INS is allowed: 1) Start-up harrier but do NOT switch "INS Mode Knob" from OFF 2) Select EHSD 3) Select Data on EHSD page -> Data should now be boxed 4) Switch "INS Mode Knob" from OFF to NAV 5) Enter "77" (or any other number > 1) into UFC and pres ENT 6) Enter coordinates for WP #1 as normal If you start-up the Harrier, switch the "INS Mode Knob" from OFF to NAV, then press Data you will CTD. I'm unsure if the existing 'you must have an existing WP to enter subsequent WP in MP' bug and subsequent workaround by pressing Mk0 (=Markpoint #1) on the EHSD page still exists, but it doesn't seem like it.

Repair still does not seem to be working with minor or major (missing landing gear) damage, despite engine and power being off and ground crew acknowledging with "copy".

Related: AIM-54 launch in PD STT = no active guidance? (@ DEVS)2 AIM-54 Guidance