tkyler

good luck Garyth. I'll check in the morning when I get up myself...after a night of less cultural activities and see how you fared. TomK Laminar / IXEG

to mGN: I responded to your scenery question in the scenery development forum. http://forums.x-pilot.com/index.php/topic/4269-airport-on-plateau/

This is in response to user, MgN, but is probably applicable to others. Sometimes you may find that your airport sits on a high plateau, way above the surrounding scenery. This is set by a airport altitude value at the top of the apt.dat file. See picture below: If you are building your airport in WED, then this altitude is set from within WED. There was a bug in WED in the past whereby this value would be input as feet, but would export as meters. The thing is that x-plane READS the value as feet. So if you put 100' elevation in WED, WED would export that as 328 and your airport would be on a 228' foot plateau. That bug has since been fixed, but every now and then it rears its ugly head in some capacity I know not why. The straightforward solution is to go into the scenery folder, locate the apt.dat file, open it up in a text editor and set the value to the proper airport elevation. You can play with this value and reload x-plane to see its effects. TomK

mGN, I am in an absolute rush to leave th eoffice, but will reply (or someone else can). should be a small change in a text file. gotta run! back in hour or so.

Intrance, as the developer of the MU2, the start locks are near and dear to my heart to simulate. X-Plane does not simulate this and I haven't been able to get Austin to implement it yet. It is possible to do some with custom programming, but it becomes very involved. The x-plane engine model is the most difficult part of the simulation to intervene in and overriding the prop pitch in x-plane to implement locks means writing not only your own prop governor algorithm, but also a fuel delivery algorithm....all without fully knowing what x-plane does behind the scenes. After 10.20 goes final, Austin has a pretty long list of new systems features he wants to implement for 10.30 and I am putting prop locks on the list. Tom K Laminar

Until you feel comfortable visiting there, feel free to ask here (in the scenery section actually ). Some of the most experienced scenery developers regularly participate here. I'm sure we can get you answered in the meantime. Tom K Laminar

Two for one. another video of Jan flying around the pattern at Nice.

Hey guys. Jan has done another video showing some more details of the electrical system, which is pretty much ready to go. We have 17 electrical busses powered, we have equipment tied to each of these busses so when a bus goes down, things dependent on that bus go down. We have modeled generator heating and cooling, taking into account ambient temperatures and heat transfer coefficients, DC battery drain and voltage drops under heavy load, galley power, ground service bus with attendants switch, even coffee maker and hot air ovens. We have filament fadein/fadeout so the lights don't just pop on instantly. Momentary generator disconnects on switching power sources (you'll see lights flicker during this process) Warning annunciators are tied to their appropriate recall system..and lights dependent on voltage dim under voltage drops. Seems like a lot of detail but the coolest thing of all is you just let it run and it looks and feels real. No funny needle jumping, no instant on lights, it just all seems normal. Another video to follow shortly where Jan flies a simple pattern around Nice. -TomK

It depends upon which datarefs the authors used for the de-icing. Certainly it is worth a "double check". No visual indicators, but there is an indicator you can use. Go to the menu item "Settings > Data Input and Output". This will bring up a screen with lots of checkboxes on it. Checkboxes number 125 and 126 on the last column on the right are the icing status variables. Check the right most checkboxes on each of these "icing status" lines. Then when you close the window, you will see some numbers in the upper left corner of X-Plane. These numbers are ratios from 0 - 1 that indicates how much ice is accumulating. In icing conditions, these numbers will steadily increase. When you turn on de-icing, then the numbers should decrease. Above the numbers, you will see descriptions. When you see the same description twice, like "inlet inlet". The first one is usually the left side and the second one is the right side. I just confirmed on the King Air in beta 7, that "independent side deicing" works; HOWEVER, I think the King Air in beta 7 is borked for other reasons not related to ice so some of the switches may not work on the King Air....but X-Plane itself does have both sides de-icing independently now. -TomK

This should be fixed in the latest version, beta 7, I tested it on the King Air the other day to confirm. Also there now exists new, individual anti-icing dataref arrays for wing surface heat and engine inlet heat. These should be incorporated into multi-engine aircaft that have individual icing control for each side wing and engine inlet. TomK

Oh please, I can be as lazy as anyone....I see lots of problems with my work. If you change your mind, fire away! I have plans to one day provide a comprehensive training ground in all things development....blender, plane-maker, theory, scenery, development strategies, systems programming, texturing, etc and form a club for those who wish to engage in a higher level of development and are tired of scouring the net for information and how-tos and also want to learn tons of tips and tricks. It may be a good while yet because of my other projects, but I very much have a well-defined vision of providing training services for the community. As XP becomes more prevalent among flight sim users, and I believe it will, there will be a real need for training. I really enjoy it and fortunately, have been given good opportunities to gather lots of experience. In the meantime, I'll practice my voice-over skils and presentation software mastery Tom K

Hey pyoski, I'm so sorry, I've been out of town, I certainly don't avoid posting on purpose. Thank you for the compliments. Any suggestions you want to give on the King Air I'll certainly consider. The default planes are a bit of a mixed bag. The goal was to make them "much better than previous default aircraft", while still leaving a bit of room for payware developers to come in and do those models if they desired. Now mostly the reason for that was not to be "purposefully lower quality", but rather that the time to work on these was very limited relative to time spent on payware development. I had four of the default aircraft to do. We also specifically wanted to provide a mixed bag of technology, with some 3D instruments, some panel texture instruments, etc. so folks could look at them and see multiple ways of accomplishing tasks if they wanted. There are a few things I know I still need to do yet to the King Air and will chip on those continually...so please feel free to make any suggestion or criticism. With regards to copyright...unless you're reselling it or any part of it (say you use it as a base for payware) then you won't be violating anything. If you intend to modify / improve and distribute it freely, then by all means have a go at it. It can certainly stand for improvment in lots of areas but I'm always open to hear what folks have to say about it, good or bad. I wear big boy pants nowadays Tom K

A little glimpse into our debug screen as we refine the electrical system. When the APU is started, the APU starter uses the battery and induces a really heavy load to the battery. Anybody care to guess what happens to the battery and the annunciator lights attached to the battery bus during the APU start?

yea, well at least I can reply here Jack. Thus far we have not implemented any type of failures or chance / random scenario control. We DO have hooks for that though, the system was very much designed to be open ended and accessible at many levels. For example, we have relays that control the electrical system switching...and our relay data structure has a "isfailed" property so we can fail any relay. We also have 'isfailed' properties for busses, switches and a lot of other stuff....so unlike xplane which just fails a major system, we can fail a component which of course can bring down an entire system. This can result is multi-level "problem solving". One user might simply want to do an engine out situation....another might want a random failure of a really obscure component and then have to sleuth their way to finding it....pushing their knowledge to the limit. Regarding obscure situations...we really try to hold fast to physics as much as possible. The aircraft is a machine after all and works in a very well documented environment. For a scenario like the APU start in flight, we would probably do some research on operating limits and only allow the APU to start in the "comfortable part" of those limits. In the transition areas of the limits, we might put a sliding randomization factor that makes it anybody's guess, including our own. In such a case, your knowledge of the limits of the APU would play a part in making darn sure you make the best decision. Tom K

Yes, any customer who owns the MU2 at the time the update becomes available will be eligible for the free update. Tom Kyler

I would also like to point something most of you do will not see. By it's very nature, programming is a technical issues and hurdles must be overcome as limits are pushed. We are handling some very advanced issues that will pave the way for more full featured and reliable products. Nobody works with Laminar more than Cameron to solve these issues for the benefit of the community to grow the market. He consistently takes strides to remove obstacles for any and all developers and does so in the face of many ignorant and childish criticisms. I would like to simply thank him publically for the steps that he has taken on the behalf of all developers of x-plane. Thanks Cam! P.S. The MU2 hurdle was unexpected...a unforseen result of pushing some new limits, but the solution will ensue! Tom

I won't go so far as to say there shouldn't be a "budget" or that there's not a point where "that is too much". The fewer polygons / texture space that can be used to achieve a desired result the better no doubt. Fewer polygons on a cockpit panel means more for scenery for sure....but putting a number on it is not very straightfoward because there are so many hardware configurations and computers / graphics abilities are getting faster every year. What was a concern 3 years ago is less so today. Certainly having a poly budget is a prudent thing but that is for you yourself to place on your work...as oppsed to a "why can't we....approach" which implies that everybody's priorities are the same, which of course they're not. Some are perfectly willing to sacrifice a few FPS for the sake of bragging about having more detail than the next guy. It's a give and take situation for sure and just a matter of weighing the goals/pros cons. Given that everybody has different priorities though, the one sure outcome of any approach taken is that is that someone will complain about it. Tom K

OK guys...the package is in x-aviation hands for logistics. This is the MU2 cockpit that I envisionsed way back when for GA cross country. 300+ miles per hour on VATSIM "old school" is just a ball. Night lighting is wonderfully immersive and everything you need just works. The AP is great, flipping the radios from com1 to com2 on vatsim for tower > departure handoffs is just like the real thing. It's incredibly satisfying to fly this thing and not say to myself..."man I need to fix that!" Of course there is a lot of other 3D that can be cleaned up and that will happen, but getting all the interaction with the cockpit and controls just right really has made a difference. I think you MU2 fans will love it. This will be for XP version 10.11+ as that's the version I developed on. If I can find some time, I'll throw together a "over the shoulder whats new" video. As far as the future of the MU2, I expect to fix any minor things that the masses come up with that I missed for this 1.5 run.....there's bound to be a few but as far as higher fidelity simulation, custom sounds, all new 3D graphics and UI, that will come in a version 2.0 run at some time in the future....probably well after the 737 is out the door.

Im' sorry....my wording on "the update is done" was very poor! As my experience goes, the manner of the update will be as follows (X-aviation to clarily): All distributions at x-aviation, whether they be new or an update generally come with an installer application. X-Aviation will always notify customers via email than an update is available...i.e. they always do an announcement and/or newsletter with specific instructions on obtaining the update. The MU2 update uses X-Aviations current installer program and activation which is quick, easy and painless and reliable. The "old" activation system on the first MU2 is no more. So here's where we are. We (me and x-aviation) are looking at the MU-2 package as a "distribution package". We're checking all the files, editing the docs, preparing a "what's new" 'doc, generating promo images for a new gallery and prepping the newsletter announcement, reworking the web page, etc. This will take some days yet and the conclusions of that will be an email newsletter to hit customers inboxes letting them know that its ready fo download. As far as the 64-bit version of Gizmo goes, that is not yet available but also, will most likely be an announcment by x-aviation when it is in the form of an email. I have confirmed that Laminar will ship a 32-bit version of x-plane alongside the 64-bit version throughout the Version 10 run of x-plane....so we all have some stability for another year or two minimum. With 64-bit shipping soon, I'm confident Ben will get the 64 bit version going and we can begin testing all our stuff. Tom K

Gentlemen and Ladies, With the exeption of VERY tiny adjustments, the MU2 1.5 update work has been completed and we are rolling into packaging and some marketing stuffs, the logistics of which can take a while. Here's a list of 'major' what's new since V 1.1.1. There are numbers minor adjustments for the sake of reliability and usability. To remind everyone, this is for version 10 only, free for existing customers....and taking advantage of the latest goodies and bug fixes V10 has. This is the last "major overhaul" for the Version 1.0 run. New 3D instruments and higher resolution graphics New Attitude Indicator with mechanical flight director bars New altimeter and higher resolution texture for more legibility New clock More refined altitude set action with rolling digits New Garmin GTX 330 transponder simulation New ADF with 3-tier setting knobs audio switches for com/nav/adf/mkr/dme working Independent use of CoPilot HSI, coupled to Nav 2 [*]Fire warning systems and suppression implemented [*]Several new liveries added [*]New Custom master caution annunciator system implemented [*]New fuel management system with accurate transfer and engine/fuel cut off mechanisms [*]Convenient pre-set initializations so you can just almost just "get in and go" for starting with engines running [*]All new night lighting for immersive experience [*]Animated windshield wipers (actuate with overhead switch) [*]VS and IAS autopilot modes implemented along with others [*]Autopilot disconnect switch on the yoke works [*]Animated trim switch on yoke to conincide with trim commands...you'll see this when you actuate your joystick trim [*]More refined electrical simulation. [*]Almost all overhead switches wired up correctly (no fasten seat belt or no smoking dings) but anti-ice implemented [*]In HDR rendering mode, new 3D lighting for wing ice light, gear warning lights and real wingtip taxi lighting. [*]New installation and easy, painless activation system. A special thanks goes out to Jan (litjan) of the IXEG 737 team for beta testing...he's a 1-man beta testing wrecking crew and if there's somthing to be found, he'll find it. Another special thanks to Ben Russell and his Gizmo middleware scripting language. It's introduction has had a few bumps but its power and ease of use holds great promise. It's changing the face of simulation abilities for x-plane and we will all see this soon. And here's a picture of about a 99.5% final result look...in the daytime. (A bit more texture adjustments still) More screenshots will follow at release.

Report. Moo 1.5 update is in beta testing.....I have a very small punchlist to do but nothing terribly serious. All the "worrisome" stuff is done and today is "clean up day", chasing small bugs and refining operation. We still have to prep the distribution and new screenshots, go over the what's new docs and makes sure all that stuff is in order, but after flying the Moo for the last few days, minus the small punchlist items I'd say the 1.5 update is ready to go and a ball to fly compared to 1.1. Again, this update version is Gizmo powered and version 10 only. Stay tuned. I'll put a quick "what's new" list here later to recap.

More work today.....very satisfied with everything so. I'm well past the "stalling point" I found myself in a year ago and have the Moo in beta testing with Jan, the IXEG 737 tech advisor. He's already found a few things and there are yet a few things left to implement, but nothing near as serious as what I dealt with a year ago. Once the update goes out, I'll keep an eye out for the obvious bugs that need to be squashed but once it seems robust and reliable, I'll call the version 1 run over and work on new 3D for version 2.0. No time frame on that of course. Tom K

I am unsure about the state of reality XP products. They are great products when they work but of course are Windows only being that they run off of the Garmin Simulator software. I do not know if they currently work in the V10 run and you would have to inquire with Reality XP. But I do like the products. -Tom K

I still need to get my teensyduino going. I'll be pinging you on that one day Jack. Not in that exact paradigm. Lua uses tables for data storage...tables that have both index and hash components. They are highly adaptable to many physical paradigms. Tables can hold both data and functions and so can mimic classes but there are also other ways of approaching object oriented code. The Lua table library manages the tables in lots of convenient ways for you, including iterating in numerous ways and automatically growing/shrinking it for you along with "garbage collection"...so think of it as a ready-made linked list for you and you don't have to roll your own list algorithms for most tasks. It's made me 10x more productive on simulating systems...the entire 737 classic is written in Lua and to a very high level of fidelity, probably 30,000 lines + with nare a performance hit. Ben told me I'd get hooked and he was right. If the goal is accomplishing a simulation (as opposed to exercising ones brains in the joys of programming and learning C++ for other reasons), then I have definitely found my comfort zone. I can focus more on the algorithms and not get bogged down by code structure. It works great for me. Tom

I rewrote the MU2 master annunciator system today, bypassing X-Plane's altogether. The MU2 has a lot of caution warnings for "MU2 specific' components that x-plane does not have (like windshield temp) so now I have space to grow. Any caution light that goes off on the side annunciator panel now triggers the master caution annunciator on the dash. Some of these caution lights are currently wired up to x-plane datarefs but some of them are "empty". Eventually, I'll I'll put in code to simulate these MU2 specific functions. Caution lights are, of course, tied to the electrical system, and also (*cough) button/switch and bulb integrity. Bulb "burn out" and switch failure code (MTBF) hasn't been implemented yet, but will in the future. I was on a MU2 flight from San Antonio to Dallas once and the radio transmitter switch on the yoke "stuck" and we couldn't receive transmissions. We had to end up landing using the light beam from the tower for communication. You never know what might break on these old aircraft. Tom