skiselkov

Wish there was something I could do to help you guys out with regarding custom avionics coding. If you think there's some particular system on a "nice to have" list that you guys don't have the time to produce right now, please let me know.

Version 2.0, release candidate 4, available on the Github project release page. Changes: Rewritten documentation in pdfTeX to obtain more consistent formatting. Added lots more error checking and reporting to the OpenAL integration to check for all kinds of weird underlying OpenAL errors.

Version 2.0, release candidate 3, available on the Github project release page. Changes: Implemented parsing of APPCH procedures to extract the runway GPA. Removed guessing at the TCH & GPA by scanning the location of GS antennas. Documented all the new options in the PDF and the sample config file. Included sample config in distribution package. Added the auto_disable_notify option to the config GUI. Switched from '--' to '#' for comments in the config file. The legacy '--' combo is retained for backwards compatibility.

Version 2.0, release candidate 2, available on the Github project release page. Changes: Fixed regression when enabling use_tts would crash the sim on attempting to emit an annunciation.

Version 2.0, release candidate 1, available on the Github project release page. Changes: Added harder detection of malformed VGSI entries. Made GS antenna elevation always be equal to the threshold elevation for auto-computation purposes (avoids strange behaviors for GS antennas with bad elevation values). Fixed error when the cache was manually removed and subsequently the user used the menu entry to recreate it. Fixed incorrect cache location in gui.c after it has been moved to Output/caches. Bumped cache version to regenerate caches using newly hardened algorithm.

Version 2.0 beta 2 is out, available on the Github project releases page. Changes: Fixed assertion failure when an invalid runway ID is detected in an apt.dat. Hardened parsers to perform much more validation of the scenery database. Bumped X-RAAS cache version number to force cache rebuild using new algorithm. Implemented auto-translation of US runway numbers in scenery database. Implemented stripping of 'T' from earth_nav.dat files referencing runways using true heading numbers (e.g. "08T" at BGTL).

Thanks. Let me know if you need any help getting this running. If you were running X-RAAS 1.0, be sure to remove it so you don't get duplicate callouts. This no longer depends on FlyWithLua, so just install it as a stand-alone plugin into Resources/plugins.

What is X-RAAS/RAAS? X-RAAS is a simulation of the Honeywell Runway Awareness and Advisory System(*), an extension to the EGPWS. If you've ever seen cockpit videos where some robotic voice announces something like 'APPROACHING 09 RIGHT' or 'ON RUNWAY 09 RIGHT', that's RAAS. What's the point of this post? I've been hard at work on X-RAAS version 2.0. Basically, this is a from the ground up rewrite of X-RAAS 1.0, because I wasn't satisfied with the Lua scripting performance and limitations. As a consequence, X-RAAS 2.0 is written in C and is instead compiled as a native binary plugin with no dependencies on anything else. We retain all features from X-RAAS 1.0 (refer to link above), as well as get some new ones: Configuration GUI: no need to hack around with config files anymore. Everything can be set up through an easy to use graphical user interface. X-Plane 11 compatibility. Much better performance: no more stuttering when Lua decides to collect garbage. Resolved all audio compatibility issues: we now use a dedicate OpenAL context, so no more compatibility issues with JAR's GroundHandling and the LES SAAB 340A. Ability to selectively enable/disable each monitoring function. Much nicer text rendering and substitutable fonts. Ability to change the 'LONG LANDING' into the 'DEEP LANDING' annunciation. This is a call for alpha/beta testers. The code is very nearly finished and is usable for day-to-day flying, but there is always potential for pitfalls. Given that this is written in C, bugs can lead to crashing the simulator. As such, the beta release is only suitable for people who are not afraid to see the occasional crash and are willing to provide testing feedback, such as explaining what you did, what settings you were using, willing to supply log files / crash dumps, etc. If you are not turned off by this, head over to https://github.com/skiselkov/X-RAAS2/releases, grab the latest X-RAAS2.zip and go flying! Note to aircraft developers If you'd like to integrate X-RAAS into your avionics package, you are quite welcome to do so! X-RAAS can feed you visual alerts for display on the ND, configuring the stabilized approach monitor and more. The installation package includes an avionics integration guide in the Documentation folder to guide you in the process (or just message me, I'll be happy to help). You can also grab the source from Github and build an embeddable version, so you can ship X-RAAS with your product. (*) More accurately, Honeywell SmartRunway and SmartLanding.

Is the update to the 340A still gonna happen? Another two months have passed with seemingly little new info. Maybe I just missed it, but I figured it's best to just ask. If there's anything a fellow 3rd party xplane dev can do to help, I'd love to put a hand in. TBH, I wouldn't even mind if this were a paid update for a modest fee, just to let you guys know that continued customer support post launch is worth it.

There's already a several second pause when loading the aircraft. As long as the pause is properly positioned and predictable, people can generally tolerate it. Another thing is that it's an ideal target for backgrounding in a separate thread. Just loading in a file to build Lua data structures shouldn't access X-Plane's API, so multi-thread away! Admittedly though, LuaJIT might not be easy to modify to be multi-threaded on execution. Not sure what you mean by "Shared RAM pools" - shared between what? Do you mean as some sort of an IPC mechanism? As for the garbage collector: might be a bit of an issue. Depends on the collector's design. It shouldn't be too hard to mark a piece of lua data to mark as "don't bother trying to collect for now". As for the complexity of Lua code, isn't the IXEG 737 FMC (and pretty much all of its logic) written in Lua on top of Gizmo? The pausing when modifying a route in flight, or even on the ground, 2000 nm load limit for airports, etc. None of this would be an issue if the code could run on a separate thread. Finally, though, I'm not talking about some hypothetical project in the far future. I'm talking about solutions to an already existing project which is substantially written in Lua/Gizmo and most likely won't be rewritten any time soon. Please don't take this to mean I think Gizmo is badly designed or written. For all I know, the IXEG 737 might be abusing Gizmo's internal facilities to an absurd degree, hence the performance problems.

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.