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.

I think I've figured out the root cause of my issue as well as a workaround. I have three DCS directories on my system. 1. D:\Eagle Dynamics\DCS World: My initial stable install now converted to an OB install. 2. C:\Users\<USER>\Saved Games\DCS.openbeta: An OB saved games directory created when I converted #1 from stable to OB. 3. C:\Users\<USER>\Saved Games\DCS: My initial saved game directory from the initial stable install. I've configured my DCS installation to use my saved game directory #3 instead of #2. Liberation is picking up and writing the mission files to directory #2 which is not used. If I run the mission from directory #2 I get the script error on mission exit. However, if I move the mission file from directory #2 to directory #3, launch DCS, and then run the mission everything works great! For now I'll just manually move the mission files generated by Liberation until the next RC is released in which khopa has stated will allow us to manually specify the saved games directory which should fix the problem for me.

Thanks Dan. I missed that reply from khopa in my searches. I've compared the contents of <dcs>\scripts\missionscripting.lua and <liberation>\resources\scripts\missionscripting.lua, and they are both identical. I've also verified that liberation is rewriting <dcs>\scripts\missionscripting.lua each time I launch liberation.

When I exit the mission I get the following mission script error and Liberation doesn't detect the mission ending. [string "local jsonlib = [[D:\DCS Liberation Dynamic Campaign\resources\scripts\json.lua]]…"]:24: attempt to index global 'io' (a nil value) stack traceback: [C]: ? [string "local jsonlib = [[D:\DCS Liberation Dynamic Campaign\resources\scripts\json.lua]]…"]:24 in function 'write_state' [string "local jsonlib = [[D:\DCS Liberation Dynamic Campaign\resources\scripts\json.lua]]…"]:61: in function 'f' [string"--[--…"]:1534: in function 'onEvent' [string "Scripts/World/EventHandlers.lua":13:in function <[string "Scripts/World/EventHandlers.lua":11>

Solution: I missed adjusting the start time and just had to wait. I think I'm doing something wrong. I went through and configured my first mission for an F18 flight off of the SC module. The mission file was created. I loaded it in the mission editor and launched the mission. The mission starts and prompts me to pick my slot (F18 or tactical commander). After selecting the F18 slot I'm not spawned into an aircraft. I did notice that the F18 mission I selected was not set to occur for 52 minutes. The briefing says the start time is 17:00 and the mission starts at 17:00 when I load the mission. Do I need to wait until closer to 17:52 for the aircraft to spawn?

Sure this makes sense.... 1 A10-C I is released. 2 F/A18-C is released, kill A10-C I 3 F-16 is released, kill F/A 18-C 4 A10-C II is released, kill F-16. ...and that's just a limited list. Unless your suggesting DCS should only ever contain 1 aircraft from each vendor (IE 1 from ED, 1 from RAZBAM, 1 from Heatblur, etc) then this logic is on slightly shaky ground and a very slippery slope. For me, I'm pretty sure ED is capable of supporting multiple aircraft. They kind of have to if DCS is going to continue to offer us a breadth of aircraft to choose from. :) With that said no ones perfect, there will always be bugs introduced as we continue to get updates. The only other option is to let all of DCS go stagnate.

The video you linked shows exactly what Victory is talking about. As each aircraft approaches the end of the deck (also the end of the cat acceleration) the elevators are at full deflection. Then as soon as aircraft leaves the deck/cat and is no longer under the acceleration of the cat the elevators immediately return to their trimmed T/O position near neutral (as compared to the full deflection they were at). So if you're holding full aft stick to simulate what you're seeing in the video, you need to release that aft stick pressure as you come off the deck to also simulate what you're seeing. If you continue to hold the aft stick pressure after coming off the cat then you're deflecting your elevators more than what's in the video and of course you'll stall out.

I own both modules. Like others have recommended, buy both if you can. However, if you can only get one at this time here's my recommendation: The bug should be your choice if you want to work more with the systems than flying the aircraft due to FBW and the amount of tech. in the pit. The cat should be your choice if you want an aircraft that you really have to fly over managing systems as its few systems are fairly easy to manage and it's a true "pilot's airplane" (of course there's more systems if you decide to go RIO over pilot). The bug should be your pick you looking for a broad multi-role capability, it's a true jack of all trades. On the other hand, while the cat can do attack missions it really is an air-to-air platform first and foremost being designed around it's radar/phoenix combination. I routinely fly both in one evening and make my choice primarily based on the differences above. Both are great fun!

Today I used the ejection function for the first and second time, both in single player. I happened to be looking in my F-14 Logbook entries after and I noticed my ejection count was listed as 4 rather than the expected 2. It looks like the logbook is adding in the RIO's ejection counts on top of the pilot's ejections, resulting in the logbook doubling the actual count.

I can confirm what SiThSpAwN is seeing is the same thing I'm seeing as I reported in the thread referenced by PitbullVicious. I've included the my log files and system info in the other thread, I can throw together a track to go along with Sith's if ED would like.

I get this same issue with my A10Cthrough TGP using BHOT and WHOT modes. dcs.txt debrief.txt Sys Info.zip