tkyler

Well Jim, your thoughts are duly noted and will be incorporated as I am 100% in agreement with you. I will say that when I did the first iteration, my boundaries were quite a bit tighter with regards to allowable texture space...and while I don't have an unlimited texture size budget, I do have a bit more freedom. In addition, new features being developed for V11 will allow me some new design techniques that should allow for quite a number of variations of things to be implemented...quite exciting IMO. I'll see what I can do about those hangars. -tkyler

Yea, I have a multi-year history working for Laminar. I did the initial mobile scenery way back when, some of the mobile aicraft, and for XP V10, I did the Beech Baron, King Air (but both have been improved for v10.50 by Jim Gregory)...the F22, F4 Phantom and airport scenery library.....most of the while working on the 737. About two years ago, I had some other opportunities that I felt necessary to take for the sake of my familiy and did so....but have since finished those endeavors and quite looking forward to working with Laminar again to improve the sim. -tkyler

Unfortunately, you should not get your hopes up for 10.50; HOWEVER, I am moonlighting for Laminar once again on the scenery library. I did the original and have now been asked to "add some more" (Not like I didn't know it needed it)...so I am taking note of what folks have been asking for, and T-hangars are indeed on the list (have a picture of something you'd like?). I can't say what will make it into 10.50 as I haven't been involved until just recently, but I don't think there is anything new as I don't see anything new in the developer files. It is possible though that the default library could be updated well before V11. We'll see once I get rolling. -tkyler

As are many modern software products, I'm not saying that you are not speaking the truth on several things, I am just saying that IXEG is not unique in these issues....for example: We have fixed the following: Reduced numerous CTDs related to terminal procedures in the navdata. Fixes for several situations that could result in an incorrectly calculated VNAV path. RTE page now automatically picks the correct waypoint when an airway is entered in the VIA column and the waypoint entered in the adjacent TO column has duplicates in the navdata that are not on the airway. Fixes for several situations that could result in a crash message. Fixes for several scenarios that could result in a CTD while performing a go-around. Fixed a CTD caused by entering a value higher than 100 into the cabin lights. Autobrake system completely redone, values match Boeing braking distance tables extremely closely. Added the ability to make and use custom runway-based waypoints Tweaked approach idle values to be more accurate ​OH WAIT....this is not stuff IXEG fixed, its about 10% of PMDGs Service Pack 1 update log (and 2 and 3 is equally as long). ...and just like PMDG, we will continue to improve and update the product. This is the way of software development and though the elements of the things "to go" differ between products, all modern released software products have such a list and its always a ways to go to shorten it. -tkyler

DOH...indeed!

The intent is not to model the failures themselves, but rather proper operation that works because of the way the thing is engineered. The only way to simulate a system that operates like the real system is to program it like the real system. A consequence of that process is that failures comes along for the ride....fail a component and the same type of effects happens. Its a "two for one" as it were. We are not, then, spending "undue time" programming failures, extending the release schedule for features barely noticed. The failures simply highlight the accuracy of the simulation itself, which makes normal operation that much more satisfying. We'll see the release this year I'm confident...sooner rather than later barring some catastrophe. We are making excellent progress on the FMS and laboring heavily as of late. Tom Kyler

Jan, our expert airline captain just posted a video demonstrating some of the cascading effects of a failure...in this case, an engine fire. TK

Hi guys. When the product ships, we will have the basic failure menu you see on the videos, manualy actuated at first. All failures cascade properly as we simulate the electrical buses themselves...electronic relays and some internal switching like the wheel ground sensor. So for example, if a component (sensor or gauge) is hooked up to the AC electronic bus and that bus fails....then that instrument will go down...and if a sensor or relay, that will go down and cascade further. Same for hydraulic power systems. There are a few default x-plane failures that will work and we will go over this in the documentation. After release, we will look into a more comprehensive 'failure mangement system' where we can initiate MTBF criteria...part wear, etc. Because we coded the simulation around modeled parts at a very low level. (switches, relays, light bulbs), the sky is the limit for failures. We feel the time we put into this using engineering style modeling will create a superior flight sim experience. Tom Kyler IXEG

As deep as we can make it. Being the FMS is "new" to me, I don't know any better than to understand it and simulate it as I see it operate. One thing I am really good at is trying to break stuff too. I press button combos that no self-respecting airline pilot would ever press and so make sure the unit can handle that. Minus the obvious, one thing I think a real unit might have that we won't is waypoint bypass and double-bypass calculations. In general, procedures are designed nowadays such that aircraft can fly the procedures so you don't encounter bypass situations very much; however, we have found our Navigraph data source having some situations where the data doesn't match the procedure description and we elect to "skip" waypoints in these cases (when the next waypoint is inside the turn radius of the aircraft and can't be made)....in these cases, we simply will sequence to the next waypoint. I think all the important stuff will be there. lnav, vnav, takeoff and climb calculations, leg and route editing, fix and hold pattern entry, etc. We won't really know till we get there how long it will take or how tough...is our first time, but thus far, there is nothing critical we have said, "lets leave out" or not followed through on stability during operation. Here's a quick glance at the EHSI with Gizmo's interactive terminal for debugging and testing. This is leading up to route editing via the legs page and RTE pages..including shortcutting, deleting or adding direct points, etc. TomK

Its been quiet for some time here so here is a quick report to let you know work is still ongoing. Just about everything except the FMS is ready to go. All the focus is on the programming of the FMS, which is quite narrow focused and internal and so it may look like there's not a lot of activity...nothing new to show in the cockpit or exterior, etc.. The truth is that the coding and work on it is ongoing and everybody are well are that we are waiting on the FMS work to be complete for a run up to release. As we have said, this is our first go round and so have no re-usable FMS code and we want to get it right the first time, handling all the button presses you can throw at it without crashing the sim and also handling dual CDU operation for shared copilot use in the future. TomK

From time to time, we like to reiterate why that there are a few reasons for the slow rate of development...for new folks. It certainly is not due to any "show-stopper" like inability to program, or do 3D or any of that stuff. Its that each and every team member is a full time professional, having a full time job doing something else...and each and every team member is a dedicated family man raising a family and they come first. There are several upsides to this though. The biggest one is that we are all settled in our paths with some mileage and maturity under out belts and so do not have anything to really get in our way or knock us off track. We are not embarking on new careers, experiencing some major milestone like a graduation...we are not moving anywhere, etc. This allows us to move nice and steady to focus on the work at hand. Other reasons for slow development is this is our first endeavor and we have to build a foundation of code from scratch. Also, the quality bar and expectations are constantly moving so as we move towards our goal, the goal moves further away. As can be seen from videos and blogs though, we clearly have most of the 3D done and a lot of the programming also. We have some FMS work remaining...very minor 3D details left and then we have to focus on several things at once like documentation (in progress), training videos, marketing concerns, distribution infrastructure and this will be the time where it will get really quiet before release. One thing each of us share on the team is that if we do it right, it will be worth it and worthy for years to come and we won't have to do update after update. TomK

Ok..the first of 4 videos is up. We're going to publish the videos one per day. Uploading / processing takes quite a while and its just easy this way. Tom Kyler IXEG

Name: "Cold and dark" part 1 of 4 Category: XP Aircraft Date Added: 19 November 2013 - 03:38 PM Submitter: tkyler Short Description: None Provided In this first installment of a 4 part series, our tech consultant and 8000+ hour 737 pilot demonstrates our 737-300 simulation for X-Plane by showing you what its like to work in a 737-classic for an early morning flight. This 4 part series will take you from entering a completely unpowered aircraft on the ramp, through takeoff and leveling off at 7000'. You will feel like you are getting the VIP treatment to a tour of a real flight. We could watch these all day long! View Video

Hello guys, we are really happy with the progress. We have a preview coming up, broken into 4 videos showing cold and dark to 7000', without using the FMS for enroute navigation.....perhaps 45 mins of video, more or less. The FMS "wrap up" is the last thing we will do so that is not covered in these preview videos. Most every other system and switch works to perfection. Our goal with this aircraft was simply to build the most accurate and immersive aircraft we could simply because we like it that way and this is what we want to "fly" in sim. The natural order of progress is to keep adding new detail to projects to get closer to "as real as it gets" and accurate systems have been done, but the visual and aural feedback for these systems have not been done "as real as it gets" in our opinion.....very close yes, but still room for improvement. For example, annunciators lights "fade on" and "fade off" as their filaments heat and cool....they do not come on instantly and your eye and brain knows it. Needles on indicators have mass and exhibit a movement behavior that is distinct...when its not done right, it looks "not real". Accurate systems goes without saying, but we wanted to take it to the next step and really make you feel like you are in an alive cockpit. Our biggest frustration is that this project, being our first effort, means we have had to sink a lot of time into infrastructure code....a sound engine, EFIS drawing engine, FMS, electrical and hydraulic frameworks, etc. This takes time away from applying the code to more features. We are fast approaching the time frame where our wives and families are starting to squirm and we will have to get this thing out soon. That being said, I can already tell you that any features we do not have we are more than fully aware of and will work those "fun extras" in just as soon as we can placate our families. At the very least, you will sit in this cockpit and fly this thing using the same interaction / procedures that captains use to fly the real thing. You can see this in the upcoming preview videos in the next day or two. Oh and one final thing....the switches on the overhead are currently "reversed" because that is the way Lufthansa has their 737 classics, BUT that will not be the layout as shipped. We will ship with the overhead switches "Boeing normal" Tom Kyler IXEG

This is a trade-off of sorts. Add-on revenue is the the fuel for the scenario you are asking. If everybody waits for the market to become mature with add-ons, that only stalls the very market they are waiting to mature. In the case of the rise of MSFS, there was no real competition so all revenue went into the same fire...easy-peasy. What is needed is for flight simmers....not MSFS'rs.....to support x-plane with purchases of quality add-ons. By purchasing quality add-ons, they enable the devs to continue to develop quality add-ons, hopefully devoting more and more time to it and grow the market. Many markets have some type of catalyst event that kicks off the growth and for x-plane, I believe that will be the high-end airliner simulation market, which is just now coming into its own. With more folks buying the airliners and becoming x-plane users, that creates a bigger market for other devs to tap into and so on and so on. It will get there. TomK

I've talked to Pete and I can see all perspectives and understand peoples perspectives....and taking into account all of us are born with differening senses of perspectives, its natural to have to deal with this on regular occasions, it comes with being human. The big thing is we get past it and keep trying. Whereas some folks see it as "x-planers" vs. "FSX'rs" and treat each other like clubs with entitlement, I don't view it that way at all. To me it's 'Flight Simmers" and right now most of them are using FSX. Treating FSXers like they're some outsider to me is not my perspective...they're not some 'other market', they're my market. To me, my market is not owners of x-plane, its flight sim enthusiasts. I would phrase it as we need more X-Planers, IF we want to make a living at this and therefore increase our production......and it is an 'insinuation' that if one is not currently an x-planer, then they are a 'MSFSr" so the sentence is valid depending on your interpretation. One reasons for the org vs. non-org is that financial resources / market share were pretty small @ 2008 and if the org was accumulating all the resources, then this isn't good for growth (except for the owner of the org). The whole x-aviation story is akin to a liberation story to introduce competition into the market that benefits the end users. Like any liberation story, its gets nasty, folks take sides and fight it out until the uprising is suppressed or independence is gained. After 5 years, I'd say x-aviation and x-pilot has earned its independence and the conflict needs to be over with objectives now met......but it was necessary at the time. Given the sales trends for the last 5 years....I can tell you that unless more flight simmers adopt x-plane....us add-on developers will have to maintain other jobs which limits our time to work on x-plane.....so the concept of whether or not we NEED FSXers is relative to what our objectives are....Mine personally are to do this full time and make great add-ons so I myself need more x-plane users and the sooner FSXers also purchase x-plane, the faster x-plane will grow IMO. Tom Kyler IXEG / Laminar

FWIW. ...take what you will from it. Note copilots left hand when he flies...most of the time when he moves it down......he's adjusting trim. MU2 a busy plane to fly. TK

But is restored in a 1.51 patch yet to be released as of the date of this post. TomK

Hey John, The problem will occur any time you swap aircraft and you (or a plugin) will have turned down the lighting on the previous aircraft as these lighting values are persistent between aircraft. IMO they should NOT be and I have lobbied to have default aircraft load with consistent values. Aircraft with custom plugin programming do not usually exhibit this behavior because the author can set the lighting in the plugin when their aircraft is loaded...but for default aircraft or aircraft with no plugin programming, they are at the mercy of the lighting settings carried over from the previously loaded aircraft. Being that there is no standard between authors, it is a hit or miss as to whether or not one author uses a lighting slot that causes an issue for the next aircraft loaded. There are some "best practices" to avoid this scenario, but not all authors practice it and I have been guilty of it myself. You should not have to restart the sim to fix this on the King Air.....if you load up the King Air and some instruments are dark (I assume either the EFIS / radio /LEDs), just look up on the overhead and turn up any lighting rheostats that are "off"...a few of them will probably be set to off depending on what the previous aircraft settings were....but on the King Air, particularly for the avionics knob. For the King air daytime flying, you need to always leave the avionics lighting rheostat up as well as the gyro instruments I think...but can turn off all the others. TomK

John, I'll see about the light issue, this one has reared its ugly head from time to time and is one of my *sigh issues.....due to differences in opinion internally about how lighting should be handled. The usual culprit is that you turn down a light of some type on the King Air and that lighting value somehow gets carried over to the next aircraft who uses a different light "index number" for their isntruments....so what controls the engine lights on one aircraft might control the EFIS lighting on another. There is no standard, as authors we simply have 16 lights to choose from based on ID number. On custom aircraft, the author can just set the lights where they need them to be via a plugin when the aircraft is loaded, but when the aircraft is unloaded, (another aircraft is loaded)...then unless the next aircraft uses a plugin to manage the lighting OR they do not manage the lighting (very common also), then as mentioned, that lighting rheostat value will hold over from the previous aircraft. This isn't supposed to happen as default aircraft should initialize to a default lighting value that is sufficient to see the instruments so when this does happen, a bit of digging is in order. Finally, we can't rule out the fact that there is a weird problem you're seeing either because after nearly 2 years, this isn't one we've heard about. Sooo....what to do about it is try and discover if there is a knob on the King Air causes the issue.....however, it is compounded by such considerations as: Are you going from a default aircraft to a plug-in controlled aircraft? vice-versa? I'd suggest turning all the lights up on the King air, then moving to different aircraft...then go back to the kig air and turn all the lights down (and the EFIS will go dark on the King Air when you do this) and then load up another plane and we can start there. About the brake light, I'll see about getting that in. TomK Laminar

Ok, Got some clarification. There is a proposed change to the engine model in x-plane, it won't affect us at IXEG and anything beyond that I can't speak for the 757 team, so their "press releases" are the goto information from them. TomK

I just talked to Austin ...he says no one has contacted him about this. Having a 3rd party influence Laminar on core model changes is a dangerous thing. At IXEG, we have customized the engine model just fine through the SDK....so no reason the 757 team can't either and I will be quite vocal if another team causes us to have to re-write our engine model because they couldn't get it done. I would lobby very heavily against one team getting Austin to make such a fundamental change without consultation with a consortium of developers. Where did you get your information? TomK

Fredricksburg Texas: Hangar Hotel, 1940s style conference center and hotel on the flight line of Gillespie County Airport. 1 hour west of San Antonio in the hill country so centrally located from the coasts. Nearby drives to several state parks for hiking etc and historic Fredricksburg shopping (for the ladies) or tour of the Nimitz museum in downtown Fredricksburg. Popular fly-in spot too. http://www.hangarhotel.com/

Without a doubt. While the 737 is now high priority, I expect to take a lot of that experience and code base back into the MU2 for a 2.0 version, pretty much completely rebuilt. There is still a whole lot I still do not like about the current Moo and I want to be able to turn to any page in my POH here and have it work and sound like the real thing. I'd like it to be every bit as detailed and accurate as we're trying to make the 737. Usually the airliners get all the love, but I think a top notch turboprop with the same kind of attention and detailed systems simulation would be just as much fun in its own way and the Moo is just fun to fly IMO. I'd hope for a mid 2014 release on a Moo 2.0....have to get this 737 out the door before my wife kicks me out of the house. TomK

Thank you all gentlement for the kind words....it is very encouraging. It was my goal way back when to try and get folks to try x-plane and show what it can do and it makes me glad a few folks gave it a try. Hopefully the 737 will woo a few more. Indeed the Moo is special to me and what I have in my head for where I want to take it in x-plane means there is still a whole lot more to do. A lot of love is applied to the higher end airliners but I would like this Moo to be at the top graphically and simulation wise so there is not only much to do still, but much to look forward to.....more accurate engine sounds, new cockpit sounds, totally new high-res 3D, weather radar, deep electrical system with working breakers, better GPS, prop locks, more animations, real cabin lighting....moving map screen in the cabin...oh man, I got all sorts of cool ideas. TomK Got one in the box right next to me! Going to assemble it one day!