quyes

That was my first thought, so I stripped that and all other throttle axis bindings. No change. I actually deleted every input .lua with the exception of default.lua and that did the trick. I tried adding them back one by one to see which one was causing it, but of course they all ended up getting put back and everything was still working happily. I just finished a pattern around the carrier (and right into the back of it) so all of my controllers are now back to fully functionality. While I'm not sure what specifically caused it the conflict, I now know how to fix it.

I didn't test thoroughly enough. I tested with only my joystick plugged in. I came back later tonight with my full setup and the problem resumed. I've now tested by removing one peice of hardware at a time. I found that as soon as I unplugged my Warthog throttle the joystick y axis resumed functioning again. Now that I've got a little bit more of an idea where the conflict seems to be I'm going to keep testing (I'm going to try deleting the throttle .lua) to start. I'm still open to suggestions.

I'm running MT preview 2.8.3. The deletion of "Joystick - HOTAS Warthog.lua" from the F14 config did the trick. Thank you!!

I have just come back to the F14B. I took off only to find that I could only control my pitch via the trim. No big deal, I go into controls to find the issue. I find a red exclamations over both the pitch label and the controller binding. I figure it's an easy conflict that I just need to resolve so I mouse over the controller binding to find the conflict. However, to my surprise the pop-up only says "joy_y" which is the listed value in the mapping (joy_y on my warthog stick). My next step is to mouse over the red exclamation for the pitch label, maybe I can get some information about the conflict there. Nope, the pop-up just says "Pitch". So here's where it starts to get really strange. I remove my joy_x mapping from roll (which when used as roll is working fine) and map it to pitch instead. It also gets a red exclamation and a mouse over pop-up that says "joy_x" and the red exclamation remains on the pitch label that still says "Pitch". At this point I figure pitch has multiple mappings. So I remove joy_x and check for any other pitch mappings... ...there are none. With pitch completely unmapped on all of my controllers the red exclamation remains over the pitch label and when I mouse over it the pop-up still says only "pitch". Anyone have any thoughts?

Thank you so much Flappie. The file system scan followed by the slow repair did the trick. I've now had NTTR running in the mission editor for 1.5 hours with no issues!

I ran the scan per MS. It found, and corrected, errors. A retest showed no change in behavior. I then ran the scan a second time, it came back with no errors found. The logs still show "in_page_error" combined with "io:FileStreamOpen". Updated logs: dcs.log-20221129-162118.zip

Thank you Flappie. I'll dig into that some more. I was suspecting it was probably some sort of hardware issue.

I'm only experiencing this issue with NTTR. It happens both when opening pre-designed missions as well as new blank missions. I've tried a repair, and updated my NVIDIA drivers, no change. It's been a while since I've been in the NTTR so I'm not sure when this started. I feel like I'm beating my head against a wall. Any suggestions? dcs.log-20221129-011517.zip

I tried searching to see if this was already requested, apologies if it was. It may even be something slated for the final release already. I just came back from a decent DCS break and jumped back into the Apache. Struggled with George a bit as I couldn't remember all of his commands and the menu only showed a couple of the options after taking off from a cold start. I eventually remembered that I had put them all into a table in my kneeboard. This got me thinking, it would be really great if the George menu dynamically updated with all 8 of the current available menu commands (IE: up, down, left, right, short, and long) for quick reference as we fly and interact with him.

Are you using flight's that you set as being flown by "Player" only, or are you using Combined Arms to take control of AI flights? If I recall correctly the flight plans are generated slightly different for flights set as AI in Liberation as opposed to those set as "player" with he AI ones were missing the required settings for the wingman attack mission commands. It's been a while since I looked at these so I may be off though.

I'm not sure if it works the same way in the current version. In previous version you could set the AI flights to launch at +00 and then set the player aircraft to +XX (however later you want the flight to leave). Once the mission starts you can then use time compression to get to the player spawn time and you'll get spawned in at that time. There is no way, that I'm aware of, to start right at the player spawn time with the AI partially into their flight plans.

Hey Kohpa, I'm really enjoying the new release. I've got two items for you. 1. For PG - Iran Invasion I've got both US tankers being created in the ME with Tacans of 98X. The briefing is showing them as expecting to be 60X and 61X. 2. The Iran force is spawning the Hawk battery with a single Vulcan unit. However, the default Iranian army in DCS does not have the Vulcan in it's unit list.

The deck crew only interact with the aircraft connecting to, and launching from, the cats; so for helos there is no deck crew interaction. In terms of the ATC interaction, I would suspect that the radio calls will work with helo's for owners of the SC module (I haven't actually tried it with my helos yet). However, my understanding is right now that you'd be given instructions to fly the fixed wing approaches (case I/II/III) and not helo approaches (I'm not sure if the RL helo procedures are different, I'd imagine they are).

Hey Khopa, I'm really enjoying the newest RC. Can't say enough how great the work is. I really like the carrier BRC alignment with the wind now, it's been working very consistently. However, I'm noticing one issue. The wind seems to be reversed 180 degrees from what's desired. The wind is always blowing straight down the carrier but as a tailwind. I suspect the issue is that the mission editor uses the direction the wind is blowing to, rather than the norm in aviation of reporting where the wind is blowing from. So the carrier direction needs to be the reciprocal of the wind direction in the editor where as in real life they would be the same. I'm not sure if it matters but I've seen this in every mission so far but I've only tested using the PG - Iran invasion map with the SC.

Khopa, I'm really enjoying Liberation. I can select my primary mission (Strike, CAP, SEAD, etc.) that I want to focus on for that flight, but I really have to keep my head on a swivel in a way that's just not present in the default missions/campaigns. I'm also able to use my DLC maps along with the SC. This way I don't have to take the time to create my own mission, and I also have no idea what the enemy is doing like I would in my own missions. I don't think I've had a mission yet where I haven't had to defend myself or fall back and then recommit on my mission target. A couple of QOL improvements I'd recommend (if you don't already have them in the works). 1.) If possible could the carrier, AWACS, and tanker comms be pre-programmed into the mission aircraft? 2.) If possible a check on the wind direction in comparison to the carrier's BRC. I just flew a mission with a 113 degree crosswind compared to the carrier's BRC. My hornets flight path indicator was out of the constraints of the HUD. Thanks for the great utility and keep up the great work!!! Liberation has returned my interest in DCS.