MarkDH

Are you using the Saitek trim wheel? If so, this is appears to be a common problem. For me the fix is to make sure I move the trim wheel before starting P3D until Windows gives the 'USB disconnect' sound. Then everything works properly. If I don't do this, I get into the same twilight zone you describe, with no mouse control and the only way out is to hard reset the computer. Don't ask me why, but it is so

No deadzones. Bungee life - who knows. From bungees I have around the garage I'd estimate 10 years if they're exposed to weather. If it needs new ones, maybe you can buy them at Halfords and fit them yourself. BTW, PFC yokes use bungees and nobody complains about those ;)

LMRTFY

Make sure you do your research on the GoFlight yoke. I have not tried one but it has a bad reputation for sticking too. If you're looking for excellence, Yoko is the way to go.

Can't see any mobile version.

Lubricating is not going to help, this is a design issue with the Saitek yoke that more or less guarantees sticking in the pitch axis if you have any aileron applied. You can look at my Saitek Cessna yoke review video for details, although it won't really help you. The Cessna yoke works better, if you can find one.

Yes, apparently the IoS are already modelled in TrueEarth. A recent post by John Venema says they intend to update all the airports to 2018 specs where possible. I presume her means for all the ES legacy products, since IoS only has one proper airport.)

I didn't write it, I just tweaked the layout.

As far as I can tell the procedure you describe is correct, although it will depend on what text you have put in your file (ec135.lua). I don't think I can help any further as I don't know anything about this example code or this particular aircraft.

I was assuming you were binding the button to 'Lua <name>', not 'LuaValue <name>'. If your Lua file is called 'EngineCoverToggle.lua, you should bind your button to the action labelled 'Lua EngineCoverToggle'.

This is not an issue of formatting, LINDA uses the FSUIPC Lua engine so FSUIPC will understand anything LINDA understands. In the example you posted, I would say you need to write it like this: -- ## Engine Cover Control ############### local function Engine1_Cover_Open () ipc.writeLvar("L:switch engine 1 rpm control cover", 1) end local function Engine1_Cover_Close () ipc.writeLvar("L:switch engine 1 rpm control cover", 0) end if _t("switch engine 1 rpm control cover", 1) then Engine1_Cover_Open () else Engine1_Cover_Close () end You will see I have removed the function header and 'end' statement from the main function. You should think of a Lua script as a complete program rather than as a callable function as in LINDA. In other words, the script starts executing from the top when invoked from a keystroke. In this case it defines a couple of helper functions and then executes the body of what was previously the Engine1_Cover_Toggle() function. Style dictates that you should also put the word 'local' in front of the function definitions to emphasise that they are helper for this program only, although it will work without that. I think there is a way for FSUIPC to address individual functions in a file but it's clunky and has something to do with passing a numeric argument. personally I would use LINDA, it makes things so much easier.

I think you need to reign in your expectations, I doubt you will get acceptable performance under any circumstances with three 1440p monitors. If you were to run them at 1080p you'd have a chance. Perhaps throwing an extra GPU at it makes a difference, but the sim still has to calculate the projections of everything you see. Maybe you have a super-computer, so YMMV. Then you have to choose between a three-srceen array with nvidia Surround or three separate views. The latter has a performance hit but looks better. In my experience it works well in P3D and X-Plane but it's an ordeal to do in FSX. Separate views (best using View Groups in P3D) would let you mix resolutions, so you could run 1440p on the centre and 1080p on the left and right views, which might be more realistic (but still not very) for performance.

More voodoo. AffinityMask is just another parameter that interferes with the balance of scheduling, usually in unpredictable ways. So it it is nether the cause of nor the solution to blurry textures, although it can appear to be either. You're much better off tweaking parameters that are designed to adjust the balance in predictable ways. In other words, if you can find it on a menu inside P3D it's much more likely to have a useful effect.

Without any more context, this sounds like what happens when you demand more of your computer than it can deliver. Try adjusting some of your settings to more conservative levels. The frame rate setting would be a good experiment for starters. Set it quite low (like 15 or something) and see if the problem goes away or reduces. Another good test is to hit Pause and see if the textures catch up.