tkyler

rgr. Best solution is probably to add these internally. We will do that for this next release. -tkyler

to reiterate.......by not working properly, you mean the Fly With Lua issue? I press it in sim and it works as expected for me. -tkyler

All our actuator manipulators are instantiated as objects from the same template object, so having a "few exceptions" is quite odd and I haven't the faintest what the issue may be with regards to our own code base, if at all. If you are using FlyWithLua to overcome 'deficiency of datarefs' from our end, then please let me know as we are now working to expose many more datarefs / commands. -tkyler

It is a holdover from the days before X-Plane had hardware configurations and users would have to re-assign commands every time they swapped airplanes, which was a huge headache. The solution was for us to "hijack" those common commands users normally assigned to buttons and customize them. With hardware configurations now, this isn't an issue and indeed you are correct, that moving everything over to custom is the logical solution. I have begun a new source code file strictly for the purposes of creating these unified command names, but it will probably take a while. I estimate well over 750 commands to represent all control possibilities, if not more. My strategy is to chip on new ones each day, which I will be doing in a few hours -tkyler

If you have a request for any specific datarefs or commands, please do so in this forum thread. We have nearly 600 manipulators in the 737 and exposing every position possible as commands could result in over 1000 commands possibly (I have yet to audit all the positions). If you count the "feedback" datarefs as well, i.e. "annunciator lights", the list would get very long indeed. So while we do not mind exposing all these inputs and outputs eventually, we certainly want to focus on the most requested ones first if we don't get to them all by the next update. So if you have a request for a nominal (button / knob / switch), then don't bother posting as we are actively coding those up now. But for anything else not so obvious, please let us know. Note that we're starting with the overhead, pedestal and main panel controls first. Note that multi-position knobs and switches will have a command for each position, e.g. the left engine start switch (see below): -tkyler

I am going to start coding up commands for the overhead controls, we should be able to get these into the next patch. If not, then shortly thereafter. -tkyler

Hi all. This COVID thing has affected my employment and sent me in a different direction.....full time back on X-Plane! (note...I work on more than just the 737 though) We are working on the update every day as of late; however, we are still going to wait for some 11.50 stability before we release. In the meantime, we're cleaning up things we feel we can without putting the plane in the hangar with the major renovations like the FMS/holds/VNAV. We are back in the FMS code somewhat though and have made the coroutes loading more robust. We will be including that folder in our update so as to not cause confusion, but we also now support about 6 flight plan formats, X-Plane 10/11 (*.fms), PMDG and Quality Wings (*.rte), X-FMC (*.fpl), FSX (*.pln) and AirbusX (*.flp). Like the real FMS, if a waypoint can't be located because of database incompatibilities with the flight plan, then the FMS loads what it can until encountering such a point and then provides the message, "PARTIAL ROUTE LOADED". I was testing this code with random format downloads from Flight plan database...and nearly all of those flight plans contain out of date data, so getting the FMS to load a full route was a challenge. I had to go in and hand edit the flight plan files to 'up-to-date' data. Once done though, they can be saved through the FMS as before. These coroute. loaders do not load SIDs/STARS, only the enroute portions, which is typical. As time goes on, I'll continue to work on improving the route editing, which will have applicability for the holds and eventual "in air" vnav entries. More to follow as we get closer to our release point. -tkyler

you can enter an "extended runway waypoint" based on the centerline and distance from a runway threshold(that is in the database), but not for any other type of waypoint. This is a limitation of our FMS and not the real thing. The real thing does have the ability to create waypoints based on radials and distances from other waypoints, but we did not implement this in our current implemenation of the FMS; however, I may very well look into this after our upcoming compatibility update as in the course of my rewrite of the new FMS, I have since written these functions that can parse the CDU entries and create those waypoints and I may be able to squeeze these into the current FMS codebase. -tkyler

nothing to see that you don't already see. This is a "infrastructure" and compatibility update.....such we can maintain the 737 efficiently as X-Plane moves forward with advancing technology. After the compatibility update is when we'll be making the visual / aural changes towards a major "visibly changed" update later. -tkyler

we are actively working on the compatibility update. Jan is testing the flight model and I'm hunting / fixing any of the 3D oddities found from the recent conversion to new 3D tools. Its job #1 at the moment, especially with 11.50 final getting closer. -tkyler

FYI, we will create a more comprehensive set of custom commands for controls that can be mapped to "joystick settings". I will assess whether or not we can squeeze a bunch of them into the next patch. Creating them is relatively quick. If not the next patch, then perhaps shortly thereafter in a dedicated "commands additions" patch. -tkyler

Hello all. I have not been able to get onto the FMOD sound conversions as of yet for personal reasons; however, things have transpired during the reorganization process such that we are now maintaining two development branches. A longer term branch which will use the new XP11 navdata I've written about above, with revised FMS and we'll also maintain a "now" branch which we'll use to make compatibility patches and small fixes as able until the major revision comes out. The 'now' branch is a combination of our current FMS code base, but with the new 3D development pipeline....and juxtaposing those two elements has been the focus over the last few weeks. As many have noted, this tact will allow us to not have to wait for "big ticket' items like the FMS/FMOD conversions in order to get the smaller improvements to the current product. Until we finished our "pipeline renovation" though, this wasn't as easy as it sounded. We have begun flight testing again and making tweaks to the flight model as X-Plane updates come out. In particular, we are working with the 'experimental' flight model in version 11.41+ as we feel that will become the norm. In addition, we have XP 11.5+ test builds so we can test the Vulkan and Metal graphics also. The plan now is to get a XPlane compatibility update out asap, with scroll wheel support. This patch will have small fixes for the exterior lighting/MCP issue and flight dynamics etc. After that, we'll resume our development in earnest. -tkyler

So this is a heads up that it might go quiet for a few weeks. Not because we're not working on it, we definitely are, but the conversion of sounds to FMOD is going to be a very intense task. We wrote our own sound engine before X-Plane adopted FMOD....and our system is quite versatile and very quick to add sounds in code, but its also based on OpenAL, which is going away in XPlane 12 IIRC. Now we could probably distribute an openAL DLL as a solution; however, that is probably asking for more trouble trying to play alongside X-Plane's FMOD sandbox....so we might as well tough-it-up and make the change. We have over 1400 lines of code that control various sounds in the sim...and we have to go through each of these situations, audit the behaviors and then port that behavior to FMOD...probably having to write new code just to drive the FMOD inputs. In the same way we ported the 3D, we will chip away each day on this task until its done and report back as we progress. -tkyler

Conversion of all 3D to the new toolchain is complete and we have exported out all of the 737 objects from the new version of Blender. Jan and I will begin testing the functionality to see what I may have missed in the conversion as I had to hand-edit an enormous volume of elements to prep it for the conversion software. Next up is converting the sounds. The attached screenshot shows a "quickie adjustment" I made to test drive the 3D update process......about 15 minutes of fooling around in Blender to see how quick I could make an update to the 3D with the new toolchain. (I know, the circle isn't perfectly round....but it was only 15 minutes) -tkyler

So the following screenshot tells two stories. 1). We have almost completed the conversion of all 3D assets to to the new Toolchain. Two assets remain and I'll probably knock that out over the weekend. The second story....is that with the upgrading of our assets, we finally have a workflow between 3D and Substance Painter® for texturing....in this screenshot the glare shield has a bit of a texture to it, nothing major, but adds to the immersion that's so important to us. We'll be able to start sharpening up several 3D elements that are a bit low-res by todays standards. The roadmap after this 3D conversion is to then convert the sounds to FMOD, upgrade the 3D a bit, including a revised cabin and working doors and make any adjustments required by the X-Plane flight model itself for stability and we'll probably put out an update then. Then I'll move back to the FMS to finish up my integration of the XP1100 data format and get the holds integrated, the VNAV cleaned up and several other FMS polish work. -tkyler

Certainly once we get all the 3D assets converted to the new workflow, a cargo variant would not be terribly difficult. We'll put this on the wish list. -tkyler

With a future release of the 737 rather....the ball is in our court. Its been fixed and will make it out on next update.....yes....a real update! -tkyler

With modern tools, comes modern features.

another update, for those who may not have seen discussions in other threads. As much as I've spoken about FMS work...that was mostly because all the other aspects of our project, the 3D, the sounds, etc....were bound up in deprecated technology and tools, making it VERY difficult to update things....whereas the FMS was just code work. This was not really a lack of foresight on our part regarding the 3D tools, but rather being so far ahead of the game way back when we started, we came up with our own solutions.....that were not quite compatible with the way X-Plane moved with regards to developer tools. WELL.....thanks to Ted Greene of Laminar.....he has coded up a "converter" between the old toolchain we used and the 'toolchain of today'. Only in the last week did we work out some critical bugs that allowed us to begin converting all our assets into the modern workflow supported by Laminar. We are currently in the process of converting all our work to this new toolchain and have converted some of the most complex aspects of it already...so we do not anticpate much resistance converting the rest of the work. This converter by Laminar is a huge lifeline of sorts and will allow us to again respond quickly to bugs and manage updates once we establish a new baseline with these tools. -TomK

We have confirmed the issue with Laminar. They are aware of the issue now and chasing it down. This issue should resolve itself with a future update from XP. -tkyler

After working with Ted from laminar to squash a few bugs in the 3D converter, we have it working and have successfully converted many objects over to the new Blender 3D workflow including some pretty complex ones as well. My hats off to Ted...this converter was a real lifeline for us. This was a very very big hurdle to clear. I expect to have all the objects converted before the weekend is out. This will effectively restore our 3D workflow and allow us to get back on the cabin / door work in the 3D department. We still have sounds to convert to FMOD and also our 2D GUI to rework to the new look. The FMS work will resume once all the 3D conversions are done. It is unfortunate that all this infrastructure doesn't have anything visual to show for it but I can assure you, its quite significant for IXEG ability to get back on track with improving things. -tkyler

So some pretty significant news. One of the contributing factors to our lack of updating was our mostly deprecated 3D toolchain using a very old version of Blender. Because our project is of a significant amount of 3D complexity.....manually transposing all the work (6 years worth) to the newest toolchain used by Laminar was so daunting as to preclude us from even attempting it. Laminar, recognizing the volume of work performed by many aircraft developers in this old version of Blender was significant enough to warrant their development of an "automatic conversion" tool. As such, Ted Green of Laminar took on the task and provided it as of a few months ago.....but we (IXEG) have only gotten around to trying it recently....after waiting for Blender 2.8+ to also evolved and stabilize . But I am happy to report that we have successfully converted about 85% of our 3D work and its now in the new Blender 3D / Laminar pipeline and exporting as expected. The remaining 15%, we will have to do by hand and will take a bit of time....but once done, SHOULD allow us to make more frequent updates as we did early in our release. It is our hope that once we get the new toolchain back up and running (and it was our efficient toolchain that allowed quick updates during release)....we should be able to handle updates well again. It was unfortunate that XP and the toolchain (and Blender) all changed radically at about the same time...leaving us somewhat in a difficult spot, but I do see a lot of light on the horizon. -TomKyler

Thanks for the inputs gentlemen, I fully understand everyones point of view and dont' disagree with folks feelings. The issues to bring the 733 up to speed are indeed challenging for sure, and there are several factors contributing to the complexity of the situation; however, the likelihood of us falling behind technologicially is not as great as it may seem....that's not the issue. The issue has always been stability for myself as I'm the one who needs to fix the glaring issues. Not an excuse, but an explanation....(followed by a course of action) As a self-employeed engineer, I'm always having to gauge project opportunities that can provide for me and my family and the 733 and customers have taken the hit over the last few years while I've committed to other work that has to be completed towards 'deliverables'. ...in particular, what I like to call, "the NASA gig"...which fortuantely is over....and took 4 years of my life at heavy cost....and why I got out. As that gig ended earlier this year, I begin looking for other work, while simultaneously working on the FMS again...and folks have seen those posts around that time frame I'm sure. For those who might say, "why not just work on the 733 full time".....the simple answer is that even with the X-Plane market at its best, it doesn't compare to what I make as an engineer...and it'd only be a matter of time before I went broke on 733 revenue alone (i.e. kids college tuitions, mortgage, etc). I have since secured new work (in the flight simulation industry no less.) and began in November. After much discussion with Cameron / X-Aviation.......the obvious course of action is for me to simply prioritize and focus all my available X-Plane time on bringing the 733 back up to speed. Whereas the NASA gig ate up nearly 50-60 hours week....this new job is more stabilized...and basically puts me back in the same situation I was in when originally working on the 733 years ago. That's the story and the plan moving forward. I need to get on it. -tkyler

In Planemaker, Standard > Misc Objects menu....the MCP lighting mode for the B733_mcp.obj is set to "glass outside", and is being affected by the landing lights when they're on. The pull-down for the lighting setting should be set to Glass (inside)...which should fix the issue. -TomK

So its been a while, time for another update. There was a pause after the rush of FMS work mentioned above. During this pause, I have finished up my NASA obligations...and demobilized from Houston back to San Antonio, where I live, and some much needed stability to my schedule. Last week, I dug back into the FMS code and started coding up the route editing features using the new XP1100 dataset. This is the backbone of the FMS future with regards to performance.....for VNAV calculations, performance progress and also holds. Its one of those things that I wanted to be real sure I was ready to dig into before doing so. This route editing coding will go on for a bit......'route editing' involves building the route data that the FMS will use during lnav and vnav tracking and so is critical to be flexible and correct. It is my belief that if carefully done now, the FMS will be functional and stable for many years to come, which is the most important thing. -TomK