tkyler

Simon....little favor? I don't have Phillip's Island scenery installed. Could you grab about four, creative, high quality screenshots over Phillips Island showing the Falco and post them here? At least one interior angle would be good. These screenshots will be going into the Falco Builder's Newsletter. We want the screenshots to be over the same area as your video is since your video will be referenced in the newsletter.

Simon, Just found out that the designer of the Falco, Stelio Frati (age 91) saw the video yesterday. He commented that he never thought the Falco would get this far (it was designed in 1955). Everybody in the real Falco family loves the video..it's been referenced off of Seqair's website also. Excellent work!

Congratulations on the Corvalis Jim! Great to see another fantastic product on x-aviation.

That dataref certainly accounts for the relative bearing...but not for the RMI needle directly which is technically tied to either the adf or VOR depending on the selector switch. So when you switch from adf to vor and the needle swings...the adf1 bearing is, of course, still the same value while the needle is animating. it's is that "needle" dataref that I'm after..but I'm beginning to think it's "internal" to the 2D RMI instrument in planemaker...something I've seen plenty in Austin's instruments...and to make a 3D RMI, I'll have to do some plugin code.

I've looked far and wide and can NOT find datarefs that represent the relative bearings on the RMI needles. Not a problem to solve in plug-in, but don't want to go that route if there's some standard variant...anybody catch these datarefs that I might be missing?

One source of turbulence that people forget is in the weather settings...and that is "thermal climb rate". it's usually set at 500 ft/min. You don't see that kind of climb rate except on hot days...so I almost ALWAYS turn this down to zero or some number below 50. It's a additional source of turbulence in addition to the regular turbulence setting.

yes you will get a free update!

Simon...I think you'll really like the next update handling wise. Morten and I put some time into the flight model to increase it's stability without sacrificing the nimble handling....I'm having a ball 'flying' it.

Yea...I'm tired of windoze too! (yea.... I use the DRM version myself :-P)

OOhh...dis is nice! Thanks for putting it here on x-pilot!

Actually Jason, the next update will be quite massive functionally speaking. The upcoming Falco (hopefully released in 12-20 hours from now) is a demonstrator of the tech that will go into the next MU-2 update. As far as Reality XP Garmin goes, the version I have for the MU-2 now is not interactive in 3D except to bring up the 2D popup. The next version will be fully functional in 3D and 2D and will include the 430 and the 530 variants. The Falco will come with the default 430 initially, but later in the week, I'll provide a reality XP version.

2.5 alpha 1 available...snap snap people

I was thinking about this as my Falco nears completion FYI..... I know Jonathan has disappeared from the x-plane stage for a while, but if any of you have bothered reading Jonathan's license for his Blender export scripts, you'd note that he asks for complimentary copies of the aircrafts you develop with Blender. I have tried for years to get Jonathan to take money, but he just refuses......and we can NOT do the work we do without his work and we all take it for granted. Jonathan was one of the very first people to get the MU-2 and whether or not he's around or would use your work, all of us developers owe him at least the gesture of good will of offering up our work. When your aircraft is ready to sell, before you put it on the market, I highly encourage you to send Jonathan a thank you via his org PM or email address and offer up your aircraft for free to him. Whether or not he takes it or responds is irrelevant, but only that you respect him enough to respect his request. If you do not do so, you're a leeching, selfish, self-absorbed trashy bastard! His email is: xplane () marginal * org * uk I suggest you try the email address as I don't think he frequents the org much anymore. You figure out where the dots go

Wombat Boy, that ATTR_shiny_ratio I think is 0.5. Nik, That low canopy is called the "nustrini", named after the first pilot to develop and implement it. I'm quite sure I will do a Nustrini canopy, but not necessarily for the initial release. Once the plane is up and running and the 'more difficult' problems are taken care of, I'll do the Nustrini. As a side note and a bit of background, I modeled this Falco as an stying exercise as I plan to begin building a Falco very soon. Usually, the biggest decisions a Falco builder makes is the choice of engine and canopy. The Nustrini, while definitely a much sleeker look, chops about 5-6 in. (14 cm) of headroom for the pilots. The cockpit goes from one of the roomiest cockpits in it's class to one where you almost have to lean in to not hit your head. I have ridden in the "tall canopy" model....in fact, this model is a replica of that Falco... http://www.dropbox.com/gallery/955680/1/Falco?h=77a056 I too, like the look of the low canopy, but from the "inside" of the aircraft, the tall canopy is a class to itself in roominess and feel. This particular Falco that I rode in was able to do 200 mph (322 kph) which is the goal I'll be shooting for as a builder. If I can get 200 mph with the tall canopy, that'd be my preference. So then, I modeled this x-plane version up as a way to play with the interior cockpit arrangment for the real thing...so that's why the tall cockpit is modeled first. As far as the 'Ferrari of the sky' goes, it certainly is as an Italian design, usually red paint, build quality and exclusivity, but not so much for speed anymore. Lancairs, Glasairs, and a bunch of other's ones are certainly quicker, but for all around balance, the Falco is still considered one of the most joyous aircraft to fly.

An in-sim shot of the exterior.

I decided to take about 7 days for myself to see how much of this Falco I can get done. I'm about 3.5 days into it and have the exterior almost done...just some more texture tweaks. next 3 days we'll see a new cabin and refined panel. I'll be pushing for a release within 4 weeks....settled at $15.00.

lol..so true Joe on x-plane development. Regarding pirating software as a student for educational purposes...I too, did the same thing. I have held true to not making money using pirated software though. Its a whole other rant though on "the spirit of the law" vs. "the letter of the law". Laws are conceived in spirit, but executed by letter for the most part. So we could say that piracy by you (who would purchase the software at first opportunity) is OK while in school..while piracy by some other peer (who would go on to use it illegally after school) isn't OK. We're exercising prejudice in such a situation which the law cannot cover as we're dealing with immeasurable but very real issues...human character. So while society must use the letter of the law in most instances....on a personal level, we tend to "feel" the spirit of the law. So what seemingly is a double standard might be with respect to legal text ...but not be with respect our general sense of morality. It's a fallable system though as not everybody has the same sense of morality or discernment and people can lie and indeed even not be sure of or aware of the source of their motivations....but hey, that is humanity isn't it? I love it! I'd hate to see a world only full of x-plane developer personalities :-P

You know I totally agree with the idea of knowing what you are getting into before purchasing a product...this is some information we need to better make available to potential customers. All arguments are valid here...I dislike DRM myself. This post goes beyond DRM though...The condition is a bit deeper than most surface arguments here. The issue is one of selfishness on the part of every participant in the "system". Vendors get selfish and don't want people stealing their stuff...nobody does. Users don't want any hassles and want access to the stuff they bought without restriction, everybody does....and get this, I know developers who loathe pirates and pirating..and they themselves use pirated software to develop their products....you gotta be shittin' me! I had a developer who wanted to pair up with me to do some work...he was using a rather expensive software package and recommended I use it too, so he sent me a link to a pirated version to download. I quit talking to him that day. I don't like the double standard. There are those who only care how things affect them..and those that have consideration for how things affect others....I fall in the latter camp. We're not dealing with DRM as much as we're dealing with character issues, that's why this debate carries a bit of passion, we're all calling into question character here and that is a very personal issue. Cameron touched on the idea of products that are so prevalent and companies so rich (so we believe) that you don't feel like you're hurting anybody when you steal from them. Do you know that Studio Max is upwards of 3500.00US and Photoshop is something like 600.00US. That's big money for some "hobby" developers...I'd bet half the payware developers for x-plane use pirated software..at least Photoshop. I myself use all open source for a reason...and I also own a license for Adobe's creative suite. I'd love to hear their justifcations about the software they're using...after they get past their "uh...uh..uh..." So then, how can one want DRM for their own work, yet use pirated software? I use the example to highlight the point of selfish intention as the basis for all arguments here. We all want what is most convenient to us; however, and this is the point I want to make, we don't live isolated in this world, we live in a community and in such a social dynamic, there's "give and take" whether you like it or not. Consideration for others point of view is mandatory to a smooth co-existence. Some accept that and deal with it, some don't like it...but one thing is for certain and that is you can't please everybody and somebody has to pay the price for ANY decision. Here's another example of selfishness and double-standard. So you won't buy the MU-2 because of the DRM as it implies mistrust and you take that personal...so then, do you refuse to fly commercial because screening makes you feel like a mistrusted terrorist? I highly doubt that. So you embrace your stance in one scenario and then conveniently put it aside for another...when it suits you...hey... we all do, I get it! So while I don't like DRM myself, we're balancing two issues here. Either vendors have people steal from them or other people have to have an inconvenience with the DRM or possibly loose their investment if the DRM can't be obtained. If my kids were to present me with such a conundrum, I'd vote in favor of limiting the theft as it's the right stance to take. Neither situation is perfect, but someone has to "take it for the team" Now I practice what I preach here...the MU-2 on my machine uses the DRM too, my non-open source software have licenses so I can soapbox here. I understand why DRM is necessary...I understand that a few people ruin it for everybody. I understand that as a citizen of the community I have to give up a little to make sure the community moves forward with development. It's the price of living in a unperfect world with unperfect people with little to no respect for others (which is why 12 year olds steal in the first place..cause many of them can't sense that wrong). By understanding the way things are, I then do not take something like DRM as a personal statement that I'm a thief or mistrusted. For those that see it and actually feel it that way, I think you're hurting yourselves by clinging to a view that, while altruistic, isn't reality. A quote I really like is "....disappointment is the difference between expectations and reality". If you expect to have all the rights that you believe your entitled to in an unperfect world such as this, then get ready for a cargo-load of disappointment. You can choose to live in a disappointed state, or relent your expectations a little and ease the burden on your soul. Now in the spirit of respecting the position of others, which is paramount to me...The one thing that drives my approach to DRM is simple.... put as much control in the customers hands as possible. They DO have the right to use the product that they've purchased in any way they see fit within the bounds of the license. If we can get both the product and the DRM in the control of the end-user, we'd be all over it...indeed it's what we want. Kesomir is right on the money, we should make a best effort to respect the customer given the state of software distribution.

I won't do anything to the GPS at the moment. You're right, it's quite a involved task to improve something like that...practically a project in and of itself. Best I can say is we'd all like something better. If the time is ever right, I'll probably look into it one day. I will say I am ALWAYS looking at and learning techniques that could prove useful in simulating things better.

Ok..another little update. I've gotten over a hump..something i've been avoiding for the better part of a year now. Recall that the Moo started life in the middle of the V8 run. Manipulators weren't quite available then, nor were the lighting technologies, nor even half the datarefs I created for the Moo, which are now standard. implementing the newst of x-plane tech needed a rebuild of the cockpit infrastructure. First order of business was taking the exising cockpit object and stripping it of all animations and manipulators. Because the gauge set was a combination of both the panel texture animations and 3D animations, obtaining lighting consistency was next to impossible...hence the MU-2 has horrible night lighting. As an example...see the cockpit image below. The pilot airspeed indicator uses the new lighting system..the copilot airspeed indicator still has the old style..that seems to glow all the time...no good!. It was necessary to get all the elements that are to be affected by lighting into the cockpit object. This necessitates the integration of all the various objects and textures into the cockpit object. Such integration required lots of UV remapping and texturing combining, which is ridiculously tedious and unpleasant to me; however, I've gotten over that hump. The image below shows the resultant cockpit texture taken from five different source textures. This will make handling of cockpit lighting 10x easier and more predicatable ala Nils BK117 helicopter. In addition, I can now apply the manipulator methods I have and rewrite the plugin from scratch. Rewriting from scratch is not as bad as it sounds because a lot of the datarefs are now default in x-plane and any logic algorithms can be copied from the old code to the new code. In addition, I free up several misc object slots. Combine that with 2048 textures here and there (only 1024 were allowed when I begun), then we have the foundation to start over-hauling the MU2 and bring it into modern day tech...hopefully one with a solid enough foundation to last for years to come. I admit...I pushed the MU-2 a bit ahead of x-plane tech and risked it when I did, but hopefully, only a year and a half will be lost. This new system will allow me to make changes very quickly and adapt new features. The cockpit picture in at the bottom , uses the new cockpit texture...you'll note a new attitude indicator has been put in place. The next version (2.0...totally skipping 1.2) will have the wipers working, the GTX330 transponder will be almost completely functional (if not completely)...the gauges will become all 3D. I will exaggerate a few things here and there to make them a bit easier to read onscreen, more complete lighting will be implemented AND the ADF will work. I'm debating whether or not to simulate the fuses / electrical system. I have a system in place, but haven't tested it yet. I suspect a smaller scale project would be a better candidate...in addition, I'm hoping to discuss with Austin some electrical system modifications to xplane for the future. So up next is to get all the instruments built in 3D (mostly adding needles / indicators), then implement the animations and manipulations. The plug-in development is simultaneous with the manipulations. Once the cockpit is "running", then I'll put out an update and then focus on the rest of the 3D, upping the quality and textures.

semi-bad news folks, I'm partially retracting my freeware offer.....I think I'm going to move a version of this Falco to the payware category...not this version as is, but it's progressing so fast and I keep sticking my best code and features in it that I'm reluctant to give it away at this high level....anticipating 14.00. So what I anticipate doing is pretty much cleaning up things as they're seen in the screenshot above and make that the free version..which is quite feature laden. Then the payware will go on to implement a fully working Garmin 330GTX, much more detailed 3D aircraft and interior....fully functioning radios and ADF with perfect manipulator knobs. What does that mean, perfect manipulators??...it means no weird hotspots...grab the knob, move it to change stuff. if you can get the tip of the cursor on the knob, you can grab that knob and move it. Sorry for the somewhat change of heart...but i will be providing a free version much further along than the current one.

Well the code is certainly proprietary..it represents a few years of experimentation and learning (moment of pause and thanks to Ben Sunpnik for his guidance............). I will; however, consider collaborations with other developers on a royalty basis. This would be of benefit to developers who need a programmer. Now I am NOT as strong a programmer as many others. My openGL and openAL (sound) skills are lacking and I intend to work on that later in the year; however, I can tell you that the system is designed to "pick up" after all the modeling and texturing has been completed..and before animations are begun. It does not HAVE to be this way, but when working with others who are doing the modeling, it represents the path of least resistance.

Tired of workin'..late night blog: You may recall the picture of the falco cockpit I have on the front page of x-scenery.com. Contrast it with the one seen here, and you'll note all sorts of goodies that will be "up and coming" in 2010. I have spent the better part of the year working on a foundation of techniques and systems to speed up the process of development. The MU-2 was such a exasperating experience to finish up, I knew I had to standardize methods and find ways to reuse the things I'd already done. I can't tell you how many times I've modeled the same entity for each new project. Well I'm quickly nearing a major milestone in my developer tools that I hope to finally capitalize on and finish up some projects. It's easy enough to keep moving on stuff you know and worry about the stuff you don't later...crossing those bridges when you get to them. I crossed too many of those bridges on the MU-2 to ever want to do that again. So the most prominent development has been a plug-in template with a deep tool-set (at least to me it is)for programming whatever I may need in short order. The MU-2 had over 100 manipulators...some tied to default datarefs and others tied to custom ones. Testing those required lots of exporting from blender...and every export from blender meant about an hour of hand editing the exported object file towards the end of the project. This new code template allows me to separate the manipulators from their functionality. I set up a complete cockpit with "empty" datarefs and animate the whole sha-bang. The plugin code has "holes" or "hooks" for the logic to be programmed later. I simply read in the position of all knobs, buttons, switches, whatever and then code in whatever I need to. This saves me the hassle of hand editing, exporting and testing repeatedly. It's much quicker to compile a new plugin and reload the aircraft than to reboot x-plane. So what does that have to do with this Falco anyhow? Well all those techniques are getting tested on this guinea pig...which will go out as freeware when done. What you see in this project is what will be in future products and also what the MU2 will evolve to. Firstly, the instruments don't have that funky bright and uniform look. This is from using ATTR_cockpit_region in the object file. Doing so makes the instruments receptive to the new lighting algorithms. You'll also note the 3D attitude indicator and HSI. This is the HSI from the MU2, but the Attitude indicator was developed for the MU2 and will get back in that cockpit eventually. There's an additional fuse panel with 8 fuses. Why put in more fuses? Well because I'm working on complete electrical simulation, including the fuses..and I'll need the practice dealing with so many circuits by the time I put this into the MU2 simulation as well as other future stuff. The 3D looks the same, but there's a lot more brawn behind the stuff now. Fuses can trip, the alternator can be overloaded and eventually (some unknown time in the future), you'll see failures where you'll have to diagnose the problem from symptoms. The Garmin GTX transponder is almost fully functional now..and will be fully functional by the times its released. How functional? "Go to garmin's website and download the manual " functional. The next thing to try and hash out are custom sounds. Thanks to Ben Supnik for providing a file loader. I just have to work through a few file file path issues, get acquainted with manipulating sounds, then hopefully we'll experience some cool stuff. So 2010 is looking to be a good year of growth for x-plane...at least in the back half of 2010 as more momentum gets built. I suppose one day I should get back to doing some scenery.

Of course the "qualifiers" keep going Jan...so the proper answer is: " generic text with ATTR_cockpit_region ...AND...the lighting mode of the generic text set to "mechanical", which is the default setting". Because almost every generic text in existence represents some type of LED output...it's 99.9% (if not 100%) of the time going to have it's lighting set to glass, in which case, folks would see no problem....but leave it to me to have it set to mechanical and bang my head against the wall. Either / or, Ben confirmed the bug and it'll be fixed for the next version...not that anybody except a bozo like me would ever deal with it. I'll presume your generic text instruments are set to lighting mode "glass". Set them to mechanical and see if you have the same problem.

YEE-HA! I just lost a stupid number of hours trying to solve a problem that turned out to be a bug in xplane and not any fault of my own after all....uh...other than that incorrect XPLM type....*cough...*cough..thanks Jan. Anyhow....the problem is that generic text is not working when used with ATTR_cockpit_region in the cockpit object. I switched back to ATTR_cockpit and everything just worked.