skiselkov

Why selectively load stuff in the first place? The full AIRAC (excluding SIDs/STARs), even using fairly inefficient Lua data structures is probably not going to take up more than 40-60 MB of memory. RAM is cheap. Just load it all in one fell swoop at startup and index by airport/waypoint/fix ID. Lua table indexing is a hash lookup, it's essentially constant time. Alternatively, if you are really that concerned with memory usage, please at last swap the lat/lon filter at load time for something a bit more sensible (like actually measuring object distance). I have pre-made Lua code for that if you want it.

In general, this is actually something that can be worked around in a rather straightforward manner. Unfortunately, X-Plane's API makes creating multi-threaded plugins fairly non-trivial and my guess is that when Gizmo was created, the dev went with the "let's keep it simple" approach and made everything single-threaded. Works ok for relatively constrained projects, but as soon as you get into writing anything approaching appreciable size, you can start running into walls. I started hitting that even on a project as small as when I was writing X-RAAS in FlyWithLua and that's a laughably small 4.5k lines of code. If I ever find the time to do a 2.0, I'll be redoing it in C and threading all the heavy lifting.

Reason I'm asking is that the last post in this thread has been over half a year ago and since then, nothing I'm aware of. Of course, I'm super stoked to see LES support their product so far past launch. I thought the 340 was a done deal by now and they were looking elsewhere. The fact that the 340 is still gonna get updated so many years is deserving of nothing but praise.

Any chance this could get resolved soon? It's been open for over half a year and should be a fairly trivial fix: just reset the GPWS' state after landing. Alternatively, shouldn't the GPWS shut up about gear if a climb rate is established? That'd work for go-around as well.

Basically, the smartcopilot file from birdy.dma already only actuates one side's transponder, so that's who should be logged in with the proper callsign. Second guy should be logged in with something like "_2" at the end. Then sometimes the controller asks if you're a flight of two and so far I've never had anybody give me any shit if I said that we are. Admittedly, I've only ever flown shared cockpit on Vatsim maybe 3-4 times. Once you get used to PilotEdge, it's very hard to go back to unreliable and chaotic ATC.

Just FYI, VATSIM works fine, as does PilotEdge and maybe also IVAO (haven't tested that). Don't use X-Plane's built-in multipler. It's... pointless.

I can confirm, version 1.4.8 no longer trims in cruise all the time. I don't know how you did it, but you're a genius!

Thanks for the quick reply, will try tonight. Important detail: it only happens on autopilot. My guess as to what's happening is that if in manual flight, only side (master) commands trim updates, so everything is fine. But when in autopilot, both master's and slave's autopilot is trying to adjust trim independently and do so inconsistently, which results in the trims fighting on the slave's side (being fed both the master's and its own autopilot's trim inputs). I don't know if it's possible to define in the smartcopilot.cfg, but I'd say to fix this, all one needs to do is disable elevator trim syncing once autopilot is engaged. Then, once autopilot is disengaged, trim is again synced.

This has been a problem I've battling for a while now and didn't notice a resolution in any other post: any ideas on how to get trim to stop adjusting all the time in flight on the slave machine? It's mighty annoying and it's just fractions of an inch off from where the slave wants it to be. We don't adjust it by mouse, only joybuttons.

So I've been doing some non-trivial amounts of Lua development for X-Plane (working on an open-source RAAS implementation, about to be released) and I believe I have an idea where the problem might be coming from. If you're experiencing a periodic stutter, irrespective of actions on your behalf, then one likely source is the Lua garbage collector. There is little you can do to fix this. It depends largely on the developer working on their code trying to lower its memory requirements by e.g. explicitly setting unused data structures to `nil' to inform Lua that it can free them early, or by trying to just create code that is lean on memory consumption as far as practicable. One possible general workaround would be if the plugin implementing the Lua interpreter itself were to run the garbage collector periodically on its own in a background thread (i.e. while no other Lua code is running in the foreground), rather than relying on the Lua engine to determine when to run it (which might not be at an optimal moment).

I totally understand. It's an annoyance, but it's not a showstopper (as happened to me today when selecting, reselecting and deselecting STARs while sitting on the ground, leading to a soft crash of the FMC).

Nah, I know what the problem is. It's the same problem you described a couple of pages back, in that if you try to do any kind of MOD on the FMC in flight, you'll get VNAV recalculations every 2 seconds. Sadly due to how those are implemented in lua, they take a lot of time and since the lua interpreter executes on the main drawing thread, the whole sim pauses for a short while as the VNAV calculation is performed. Once I hit EXEC, this stops.

Well, don't know how much use it'll be to you, but in case you wanna see what you can reuse, feel free to lift bits you'd use: https://github.com/skiselkov/openfmc The nav data parser is in airac.c, although I'm not sure the data structure format will be of much use to you. Maybe just to get inspiration from it. The generic geometry handling code sits in geom.c and allows for things like vector math, solving 2D and 3D geometric problems (intersections), coordinate conversion, spherical projections, etc.

I'm working on a fully-featured Boeing-style FMC, written in C (plan on open-sourcing it once it's functional to the point of being useful). Let me know if you need things like X-Plane navdata parsing, geometry, physics, projections code or anything.

Don't worry man, I write operating system kernels for a living, I know.

While flying on the US west coast I noticed that frequently VNAV constraints on STARs are represented incorrectly in the FMC, necessitating a manual update (which is also kinda buggy, but whatever). For example, KSFO's SERFR2 RNAV STAR should be: SERFR NRRLI, 280/FL200A <- represented correctly on LEGS page WWAVS, 280/19000-15000 <- represented incorrectly as 280/FL190A EPICK, 280/15000-10000 <- represented incorrectly as 280/15000A (remainder of STAR correct) In general, whenever there's a "below" or "above & below" constraint, it gets incorrectly translated to just "above". Moreover, trying to change WWAVS to "/FL190B" just changes it to "/FL190" with no more details (and the FMC attempts to fly through it at exactly FL190). I suspect the FMC is incorrectly decoding the Navigraph database, as it contains these kinds of entries: <Star_Waypoint ID="3"> <Name>WWAVS</Name> <Type>Normal</Type> <Latitude>36.741531</Latitude> <Longitude>-121.894234</Longitude> <Speed>280</Speed> <Altitude>19000</Altitude> <AltitudeCons>15000</AltitudeCons> <AltitudeRestriction>above</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </Star_Waypoint> I suspect the FMC is simply interpreting the AltitudeRestriction value as always applying to the Altitude value and ignoring AltitudeCons. The NACO STAR chart for SERFR2 is available here.

I'm hit by this every time I'm instructed by ATC to fly direct to a point, try to execute a step climb or even just modify a VNAV constraint. Any reason why these couldn't be performed in a background thread? It's not like there's a reason why this needs to be performed on the main rendering thread. Most of us have spare CPU cores available, but almost nobody has a CPU fast enough that a one-second computation could all of a sudden be done in an unnoticeable fraction of it.

The IXEG 737 currently has (somewhat) broken handling of the MIC selector on the comm panel, forcing you to use VHF1 for all of your comm needs. To fix that, I've devised a little lua script which follows the selection you make on your audio panel and switches the underlying X-Plane datarefs (sim/cockpit/switches/audio_panel_out). The real audio panel has two rows of controls, the mic selector switching row (only one selected at a time) and the speaker buttons (push-on-push-off). You can listen to multiple COMs simultaneously. This script preserves that behavior. Switching your mic to another VHF radio won't also switch your speaker, so you need to select it by hand. Please note: only the captain's side audio panel is handled. F/O's side is left as-is (i.e. ignored). This script also fixes a number of different aircraft which have a similar bug. The Beech 1900D, Jetstream32, L410 and Bell 407 all feature speaker selection switches, but no (functional) mic selector. There we simply follow the speaker selection. Flip VHF1 off and VHF2 on and your mic will go to VHF2. Flip VHF1 on and VHF2 off and your mic will go to VHF1. The RWDesigns DHC-6 has a mic selector, but it was non-functional. Fixed that as well. mic_fix.lua

Attached is the one I'm using. It's a rather complex setup involving a custom xjoymap script and config, which Xsaitekpanels calls into. This is to provide knob acceleration, so I can spin a knob fast to quickly change its value and then slow down to fine-tune it, just like in the real aircraft. If you don't want to run the custom xjoymap, just replace the xjoymap references in the xsaitekpanels.ini file with the standard commands to change AP settings from X-Plane. Caveats: I've disabled all switchpanel buttons except for the landing gear lever. I find they don't really map that well to the real aircraft. Feel free to reenable them by adding the appropriate lines. Be careful about avionics though, it might mess with the electrics in the aircraft. Also, even if you have the avionics button disabled, you need to keep its knob in the "on" position (and cycle it when you start the sim), otherwise Xsaitekpanels won't turn on any other panel. I've remapped some positions on the multipanel for my convenience. ALT controls right CRS knob and VS controls ALT knob on the MCP. I've changed the TRIM wheel to instead change vertical speed on the MCP, as in the real aircraft. I've changed the REV button on the multipanel to engage LVL CHG, since the 737 classic doesn't have a localizer backcourse roll mode. A/T switch on the multipanel is disabled. The real MCP has this knob on a solenoid that disengages when you press A/T disengage on the throttles. Obviously this can't be done on the multipanel, so I'd rather it doesn't mess with the simulation. ixeg 733 plugins.zip

Wonderful work. I tried it tonight - works, but I'm getting an awful lot of stutter (every 15s, stutters for 1-2s) and the trim going apeshit every 5s (non-stop adjustments by a few degrees of the trim wheel). Any ideas? I'm gonna retest with weather sync turned off.