Deezle

I've downloaded the latest version and now I'm unable to save a profile without Ikarus crashing.

I finally updated my TS after months of that problem and it's fixed for me. As with my post from months ago, I'd suggest using an older version and tell the devs on the TS forum that you're still having the problem.

I'll roll in on a Shilka with the gun every time rather than waste a bomb or mav that I could use on a tank or SAM.

Great if it's stationary. I've had to deal with a few moving Tors lately and they're real bears to kill, you have to pop up and hope you acquire it and launch within about 10 seconds and then get the hell out of dodge.

Should be the same button as the NWS and master mode buttons.

Everything on the A-10C MFCDs and CDU that I can think of needs to be typed in the scratchpad before the OSB/LSK is pressed. It's a little counter-intuitive at first but you'll get used to it.

I realize there is no perfect solution, and we shouldn't reward dumbasses who drive on the grass because they're in a hurry, I was simply pointing out that sometimes there are legitimate, unavoidable reasons where you end up off the pavement, that's all. I'm not asking for the ability to drive on the grass/dirt. The ability to recover from off the pavement would simply be *consistent* with the ability to repair in 3 minutes. If the ground crew can replace my engine in 3 minutes, they can pull my plane out of the dirt in 3 minutes. Otherwise, remove the repair ability altogether and force players to always take a new slot, lets be consistent here. Why bother landing at all if I get any damage that I know will be unrecoverable once I land? Just take a new slot as soon as I'm damaged, no need for that silly time wasting RTB. This is what you're incentivizing. If you wish to critique my airmanship, you can take it to another thread. You know nothing of my abilities. Landing an A-10 with only a bloody stump for one of the main gears is a tricky task for any pilot and I challenge anyone to try it, it's not something that can easily be practiced because there is no way to force such damage, you just have to get "lucky". Damage can happen if you take any risk at all, Flankers sneak around, surprise MANPADS out of the ether (and the MWS does not detect them on the wingtips currently and hasn't for some time now), it's an imperfect world out there and things go wrong. Be careful up there on that high horse.

I think OP is stubborn and leaving the runway is a very real problem in most places for many aircraft, but I will say this can be annoying in certain situations. If you take damage in the A-10C for example and one of your tires is destroyed, when you land you're almost guaranteed to veer off the runway. Then you'll waste time repairing your aircraft and usually won't be able to make it back onto the runway, forcing you to grab a new slot. There needs to be some sort of recovery mechanism for situations like this.

You are typing 3 into the scratchpad before hitting the OSB, correct?

Not sure what you mean, the exported RWR appears to be the same scale as the in-cockpit one.

1-9 in my experience.

This thread will be a year old tomorrow. This is still a problem. Here's a video showing failure to detect 3 Igla and 3 Stinger launches from the wingtip sensors. Latest version of 2.2. ***This is normal. There are no sensors on the bottom of the plane, launches directly below you shouldn't trigger anything. The MWS seems to work against MANPADS decently on your nose or tail, it's not seeing launches off the wingtips. ***Maybe not, I had another look, and one of the sensors points straight down, I can't remember ever getting an alert from below the plane though, before the current problem we've been having. FWIW, there's four sensors on the plane, one on each wingtip angled slightly forward, one on the tail pointing straight back, and one on the bottom of the tail pointing straight down.

Axis binds are pretty simple. Here's a few. --Lighting {action = 3510, cockpit_device_id = 32, name = _('Formation Lights')}, {action = 3636, cockpit_device_id = 33, name = _('Console Lights')}, {action = 3635, cockpit_device_id = 33, name = _('Instrument Lights')}, {action = 3637, cockpit_device_id = 33, name = _('Flood Lights')}, {action = 3272, cockpit_device_id = 20, name = _('EDP Brightness Control')}, {action = 3289, cockpit_device_id = 22, name = _('HUD Off/Brightness Control')}, {action = 3295, cockpit_device_id = 23, name = _('Display Brightness Control')}, {action = 3194, cockpit_device_id = 25, name = _('MPCD Left Off/Brightness Control')}, {action = 3195, cockpit_device_id = 26, name = _('MPCD Right Off/Brightness Control')}, --Volume {action = 3298, cockpit_device_id = 23, name = _('Comm 1 Volume Control')}, {action = 3299, cockpit_device_id = 23, name = _('Comm 2 Volume Control')}, {action = 3614, cockpit_device_id = 7, name = _('V/UHF RSC Volume Knob')}, {action = 3629, cockpit_device_id = 4, name = _('ICS Aux Volume Knob')}, {action = 3630, cockpit_device_id = 4, name = _('ICS Ground Volume Knob')},

I use the clickabledata.lua to get the commands. How do you wish to control it? If you're using a single toggle switch, this will set it to RPT when the switch is on and RCV when your switch is off. {down = 3275, up = 3275, cockpit_device_id = 29, value_down = 1, value_up = .75, name = _('Jammer RPT/RCV'), category = _('ECM')},And if you want a command for each position you can use this. {down = 3275, cockpit_device_id = 29, value_down = 1, name = _('Jammer RPT'), category = _('ECM')}, {down = 3275, cockpit_device_id = 29, value_down = .75, name = _('Jammer RCV'), category = _('ECM')},

I have a 34" 1440p monitor and I had a Rift CV1, I still have the monitor. I was not satisfied with the Rift in it's current state. YMMV.

The most ordnance efficient way is as mentioned, to fly above 20k and drop a GBU on it. You can also launch two mavericks a few seconds apart, either yourself or in collaboration with a wing man.

I was not charged any kind of tax/tariff on my VKB Gunfighter Pro.

I sure would like to see this addressed. It takes about 5 seconds to correct the lua file. There's no reason we've had to wait years for this. Mods are great and all, but they aren't MP compatible.

Totally normal.

Probably because your binding is putting the switch into the "press" position instead of the "out" position. Value down should be 0.5, not 1.

What kind of switch do you wish to control it with? You can make it work with a toggle switch or an axis if you'd like. I use this one to turn the HUD to full brightness when my switch is on and turns it off when the switch is off. {down = 3289, up = 3289, cockpit_device_id = 22, value_down = 1, value_up = 0, name = _('ALT HUD Power'), category = _('HUD Control')},If you'd like to bind it to an axis you could use this. {action = 3289, cockpit_device_id = 22, name = _('HUD Power Knob')},

You need toggle commands to map them to, many of the default commands are toggle commands, such as the master arm switch. Unfortunately I don't know if it's possible for us to add missing toggle commands, I think that is up to the devs. Perhaps the clickabledata.lua has more secrets for me to find eventually. I originally programmed one of my panels to function like that, a pulse each time the switch was thrown, because it was easy on many modules with existing toggle commands. I eventually changed it to a steady state on/off system because there's simply too many modules lacking the toggle commands, but I can always make any module work with a standard steady state on/off switch action, but it takes more work, I have many hours into editing the default.luas for all the modules to use my panels.

I've had problems repairing the Huey after rotor loss for a while now. I suspect most people don't notice because rotor loss usually equals total aircraft destruction or they lose the rotor away from an airfield and are unable to attempt a repair. I've attached a short track. I started the mission and moved the cyclic to the aft and left to mast bump the rotor off. Then I shut down and repaired. After the repair I restarted the helo, even though the rotor is replaced it acts as if it has not been replaced, no amount of collective has any affect. On previous 2.0 versions, after repair the helo would continue to have very bad vibrations after repair, but it would at least fly. The vibrations appear to be gone, but now you cannot fly after repair. The track was recorded in the latest version of 2.2 on NTTR. Repair fail.trk

I'm glad the video is helpful for you guys, there's a few more things in the video I'd like to add and clarify, but it's nice getting all your switches and such to work exactly how you want them by creating something tailored to your own needs.

It runs much cooler than before. I never bothered flying by the EGT gauge before because I always knew it ran too hot and it took way too much effort to try and abide rules that were very easy to break. It still looks like it runs too hot, but it's pretty flyable in it's current state.