tkyler

Ok...a little late, but at least we're moving.

Give this a read Geoff and see if it gets you a little further. If you still have a question, just ask here. TomK Laminar http://forums.x-pilot.com/index.php/topic/4473-future-of-blender-export-scripts-for-developers/

Glad to hear you are up and running Geoff. If the original aircraft that you are modifying includes a fuselage object that you plan on keeping, then you can, of course, use that instead of the aircraft object as a reference for your new panel. Exporting out the aircraft object from Plane-maker is useful for initial alignments of your custom 3D objects and landing gear placement but if the original author already did that and created the fuselage, then there is no reason for you to repeat the process and you can simply import the fuselage and build your panel relative to that since that is what you will see in the final output....unless of course you want to go through the process as an exercise, which is certainly worthwhile if you plan on doing more in the future..you can certainly never learn too much; however, if you are following Dan's tutorials linearly, then I just wanted to give you a heads up that you might not need to do this PM aircraft import step and could instead jump straight to importing the fuselage object and building your panel inside that if that is more preferble to you. Tom K

I think he means that the flight model that x-plane is supposed to be exporting as an object has no geometry in it at all. In planemaker, you can elect to "hide" plane-maker geometry and when this geometry is hidden, it will not export out as an OBJ with the export OBJ command. When authors make custom objects for aircraft, they generally elect to hide all the flight model geometry entirely therefore there is nothing to export. If this is the case, then go to the menu "expert > invisible parts" and in the lower left corner, elect to show all parts. After that, THEN execute the export OBJ command and you should have geometry export out at that time....and as mj12345 points out, this will NOT be the 3D objects used by the original author, but rather the flight model geometry. If you want to import the 3D objects, then you simply import those directly into blender. One caveat to blender importing of objects though is that it is pretty limited and it can choke on the import for a variety of reasons. The most common when importing exported flight models from Plane-maker is that the exported OBJ will reference its texture inside the aircraft folder but because the exported OBJ gets written to the X-Plane root folder, the texture path will be messed up and the blender importer will throw an error saying the texture doesn't exist. In this case, you open the exported OBJ file and delete the path after the word, TEXTURE at the top of the file...leaving it empty. When importing cockpit objects also...I think the importer chokes on manipulator commands and those commands have to be stripped out of the OBJ file before importing....and manipulators are found in the cockpit object only though so if you're not importing the cockpit, you won't encounter this situation during import. Importing "regular" old 3D objects as found in aircrafts "objects" folder usually works. Tom K Oh...and blender also imports x-plane 3D objects relative to the 3D cursor location, so make sure the 3D cursor is at point 0, 0, 0 before import or your imports will be misaligned when you export them back out.

First, thank you to mj12345 for reducing your signature a bit. Colin, don't get smart ass with me son, It's a reasonable request with good reasons. I don't expect you to necessarily share the view but I do expect you to be smart enough to know when to voluntarily honor a request. I asked politely that you shrink it, not remove it. I'll ask you again. Would you please reduce the size of your signature? Tom K

Would you guys please cut down on those signature sizes, they're very distracting to the content of the forums. TomK

Hey James. Public and private probably wasn't the best choice of words for those who know C++....so I"ll try and reword. Datarefs can be what we generically call, "published"...meaning that a variable has been made available for other plugins to see and read. The entire list of datarefs on Laminars dataref website are all "public" in the sense that they have been published (and can be seen by other plugins) but not in the sense that you can write to all of them. This list is all the "default x-plane datarefs" and the list grows slowly as new variables are introduced OR you coax Laminar into turning one of their internal variables into a dataref for usage in a plugin...which I have done for some electrical related values. Now the SDK allows you to create your own custom datarefs with your own unique name and when a programmer does this, they can elect whether or not to publish their datarefs.......and you have to put in a few small lines of code into your source code in order to do this so that these datarefs can be seen by other plugins....and DatarefEditor IS just another plugin. This process (and example code) of publishing your datarefs isn't the most visible in the xplane documentation and most C authors of plugins don't see it or even think about it. They figure who wants to know what their datarefs are? For myself, when I wrote my C plugin for the Falco, I included code that published every custom dataref I created so I could debug with DRE (data ref editor), but that's just me. I now use Gizmo and Ben Russell has included similar code so when you create a custom dataref in Gizmo, it too is published and can be seen in dataref editor. In all my coding thus far, I just haven't found a need to not publish my datarefs, especially if cockpit builders are going to be dabbling with our stuff. So the final synopsis is that all of x-plane's datarefs are published...and custom ones created through gizmo will be published.....but publishing custom ones created via the SDK is the choice/responsibility of the programmer and you pretty much just have to ask. Tom K

I'll expand a short bit on "datarefs". Datarefs are simply "public" x-plane variables, some read only, some read and write.... that x-plane makes available for monitoring and also for manipulation via a software SDK to allow customization or for debugging usage. There are multiple thousands of these datarefs for every conceivable parameters of x-plane....I wouldn't even bother asking, "does it track variable x?" because the answer is probably yes, you just have to find it. The list of datarefs are their descriptions (most of the time) are at http://www.xsquawkbox.net/xpsdk/docs/DataRefs.html There are two ways to utilize datarefs in a useful capacity. One is through programming via the SDK or a 3rd party scripting engine like Gizmo or SASL where the goal is to control these variables directly or (more commonly) derive behavior based on reading them.....for example say you want to make you own custom 3D airspeed indicator...you would need to read x-plane's pilot side indicated airspeed value to animate the 3D needle...and whether or not the pitot tube was iced up or the bus has electricity to power the gauge lighting. With regards to scripting engines, these 3rd party efforts interface with x-plane using the official SDK, therefore these engines are a compiled plug-in DLL, but then they go a step further and provide an easier to use scripting environment. The benefit is you can customize x-plane with text files, no compiler needed. Now for monitoring purposes..... say you don't want to customize x-plane but only monitor flight model parameters to see how your flight model is doing on an instantaneous scale, then there are two methods. One is right there in x-plane already, the "data menu"...where you click checkboxes and x-plane will output the most common dataref values like speed, trim settings, AoA, engine power, prop thrust, throttle ratio right there on the screen. You'll see this in a lot of screenshots...some green text in the upper corners of the screen. The second method is a bit more "geek" but is a plugin called, "Dataref Editor"....a binary DLL plugin you have to obtain and install (more in a sec) It's an absolute necessary debug tool for all things x-plane. It is a translucent pop up window in x-plane and what it does it displays dataref names and their instantaneous values. It has a filter text box so typical usage is to launch the window, type any text string from the dataref name you are looking for and the list will autofilter as you type and display the names of the dataref and it's instantaneous value. (which can be hard to read at 60fps sometimes) For datarefs that are writable, you can click on the value to make it editable and change it via keyboard entry and in this case, you are simply writing to the public variable....BUT this does not mean that x-plane won't immediately overwrite what you just wrote one flight loop later. Recall that x-plane calculates and writes to these variables too...some it writes occasionally and some it writes every flight loop. Anyhow, that's a really long conversation....but the thing to know is that this tool is specifically for monitoring and changing datarefs for the purpose of debug or experiementation. All you need to know about it is here: http://wiki.x-plane.com/DataRefEditor Once the plugin file is obtained and in the right folder, you can access it via the x-plane plugins menu. By selecting the menu item, the translucent window will pop up and you are ready for performance debugging. Tom K

no more big systems; however, we do still have some work to do on the vnav. I'd describe it more as that point when say...building a bridge from opposite sides you have to meet in the middle and get it all connected. The bulk of the mass is there...we just kind of slow down, hook it all up and make sure it's right. The lnav tracking is working great....you can hit lnav right off the deck and it will fly you to your destination, following the route beautifully. There are a few small systems laying around, but nothing like all the big pieces we have already done. We are setting aside vnav for the moment to focus on the 3D. Texture the engines, animate the main gear, build rear of cocpkpit and then cabin and texture it all up. After that, we will start tying it all together and hitting the final stretch. I don't think you will have problem at all with your card. I am running an i3 with 512 video card and I get about 30fps, BUT I don't run with much scenery either. If I crank it all up, things get slow. I've run it on Cameron's machine...an imac with 2gb video card and i7 processor and you can just turn everything up and it runs great. Anything new should be fine I'd think...my video card is over 2 years old. When we get everything working, I think we'll probably do a complete flight video...perhaps time-lapsed to speed things up, but we would like to demonstrate a cold and dark startup and flight...at least through takeoff and maybe part of a SID. TomK

Well we have made some good progress and came close to getting the exterior ready for screenshots, but not quite. One of our team members has had their first child recently and so is doing a lot of baby duty. We have the wings modeled, animated, UV mapped and an initial texture on it. We have to "dirty it up" and then texture the engines and we'll be doing external screenshots after that. I am UV unwrapping the engines today and this week so we are getting close. Modeling and animating the wings, engine reversers and flap structures was a big job and the reason for the "quietness" while that got completed but that is done and the results are really nice we think. so hopefully we'll have those external screenshots soon. Tom K

Man, I am rusty on that stuff, I haven't done DiffEQ in some time...thats one of those subjects where I did well at the time but when done said, "Ok noted...lets get back to algebra" MSFS goes back to 1980 and desktop computers then were really in their infancy and you just didn't have the processing power you have now to run calculations as fast as you can now. By the time Austin got into it (he's an aeronautical engineer by the way and is why X-Plane is structured the way it is), computers were fast enough where he took a more modern approach. It's not unlike CFD or FEA....stress analysis years ago was done with simplified equations, but now is generally FEA...the reason designers took different approaches is becasue different tools were available to them at the time. Because MSFS was the first though, their method is what "took hold" and dominates. That is right. FSX will never get smoother as computers get faster. X-Plane will run with higher framerates and get smoother as 'h' gets smaller (for the old timer engineers out there) This is the way x-plane works now....its "decency" is debatable of course. There is no frequency component of course, only forces. Austin uses a series of user definable point masses for Cg, fuel cell locations and weapons locations. Beyond that, he "empericizes" things like engine mass, radius of gyration, passenger location. These values can be dynamically modified through custom programming to get more realistic. Basically the way it works is Austin takes an element of a wing surface, it has an airfoil specification and that airfoil has a lift/drag curve associated with it (X-Plane's foil-maker app). Based on the AoA and airflow vectors, austin can figure the force and drag on that wing element from the airfoil curve. The more wing elements you spec, the more accurate you can get....just like FEA. That holds true for all the lifting surfaces. He estimates drag from gear (but the user can add more)....lift and drag from flaps is set via coefficients....the fuselage body is used for side area and side loads...but Austin also implements drag with rapid changes in cross-section of the fuselage along the air stream. Without sitting down with Austin and going over equations and code, it's hard to say how in-depth his state equations are...what I purport here is what I've gathered over the years of discussing certain aspects of the flight model with him and my own experimentation. The end result of all Austin's force calculations in a "calculation loop" are 6 instantaneous DoFs....for position, velocity and accelerations...these values can be examined in sim. TomK

Mostly "low level" numerical methods and dynamics modeling. By dynamics modeling, I mean deriving governing equations of motion based on mass, motion, forces, free body diagrams to build a "model of the system" and then evaluating step response, natural frequencies, vibration, accelerations.....all that stuff. I can't say I'm still proficient at it though having not practiced it for some time. The "low level" numerical methods is just that.....developing computer algorithms for solving large scale linear algebra issues, numerical integration techniques, root-finding techniques etc, but again, haven't done it in 15 years. It does still remain in my head though ready for use when needed as well as the challenges / limitations thereof. That's a tough one in that you are really asking for details from years of programming that the programmers just aren't going to give out and the best we can do is infer from what we do have....which fortunately, is enough I think, at least for me it is. There are several ways to model a phenomena of course. One can use empirical methods as FSX does....using point data, curve-fitting and statistical equations....but this requires obtained data from measurements of some type....OR, like X-Plane, you can use governing equations of state in a predictive manner. The predictive manner, using equations, generally does not account for variances in it's base form but you do not need obtained data either and can thus model aircraft that don't yet exist. The effort expended in either approach determines the accuracy of the outcome...both are simply different methods. Being that 99 out of a 100 times, you want to simulate a plane that already exists though, then the empirical approach will give the most accurate results, but only if you provide a sufficent number of data points. The greater the diversity of phenomena though, the more data you have to have and the data can get large and unweildy very quickly. If you say, "hey, lets model aircraft performance from still air to hurricane force, from -40c to 100c, from -15 AoA to +15 AoA, from min weight to max weight, from no power to full power...you could probably end up with a few billion data points in no time. With predictive methods, governing equations of state and a sufficient discretized model, you can calculate as many points as the computer can handle. The faster the computer, the more accurate the results (in general). You lose variance with this method though and tend to lose the "nuances" of modeling associated with the cumulation of minor inputs....such as cable stretch, skin flex, response time, wind gusts, etc. ...but the effects of these "peripheral phenomena" can be approximated in a limited capacity, an example of which is x-plane's "turbulence" and "prop vortex" vector fields. So each has a limit. X-Plane's approach will result in a smoother performance envelope....more accurate? not necessarily, but smoothness is really important to me as far as feel goes so therefore I choose x-plane as my platform in which to try and improve the accuracy. I think accuracy can be improved in both sims, but I think it's easier in x-plane and I think the final result is smoother in x-plane. Just looking at something as simple as "turning up the cockpit lighting" shows the difference to me. Tom K

I'm not going to address this question literally, but rather figuratively from a "design theory" point of view. Way back when I got in a discussion with a designer that absolutely insisted on using real numbers everywhere in the flight model. I couldn't really argue this approach, but at the same time, it puts the complete onus on Austin for simulating reality in code. Having done a bit of numerical simulation myself, I know that the effort involved to get realism in all possible dynamic inputs to aircraft performance is just not realistic. Now having had some classes in numerical methods, finite elements and mechanical thingys, I don't see the x-plane model as a "build it like the real thing and it will work". I see forces, moments, translations and rotations....and rates thereof. If one were to input numbers exactly and then "seat of the pants" common sense or flight testing says x-plane just isn't getting it quite right, then it's necessary to depart from norms to do it. A lot of time, we'll just "feel" our way there. Say the rudder was ineffective with actual chord an deflection values...perhaps austin's propwash model or wheel friction model isn't quite right...whatever the reason, we need more rudder control. Well you either deflect the rudder a bit more or increase it's area via chords or semi-length...or even incidence....only partial in this case as incidence on both might have been too much effect. You never really know what course a designer may take as is there is always multiple options. The thing i have found in my non-stop discussions over the flight model is that many time, people tend to discuss in "one regime".....usually cruise, whereas from a design perspective, I at least like to consider all phases. Sometimes I just have to compromise...reminding myself that this is a 70.00 sim that ain't too bad. Anyhow, that nice rudder incidence you put in to counter for P-factor at low speeds / takeoff will create unrealistic yaw at cruise speeds. The designer of the 172 is a gentlemen named "max". He sells products under the "DMax" label. Many of the default x-planes have been "built" for x-plane by "serious hobbyists"....generally pilots or 3D artists with an interest in aviation. The quality of the flight models is totally unknown as I have no idea the depth of their knowledge applied to their models....so just because a flight model comes from the "Laminar camp" is no guarantee as to its accuracy. I think as engineers, we will always have a more critical eye to these things since that's the way our brains work and why we got into the discipline in the first place....but still no guarantee. I've been guilty of working on a model and saying...."I just don't feel like spending x hours getting this right for 1 in a 1000 customers to notice". Tom K Laminar / IXEG 10 year head start....monopoly on the market and all the revenue thereof to support an army of artists to build all that stuff. x-Plane, while making great money for Austin initially...and now enough to support a small team is still only perhaps 15-20% of the flight sim market. Artists need to get paid and not enough folks are pouring into x-plane, funding such an effort. They don't come because x-plane lacks these things so it's a catch-22 of which the only solution I think is time. Being FSX is no longer developed and folks seem to like a lot of things about x-plane, they don't walk away, but neither do they flock. What I foresee is developers coming over slowly...like dripping water in a bucket. It grows slow, but eventually tips. I see no way around this currently. Could Austin set aside 100,000.00 and say, "this is for artists to make nothing but landmarks"...yea, that could happen but only Austin can ascertain if he would go there. Being that x-plane is a business and supports his other pursuits well, his incentive is going to be less than ours who are without these features. Austin maintains two other business and the mobile platform, which is a great revenue stream...better than the desktop possibly. This leaves x-plane desktop...our choice as enthusiasts as the "last in line" sometimes. We ARE however, discussing the issue and strategizing ways to deal with it, so it's not completely hopeless.

Cool. that sounds good! Sorry for the mis-info. TK

I think perhaps we have over 30,000 lines of Lua code on the IXEG 737 and while there is a performance hit, it is surprisingly low, especially on a modern machine. As Cameron says, with LuaJIT, the code is compiled code, not interpreted "on the fly" so it runs really quick....and TBH, we are talking functions that run in billionths of a second and compared to what XP is running, aircraft systems code (if decently written) is usually negligible. Ben Supnik concurred that unless you did something really irresponsible, it's unlikely you'd see a performance penalty. Here's my thoughts on each, clearly I'm biased towards Gizmo, but will try to be objective: C++: Doesn't require dependency on anybody else. Runs quick, full support of SDK. 3 platform support a PITA, having to reload aircraft to reload the plugin is a PITA. That's what put me off on C++. I can do it, but my goal isn't to have fun programming or challenge my programming skils, my goal is to produce a simulation. So while I've done two C++ plugins, I prefer the Lua scripting. Gizmo: Depends on Ben Russell. He dies or decides to pull it, your stuck. Ben's been around over a decade though so he has my vote. Gizmo has some licensing restrictions that favor X-Pilot and X-Aviation....don't expect to use Gizmo and upload work to the org to share or sell.. Almost full support of SDK functions though, including openGL and openAL functionality. Also has support for particles and physics and internet communication (correct me if wrong Ben). Gizmo mimics the x-plane SDK API very well so it's a bit easier for me to comprehend having worked in C with the xplane SDK. Performance perhaps a tiny bit behind C++, but for me that is not enough of a motivator to ditch the crazy development speed I get with Gizmo. No support for easy 2D popups, you have to make your own, but the tools are there. SASL: Depends on somebody...I'm not sure. I think Philipp was the last to "save" it. SASLs open source with no real restrictions. I do not think the original authors works on it anymore but I can't confirm this, anyone? SASL has a specialized API originally designed for 2D "gauge programming" and is therefore very suitable for 2D pop-ups and you'll see lots of SASL products utilize this feature, but has support for sounds also. I don't think it has the graphics horsepower of Gizmo's GL implementation though. We use Gizmo GL frame buffer objects on the 737 to render to offscreen textures and other things necessary for EFIS drawing operations. With the ability to read and write datarefs, then systems coding is pretty much the same for SASL as it is for Gizmo. As far as C++ being a "real language" compared to scripted languages, that argument does not work for me. I think such an argument contains a bit of "programmer pride", a sort of status symbol to say, "hey, I'm smarter than you...you can only program in a scripting language"....but that is ridiculous, these are all just tools and you should use the best tool for you to get your goals met. I've used both and my development requirements are speed and stability..speed of development, speed of code running and stability of the running code and the stability of gizmo development. In my opinion, you can produce faster results with Gizmo than C. Plain text files, 3 platforms supported...no loading and unloading of aircraft during development lets you focus on getting results, not fighting platforms and compilers. As to why I myself would pick gizmo over sasl....the first reason is I'm familiar with the API structure and the 2nd is the more robust openGL implementation. If neither of these matter to you, then I think either would fill your needs. Lua can definitely handle your math whether in SASL or GIZMO and with its primary data type being a table (same as object in javascript...also called hash table.....the whole key/value pair thing)...you would probably be very comfortable with Lua right away. Tom K

Ah, the default 172. Yes, the author is using one rudder for the top half of the vert stab and the 2nd rudder for the lower half. he does this because he wants to encompass the wetted area that a real 172 has for the "fin" between the vert stab that runs up along the spine of the fuselage. This would allow for x-plane to simulate the crosswind effect on this area. This is not the way I would do it myself. As you can see from the picture, x-plane will not only calculate side forces on the fuselage, but also on the "lower rudder" as well, resulting in a lot of side force on all that surface area. X-Plane has no concept of "wind shadow"...that 2nd rudder is contributing to the behavior in yaw. Being there is no real surface "inside the fuselage", this could yield some inaccruate results in some instances. It could also be "approximated by inceasing the vertical depth of the fuse a bit to get some of that side area from the "dorsal fin" and leaving out rudder 2 entirely. The way you tell is to go to the "wings" page and click on the vertical stabilizer tab. There are two rudders and if either one of them has a semi-length value greater than zero...then the values for the control deflections and chords are being used. In the case of the 172, they are definitely getting used. It would, but several of these aircraft are a bit older and contracted out to individuals...so its possible to encounter anything. We have done a measure of quality control though...but plan more. We are as prone to making errors as anybody else. This is definitely a heavier subject. I'm a mechanical engineer by education, with focus on finite elements and numerical simulation...so I see things a bit differently than a lot of users. If you have 1 rudder with surface area X and deflection of angle X. THEN you place a 2nd rudder with surface area Y and deflection value X into the model. That's the same as a single rudder with surface area X + Y to x-plane. When it comes to forces on a body, you can sum up all forces and moments and replace them with a single point on a body applied at the center of mass. If you have two rudders, then x-plane simply calculates the moments from both rudders , superimposes the forces and the net effect on the body is a single moment. If I have two guys stand on your chest, each 100 lbs...thats no different than 1 200 lb guy standing on your chest...you don't need to figure out which 100lb guy to use, they both affect you. x-plane doesn't figure out which to use, it simply calculates all forces from all force generating bodies and computes a net force on the aircraft. It would be no different if you stuck your hand out the window.....you introduce a new surface and a new force...x-plane would figure the force, and add it to all the others. Tom K Laminar / IXEG

Most likely these values are not used. X-Plane is a bit of a "what if" software and it is perfectly feasible to have two rudders each with different chords and movements ala the Rutan boomerang. Austin generally likes to give folks options and usualy two rudders are enough to experiment with. The way x-plane works is it looks to see if there is a vertical stabilizer with a length greater than zero... IF there is, then it will look to see if there is a rudder (the chord ratio) and if so, how much the rudder moves. You can have zero for the vertical stab length yet x-plane will retain values in the rudder deflection fields if you populate them....so could be a author accidentally put the values in the wrong field...(done that myself) and just went to rudder 1 to input it OR it could be that the author is trying to fine tune the yaw behavior in some fashion with a 2nd rudder. Contrary to many folks believing that such a technique is cheating....the truth is an x-plane aircraft is a numerical / mathematical model and if a 2nd rudder used in some capacity gets the final results closer to the real thing...then that is a viable option. 3x4=12 just like 6x2 does...not the only way, but you never know what people are going to try. Tom K Laminar / IXEG

Carenado made a really nice C208 for XP http://www.carenado.com/CarSite/Portal/index.php

One thing that is not lost on us here is that we...... having a free download library, are also subject to the same kind of situation over the long term; however, being the file library is in its infancy though....and developers that upload here also seem to upload to the org file library.....that means our download library serves no real purpose except to serve those with conviction against supporting the org......and right now, that is a small bunch of dudes and "long term" is probably just that....really long term, as in possibly never. So unless developers upload here only... the x-pilot file library really won't serve the needs of those except the convicted and that isn't the fastest growing group. BUT....as I said, this is not lost on us and we are always looking at new ways to build a better community and experience. So it's not just a matter of us hoping the file library gets big enough with community contributed, x-pilot exclusive content to make folks come here instead of there because I don't think that will happen nor do I want it to. Developers generally love attention and adulation and you get a whole lot more of that at the org than here so the incentive to host files here only is very small. So we're considering (Ok, I'm trying to sell) to Cameron a few different ideas for steering x-pilot and it's community experience. We dont' just want to be a smaller version of the org or even AVSIM, we want to try some new stuff, quality over quantity. Time will tell if we can get it done and if it will work. TK

Nicolas antics won't be the downfall of the org...it may not downfall at all. The org was built by the community sharing free stuff and users wanting that free stuff. There is, was and always will be a desire on the part of flight sim users to seek out free stuff of the highest quality. The two biggest flight sim sites are also the biggest repositories of free add-ons. Until someone provides more than the org does, it will survive. Only time will tell how long it will thrive though depending on whether or not the market gets tired of it, but its probably safe to say its got a whole lot of years left. The attraction of the free stuff fuels the membership and we all know where there are lots of people there is marketing opportunity and money to be made and that is Nicolas interest....he's a business man. Everything comes with a price of some type though. To get all that goodness, one usually has to subject themselves to various things, be it Nicolas behavior...forum marketing, newsletters, crowded forums, fiesty mods, mediocre sales support, too many topics or the whole "needle in a haystack" when looking for good free stuff. The org is a volume-based, 'low-cost' economy....and for those of you familiar with Wal-Mart, you know that there is always a large following for it. I shop at Wal-Mart for some stuff, but they do not always have the product I am looking for when a certain level of quality is desired. I rather like having an alternative and right now there really isn't one so for a lot of folks its the only game in town. Now I have friends who have become reasonably wealthy because they have a product on the Wal-Mart shelves and that appeals to lots of folks and is why the org will always draw the most developers as they all have $ in their eyes and volume means $. Getting a product on the super-store shelves is very appealing to folks, but you never know what you're going to get. I never thought I'd see a marching dinosaur for sale at a flight sim store. Nicolas has his hands full over there given the org size and a part of me says he's doing what any other business man would do in his shoes, but the other part of me says, 'you went there , you made your bed, you fed the monster so deal with it' Right now his best defense is the ban button. When given a choice between giving good customer service or working on the next newsletter that will result in more sales by new flight simmers, take a guess what path he'll choose. Remember, this is a renewable market and in his volume based approach he honestly doesn't need repeat customers, a new crop of them are born every year! If one person balks out of Wal-Mart upset they got a bad deal, Wal-Mart ain't goin' down. The org is a good resource, but to me it's like that Wal-Mart resource. Yea it's got just about everything....but you might not get catered to very well, not always easy to find help, some of the employes are rude and not interested and a lot of the stuff is cheap but low cost (free) is the market. You know what you get when you walk in. I am interested in a new type of place myself. TomK

King Air is a bit tough to start. you have to set the condition levers to lo idle and then his the starter buttons and hold them donwn for a really long time. I've tweaked this for the next beta 12...which shouldn't be terribly long. We are coming down to the last few betas before RC. The starter model is much improved over this beta 11, being much closer to the real thing. TK

I talked to BenS and the answer is, "not yet". Here's why. BenS is trying to merge Ondrej's (Sam256) 2.49 work into these scripts to kind of provide a "super 2.49" strain. The XA strain by BenR and Ondrej's scripts both have limitations for various valid reasons because as Ben Supnik says so well...."it's just a tough damn problem that demands time". We're not going to release half-baked scripts out there, it would cause more headaches. We think we're in the "few more weeks" range though so its coming. I will say the difference in workflow is amazing! In 2 hours, I took all the loose collections of my old RV6 project...all the texture files, photoshop files, disorganized folder structure, blender versions and had it highly organized with current, proven dev standards and exported out the entire aircraft (7 objects) in one quick export. Threw on some new V10 lights, tweaked a thing here and there and all the sudden, a project with too high maintenance costs just got viable. I really hope we can develop an open project guild here, there are several technical and logistical issues to think about, but I'd consider it darn near developer utopia to have common projects with team contributions...everybody on the same page and stuff like airfighters Avanti the result. Development is just fun! TomK

Will take a peek Zach. Thanks! TK

Thanks e. Hopefully I can get better maintenance in the near future. We are reworking our workflow at Laminar and these efficiency methods will cascade down to my other work. I think it will have a very good benefit for the purpose of updating and maintaining products more. I'm moving a lot of my projects over to the new project format and when the dust settles and 64bit gizmo is stable and x-plane is stable at 10.20, we can endeavor to get everything back up to speed. TomK

e. The plugin is inside the Falco folder. The license is tied to hardware so if you've changed hardware or operating systems, that would affect it. Cameron knows more about it than I do. If you have issues running it becasue of licensing, I'm sure Cameron can get you fixed up if you contact him. We always want to keep you flying. One thing though, he's out of country at a family wedding and not quite on his normal schedule. Jet lag and other things have him checking in sporadically, but I know for sure he checks in every day. TomK