tkyler

Thank YOU pilotman. The org makes sure people don't know about us and it is an uphill battle. I would encourage everyone who believes in what we're doing and what we're trying to accomplish to spread the word amongst your friends and other forums. Some of you do already and we're very grateful. -Tom

This is classic "potato / Po-tah-to" or "half empty / half full" type of question; however, as a statistical survey, it does just dandy. A lack of simpler aircraft will limit some sim pilots, but not others. I don't so much see things as 'complexity' as much as I do "un-attainability". In my experience, people tend to want to purchase and experience something they could not do in reality. Knowing that a simulation you bought is as complex as the real thing is part of the appeal of saying, "Hey, I could do this if I had to" or maybe "So this is what it is like up there in the cockpit". Though the Falco is the most interactively advanced pit in x-plane, the MU-2 outsells it 3-1 still. The Falco is a simple single GA that anybody can experience (a single GA, not a Falco) so I think the appeal is limited. I too, find it more enjoyable to fire up some complex aircraft that I can't in reality. Given what I've seen from the market..as Dhruv states, I'd elect to go the more 'reality' based route if I was forced to choose one. Sure some sim pilots would be left behind, but someone always is.

Your suggestion is appreciated though I don't think we'll be doing that soon and here's why. Without a doubt our loudest complaining customers have done so because of improper manual installation where their products wouldn't work. They have cussed at us, accused us of being thieves, liars and cheats...and most people are too impatient to actually read installation instructions. Since going to single executable installation files, we've had ZERO issues or complaints. I understand the problems you've had with FSX, but we're not FSX and have not shown a history of troublesome installers. If we did, we would certainly take your request to heart, but no since doubling our workload with such a high success rate.

...and if you do buy, you can keep up with the progress towards the upcoming update to version 1.5...which is HUGE update to the cockpit. http://forums.x-pilot.com/index.php?topic=413.30

I can certainly admire that. We're not just set on giving up DRM at the moment, but as we've mentioned before, we are moving towards making it easier and more flexible. The end result we're looking to achieve is simply entering your x-aviation data and hit one button and be done with it, one time on each machine...across multiple computers even. That's literally no more work than logging into x-plane.org or x-pilot...and only once no less. I think this approach takes away every single argument against our DRM inconvenience save for two. 1.) Its extra work to enter your x-aviation user name and pass, even just one time....pfff 2.) It makes someone feel like a criminal....pfff I can live with both of those complaints. If the technology, expertise or some logistical issue prevented maintenance of the DRM system in any way, then x-scenery products at least would be converted to non-DRM. For that to happen, basically 3 folks would have to all die at the same time for customers to be left out in the cold. Several of us have the capacity to strip the DRM from x-scenery products and re-distribute if it ever came to that. I've even left instructions with my wife on what to do about it if something should happen to me.

Textures are "downsampled" based on rendering setting (except cockpit texture, which is always hi rez). So a 512px runway texture gets pretty blurry, but several 2048px aircraft textures will keep the aircraft textures reasonably sharp.

I'll add also Larry, that most of the ADF requests were from my European customers as you mention and grand total I've had less than 10 direct requests for the feature. That is most assuredly a small percentage of the total number of MU2 users so I suspect that you're very right as few people use it in reality...at least statistically speaking. I do like having it all in there though...certainly not a big deal to add it anymore (after a major workflow overhaul that is)

I should clarify. I've been a bit careless referring to "versions". I originally thought about calling the next update the "2.0" update because it was relatively significant; however, after a bit of thought and discussion with others, I've decided that "1.5" is more appropriate for the next release whereas a "2.0" version implies a significant overhaul. Version 1.5 is a refinement of the existing series. Now while ANY improvement can be considered a "refinement"...there comes a point where improving the product as a whole requires an extensive rework. An extensive rework in this case means scrapping the existing 3D model and redoing it from scratch. Improvements in a "2.0" version will be a new model, higher resolution textures, normal maps, more 3D detail and animations, more custom sounds, etc. Version 2.0 will take enough time and effort that I'll charge for the update. Existing customers would receive a discount and the overall cost might rise to $35.00. Now for that I would expect to deliver a product with the 3D you see in this cockpit ALL OVER! And I'd expect to provide even more documentation, more detailed tutorials to cover new systems and new animations and eye candy. So then this Version 1.5 is to make the MU-2 a more complete functional product from the "flight simulator" perspective. That is I want it to simulate the operation of the MU-2 in flight first and foremost. I left a few things out for technical reasons earlier but I feel every customer ought to at least get a relatively complete MU2 simulation...so this 1.5 update will be free for existing customers. Those are the autopilot mode buttons. The "shroud" that surrounds them has yet to be redone.

This is just a big image to share cause I like the cockpit so much. From the previous pic, this has more texture work, additional details added, instrument glass, more complete instruments, and lots of infrastructure for animation and the reworked plugin. Still left to do is is to rework the quadrant texture and refine the 3D mesh, still add more animation / manipulation infrastructure, then on to the plugin. I'll be using the Falco plugin as a starting point so a whole lot of the work is already, but I'll work on getting in the additional features and system simulations put in. Final steps will be the normal mapping and the lighting / LIT texturing. I figure the back half of August, early September for the update. Upcoming Oshkosh and Laminar work take up most of the week.

OK, I thought this was kind of cool. The MU2 has 5 fuel tanks with an auto transfer system designed to keep the main center tank full at all times until the outer and tip tanks run dry. When I built the plugin for the MU2 way back when, there were only 3 tanks so I had to "fake" the system. Now if fuel is always put into the MU-2 symmetrically...as it should, then this "faking" looks just like the real thing for the most part. So as I get close to the next update, I've moved from the 3 tanks to 5 as in reality and located all the tanks in their proper location. Now since there were only 3 tanks before, and these tanks were numbered 0, 1 & 2 , the plugin would use these numbers to simulate the fuel transfer system. With the 2 new tanks, they're numbered 0, 1, 2, 3 and 4 going from left to right. So then the plugin as of now will only transfer from tanks 0 and 1 into the center tank (2) until I rewrite the plugin to account for the 2 new tanks. The screenshot below was a test I was doing simply to make sure the fuel gauges read the right levels. It was fun to watch the fuel transfer from the left tanks into the center tank, first from the tip, then from the outer just as in reality....but when I straightened my view, I noticed the plane was leaning heavily to the right since the right tanks were nice and full...and it reminded me that the MU-2 does indeed have a fueling protocol for this exact reason. Many line personnel do not like fueling the MU2 because the tip tanks cannot be any more than 150lbs out of balance. Well the tip tanks hold 600 lbs each, which means the line personnel have to fuel one tip tank to 150lbs...then go to the other side, fuel it up to 300 lbs....BACK to the first side and fuel to 450....BACK to the other side and fuel to 600..then one last time BACK to the other side to top off. If this isn't followed, then the MU2 can have one side dip way down as seen in the screenshot. The new update will finally have the fuel control panel working and you can switch from auto to manual to manage the fuel transfer; however, such manual management on the Marquise isn't really done in reality except in the case of a fuel pump failure. And regarding "dragging" vs. "clicking" for switches and knobs. I'm going to have both. Switching between the methods will be done "in sim" without loading a new aircraft using a 3D type control panel. I'll simply have multiple sets of manipulator polygons with different commands whereby the control panel will disable/enable different sets.

Alex, The ADF does work; however there is no way to tune to the NDB frequency on the panel. This was because of limitations in x-plane when the MU-2 was initially created...hence an update :-)! To work around the problem until the next update comes out, I have created a simple plugin that allow you to turn on ADF1 and 2 and tune it so that you can use the ADF in the MU2. So the simple answer is yes you can use the ADF but you'll need a simple plugin that creates a pop up window to input the frequencies. Please read the following post. http://forums.x-pilot.com/index.php?topic=396.0

I thought I'd do an update and throw up a screenshot of some upcoming changes to the MU-2 for version 1.5, which will be the last version on the 1.0 series. This update will pick up most of the functionality that was left out of the initial release and replace some of the older technology with newer technology. The artwork, except for the panel will remain largely unchanged. Version 2.0 will be a completely new, ground up rebuild whenever it gets completed. The following screenshots shows some of the new things going in. The screenshot was taken with a FOV of 60 degrees and a resolution of 1280 x 8-something I think. - 3D instrumentation throughout (as opposed to 2D mapped polygons) - A new mechanical ADI in place of the "EFIS" based 2D one. This is faithful to most MU-2s - Higher resolution textures on the intruments. - Larger numerals on the instruments to make them easier to read and more optimized text. Note the radio frequencies and barometric pressure on the altimeter...much easier to read! - A full featured Garmin GTX330 transponder lifted from the Falco. - More robust fuel systems modeling - 3D manipulators across the board - MUCH nicer night lighting. - Working ADF...(check that frequency eh? finally!)

I've found some time to move through the cockpit and change some things over to 3D. The following image shows the new engine gauges (on right) vs. the old...well at least the torque and temp gauges anyways. The lighting is a bit better and I'm moving to bigger fonts to make the gauges easier to read. The JPG compression has degraded this image a bit...it's quite easy to read in sim. The blender file is setup now so that's it's relatively quick to move through and make changes, these gauges were retextured and animated in about an hour....except that I'm on other obligations 10-12 hours a day it seems and eating or sleeping the rest of the time. I think perhaps by mid-fall, I'll be able to concentrate on my add-ons nearly full-time once again and hopefully make some good progress.

Maxime, you'll need new activation keys for those products now that you have a new computer and Jim is right, contacting Cameron at x-aviation is the way to go. I have to warn you though... that x-aviation is in the process of moving to new facilities and there might be a slight delay in a response. x-aviation has the best and fastest response time in the x-plane market but you just might catch them in a short busy phase while they relocate.

I'll hazard a guess. If people are not aware of what others are working on, then two entities might end up working on the same project and losing valuable time. If competing teams are of differing levels of competence, then it's possible they may both decide to move forward with their projects or they may elect to stop working on them. One of the few ways to judge competence is to know who is working on what....so it's plausible that just knowing who is working on what is a courtesy to other developers. I myself ran into this recently when a fellow developer was not aware of my King Air B200 project. He was quite far along actually, though not as far along as I. He contacted me and let me know he would cease working on the project. I told him that I certainly could not expect that from him though I appreciated the gesture. I felt bad for him because he was put up to the project by someone who WAS aware I was working on a B200...someone who would stand to gain from his doing a B200...someone who was willing to sacrifice someone ELSE's time for their own gain...but I won't say who. Anyhow, the x-plane market is growing quick and some of the more desirable models are going to be attempted by multiple teams I'm guessing and knowing who's working on what is just plain nice. I know a few models I won't be doing because of it, regardless of how much I know about their project.

Sorry for the stupidly late reply. Well some nasty stuff is done. By that I mean totally rearranging the Blender file earlier this week to be "modern method" compliant. I reluctantly trudged through the file for a few hours and got everything cleaned up to a point I can begin "re-animating" and "re-manipulating" everything. That part can move relatively quick. The final and more difficult part will be re-writing an entirely new plug-in. I have the old code of course, but will have to hand pick my way through it to integrate it into the new framework. I plan to hole up for 3-4 days sometime this summer and just hammer it out. What you can expect is refinements in the 3D interaction...better cockpit lighting, of course the ADF will be added and some higher resolution textures on the instruments..and I'll be integrating the Garmin 330 from the Falco too. Fuses and electrical will not make it into this "V1" run I'm afraid...it's just too much work. A future V2 run is desired...in which a new 3D model is done on many many parts of the aircraft, higher resolution textures, normal maps..and some V10 features also. This version will go for a more robust electrical system and if done right, should not need much more refinement over time. That's the desire anyways, as usual, we'll see how it pans out.

Thanks for doing this Zach. I still haven't gone over it yet! :-[ I'm trying to meet a deadline today and hopefully I can check it out leisurely soon. You know a lot more about it that I do though; however, this is the kind of thing I'd like to put on my web site and I guess it'd help if I actually tried it!

Despite the fact that Dan comes across as a "knowledgeable mentor" because of his tutorials, from what I've seen and read, the ERJ is not as efficient as it could be. Dan's taken what I call a "brute force" or "simple minded" approach. I don't say this to belittle Dan, far from it, he displays a well rounded knowledge in lots of areas but expertise in less. Javier, by comparison, is a professional game developer, not self-taught 3D hobbyist as Dan is and understands quite a bit more about game development. As such, I'll bet the CRJ performs quite admirably given its level of complexity. My point is that I am confident that complex planes can be developed without massive performance hits. Obviously more complex aircraft will take a greater toll, but Dan's ERJ, with minimal systems simulated should not be one of them. The Falco plugin is every bit as big as the MU-2 one and has several hundred custom datarefs and nearly 100 manipulators running every flight loop. Now I have to turn down my clouds and rendering settings to one below max...but I'm running a Pentium 4 with 1.5GB ram so I have an excuse :-). Still I see 30 FPS in that configuration. The "marching ants" problem is very much a mesh issue and not a texture one. Dan can argue this but he'd be wrong. This is nothing more than a "clue" that there are some issues which Dan can't see yet and it's probably affecting his performance adversely. This is Dan's first real complex aircraft though and I'm sure he learned a lot from it...my concern is....how much bad information has he passed along in his tutorials? I can't say as I've watched them but I certainly feel their positive impact is probably much greater than any negatives. Do not judge future products performance based on any other product. Juggling quality and performance is in the hands of the developer and all developers are not created equal...nor are developers skills static, they are continually evolving. My personal opinion and impression...without having actually tested it but having plenty of knowledge in the topic.....is that's its a pretty facade with a weak foundation. It doesn't surprise me to see FPS issues. His foundation needs repair...and those are tough. The MU-2 suffers the same type of issue and I'm having to pretty much rebuild the plane.

I'll claim low spot on this pole so far Pentium 4 - 2.8GHz 1.5 GB RAM NVIDIA 8800GT (makes up for a lot) 7600 RPM SATA drive Two Backup Drives Windows XP Ubuntu Linux - Dual Boot 2-23" LCD screens Kensington Trackball No flight sim hardware I run some defrag utilities and keep a clean and efficient drive to make up for the slower processor. I use no background images or window effects (I use Windows classic theme) , turn off lots of services unless needed and this keep resources to a minimum and it's actually pretty quick.

Definitely, and I do that on the Falco...at least on a lot of datarefs, I could probably stand to do it on a few more, but it's the "cleanup" on exit that is a courtesy to the end user so they don't have problems with subsequent aircraft that I was wanting to convey. Something about setting datarefs by plugin is carrying over to the following loaded aircraft. I'll ask about this one to laminar.

This is a note for developers. X-Plane handles interior lighting with two datarefs: sim/cockpit2/switches/instrument_brightness_ratio[n] sim/cockpit2/switches/panel_brightness_ratio[n] These datarefs are arrays that hold up to 16 values (indexes 0-15). The range of value is between zero and one. The default values found in these array variables when loading an aircraft is 0.75 for all indicies. When using a plug-in to manage these datarefs, it is important that you reset all the array values of these datarefs to 0.75 when unloading the aircraft, otherwise, the next aircraft loaded can load with the previous lighting settings. If the previous aircraft had some lighting set to zero, then the next aircraft loaded can have dark instrumentation and look like the unit is off when it is not. Here's the code I use to set lighting upon exiting the aircraft: void Controls_reset_lighting(void) { float i[16] = {0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75, 0.75,}; XPLMSetDatavf(xp_DR_inst_brt, i, 0, 16); XPLMSetDatai(xp_DR_nav2_power, 1); XPLMSetDatai(xp_DR_gps_fuse, 1); }

it's a lighting rheostat issue. It IS an x-plane problem, but I workaround this since I use a plugin. The 1.2 update fixes the issue, but is no guarantee that others' won't handle their business in the future. EDIT: The fix for developers is to iterate through and set every light level in the light array datarefs explicitly on loading your aircraft...and THEN...when unloading the aircraft (on XPluginStop), you reset the light levels in all the arrays again back to "default values"...which is 0.75 across the board. This way, if a user changes the light levels on some instruments in an aircraft...the next aircraft will not suffer from the previous aircraft's light levels as set by the user.

Picked this quote up from the org. I passed it through the Google Translate Filter....with settings to translate from "hype -> english" and this is what I got out. After further review, I'm come up with some observations. Nobody's forgetting the 787.....at this juncture, it just doesn't appear to be worthy of mentioning at the quality level being discussed in the thread that quote was pulled from. No need to jump in our faces waving your hands...we see it! Secondly....if Boeing has supplied dimensions and 3D models, then why does almost every cockpit element look off proportionately? As Google translate told me..."dimensions" probably means some overall dimensions and nothing too specific. Thank goodness for the google translator or I might have thought that Heinz was a privileged member of the Boeing engineering society and felt quite jealous that I couldn't get in. Seriously though, I think there's a market for everything, including Heinz 787. Personally I like Heinz and his work's place in the market, he is probably the best at balancing quality / price in my opinion. BUT PLEASE....don't start saying that the 787 belongs in the same quality category with the 777 or CRJ and other heavies in the works, we're not blind man! The fact that the quote comes from someone who stands to make money off the product, with no real supporting points is just unprofessional...and is the real reason for my posting here. Perhaps if a watermark on all the textures saying "officially licensed" were included, it might make it a bit more real eh?

Of course we agree with you! No one has invested in such a project...because all the developers who CAN do such a project are tied up with other projects. X-Plane has only recent included technology to attempt a PMDG style simulation (not 3D art...x-plane is already there) and nobody has really finished up their current projects to take on heavy as you suggest yet, but someone will! A PMDG style project can easily eat up 6000-8000 man hours so the return on investment has to be there too. It should be in the next year or two though....add to that the dev time and you might see a PMDG style simulation in 2012 or 2013.

Everybody knows that commercial passenger aircraft are the most popular market segment in flight simulation. There is a bit of a "rush" to get some payware airliners to market and being that the market is non-existent at the moment for x-plane, then anything is better than nothing. That is what Heinz will capitalize on and he'll make a decent amount of change from that segment of the x-market that is starving for some airliners. The quality is mediocre enough though that it does not preclude development of another higher quality 787 should someone choose to make one. Now if he charges 40.00+ US or something for it....well then that'd be ludicrous...and if someone actually paid that much for it....well then call Heinz a genius. Hopefully, the price will be commensurate with the quality and the x-plane development community won't look like it's gone crazy.