tkyler

The problem is that the texture is of the format *.DDS. The blender importer cannot read *.DDS files. You need to convert the DDS file to PNG format. XPlane can read both formats and usually DDS yields less VRAM usage but is more of a headache for developers. What I would suggest is that you: 1.) Convert the DDS to PNG somehow. I use GIMP with a DDS plugin that I can't remember where I got it. 2.) Open up the *.OJB file with a text editor BEFORE importing into blender and at the top of the file, you'll see a line that says "TEXTURE" followed by a path to the image. Change the extension of the image from .dds to .png This tells the blender importer where to look for the png file and because it is now a png file, blender will import it. 3.) Import into Blender and hopefully you'll see the texture. 4.) move the mesh and export your new object. 5.) Make sure that the file path given in your exported object file (after the word "TEXTURE) is the correct path in your scenery package setup.

Dude123, Sorry if I insult your Blender skills, I certainly don't mean to. These instructions are for Blender 2.49 I'll just describe the way I would do it. First, in blender, make sure your 3D cursor is at the 0, 0, 0 location. Whenever blender imports x-plane objects, it does so wherever the 3D cursor is located. By putting the 3D cursor at the 0, 0, 0 location, you ensure that the object is imported into blender exactly in the way x-plane will load it instead of offset. The way to set the 3D cursor to 0, 0, 0 is to go to the menu in the 3D view and select "View > View Properties" and a view properties box will appear. In the X, Y & Z fields for the 3D cursor, type zeros in each field and the 3D cursor will move to the 0, 0, 0 position. You can then hit the 'c' button (Blender 2.49) and it will center the view at the origin of the grid. Now, once you have the 3D cursor at the zero position, THEN import the jetway into Blender. After the jetway is successfully imported, then use the 'A' key to select everything. Then hit the keys 'GZ' and move the jetways up to their proper level. The G keys says "move" and the Z key says "only move up in the Z direction". I then recommend you save your blender file with your newly imported jetway. As far as the texture goes, if you get a message that says "texture not found" during import, then you'll need to tell blender where the texture is. If you do NOT get a message that says "texture not found", then simply hit the 'D' key while the cursor is in the 3D view, and that will bring up a menu. From that menu, select, "Textured Solid" and the texture should appear. At this point, simply re-export the object using the export script and you should be good to go. If the texture isn't found by blender during import, then we'll address that in another post.

That came out real sweet Dozer! I updated the reflections in the paint kit...you can download it...perhaps the empennage file will be OK for you. http://dl.dropbox.com/u/955680/xsMU2_Paint_Kit.zip I basically "removed" the stripes and it has a bit more of a generic look now, not quite so obvious. You going to post that paint at the org or make it available?

ah gotcha....guess I didn't read the specs thoroughly. Sorry! :-[

That is correct...you can do the "3-position" with the mouse OR use the commands. My plugin is structured such that all the commands do is move the switches and the switches still control the logic. So it doesn't matter if the switches are moved by command, by the mouse or anything else. The separation between inputs and the logic is probably one of the wiser decisions I've made and allows me to really concentrate on systems simulation and interaction separately. I haven't downloaded your plugin yet (just looked at it). You do not have to check for aircraft type IF the plugin is inside the MU-2 folder. If it is, then your plugin will only load when the aircraft loads so the MU2 is guaranteed to be the active aircraft. The plugin systems was designed this way somewhere during the 8 series to make it easy for "aircraft specific" plugins to be distributed. You do multiple plugins for a single aircraft by creating separate folders in the MU2 plugin folder...call it "Dozer_plugin" and INSIDE that folder, you'd put your win.xpl. So you could have many different folders inside the plugin folder and each of those folders would contain the win/mac/lin xpls, thereby keeping them separate.

DOH! Ok, will get a new reflection layer out as soon as I can for the empennage ! Excellent work BTW! The paint is looking good!

Done...HOWEVER, it's through a custom command and not the default landing light. You'll just set your button to my landing light commands instead of x-plane's landing light commands and it'll extend/retract the lights and turn em on and off.

Will do. I'll set it so the command just bypasses the "extend" mode. Nobody ever uses that anyhow. In fact, I'll try and put that in here in the next hour since I'm doing some recreational coding on the Mu2 anyhow ;-)

ah...it does my heart good to see someone else do a paint...that's really good looking! So is it easy enough to figure out and use? Looks like you're using 2.5. I haven't converted over myself...can you update the texture without having the UV editor window open?

The paint kit WITH instructions has been uploaded at x-plane.org for those that want the instructions. Nothing else is new over the link I provided earlier except the instructions.

If I read your screenshots correct Zach, it looks as though you have 2 functions named "function main()" is that correct? The main function is gizmo is a "flight loop" function and runs every flight loop and you should generally only have one. There are other ways though but I won't get into that here. In Lua, when you define a function with a specific name (like main) and put in some code...and then do another function with the same name and put in some different code, then the "last function" written is the one that gets run while the code in the previous function (of the same name) does not get run....perhaps I'm misreading your separate images. You should name the second function anything you like....say, function bob(). THEN in the main function, you just call the function "bob" like so: function bob do some stuff end function main() bob() end then the code in "bob" will get run while main is running.....well actually, code doesn't really run at the same time....it runs sequentially ;-)..unless you have multi-processors and code written for those. You'll note that I wrote the function "bob" BEFORE it was used later in the program. That is good programming practice....isn't it Ben? at least in Lua? It's been a few weeks since I messed with Lua and I've honestly forgotten if that's required.

The org won't officially announce anything until it goes up for sale at the org. x-plane Carenado products are usually released on Carenado's site first to maximize "first rush" sales, unfortunately all the exposure is at the org. Once it goes for sale on the org, you should hear/read ALL abowt it ;-)

Started a new thread to give out the "unofficial" paint kit to x-pilot users...

Here's the download link to the paint kit for the MU2 Version 2.x and a video showing some advanced techniques for livery painting the Moo. DOWNLOAD: https://www.dropbox.com/s/adpm5dqlje0b91e/TOGA_MU2_Paint_Kit_v2.zip?dl=0 NOTE: The 3D *.fbx model included in the download link has been modified slightly from that shown in the demonstration video. . See this link for more info (it will make more sense after you watch the video)

It might be....never used it myself. I'm a big "old fashioned" in that regards I guess....certainly worthwhile to look into. Looking at some videos, I'd say it just might be something I'd like to try.

f

I finally reworked the paint kit to reduce the complexity and number of layers and make it many times more manageable. It was so bad, I didn't even want to do extra liveries. After a goodly amount of time cleaning up the paint kit files, I was able to eek out this 'bandit' paint in a few relaxing hours. It's available for download at the following link....instructions included. http://www.x-scenery.com/xscontent/downloads/mu2_bandit_paint.zip

The axis is handled by intercepting the joystick input. There are x-plane datarefs for this to make it somewhat easy. EDIT: I removed several posts regarding the MU2 paint kit to keep the thread relevant. They were not directly related to news of Mu2 updates.

OK...so Dozer nudged me into something I've been avoiding....and that is finally getting around to implementing custom commmands. Now just putting in commands is no big deal....but organizing the code so you can put in a few hundred of them quickly IS....and so I finally put in some code to allow quick additions of custom commands. So NOW you can map your keyboard commands to custom datarefs like the throttle levers and condition levers and just about anything you want to. I have yet to tackle rheostat hardware though...like the yoke or throttle levers BUT that is coming. The movie below shows working the throttles with the mouse like the days of old, then by using the F1/F2 keys to move both levers...except this time, F1/F2 is controlling my datarefs, which in turn control x-plane. So now you don't have to hit the pesky "period" key to go into reverse you just drag the levers back. This will probably be a bummer for those with joystick paddles that don't have stops as in the real McCoy...BUT there are some detents programmed in to give you a little bit of a range. Can't win em all I guess. 22 MB quicktime http://dl.dropbox.com/u/955680/commands.mov Also, more and more systems realism is getting put in. Now when you shut off the main fuel valves, the engines will run for just a micro bit longer till the fuel in the line is burned up. The Run / Crank / Stop switches are DEAD ON now. This means that the "STOP" position is properly "spring loaded" as in the the real MU2....this is so you don't accidentally turn off the engine and this Mu2 is that way now too. Also, you have to hold the switches in the stop position for a few seconds (just like in the real thing) to get the engines to shut off.....AND fuel purge is now simulated. That means when you DO hold the Run/Crank/Stop switches in the stop position, the engine will surge a bit to burn off residual fuel in the manifolds before it shuts down.

I work "full time" on x-plane yes. Currently I'm full time on laminar work...so my x-scenery dev work is indeed "part time". I'll work with laminar as long as they can stand me...and after V10 ships, hopefully I'll turn more attention to my x-scenery projects. The experience over the last 2 years has been unbelievable with regards to workflow and efficiency and should translate well to my own projects. If you check my laminar V10 work on the F4 vs. the MU2 texturing (screenshot link below), you'll see what kind of detail will be coming in future stuff...and the laminar stuff isn't as high rez as what I'll be using on the Mu2 2.0 update. There's definitely some MU2 realism coming down the pipe. http://www.x-plane.com/images/v10/aircraft/week4/f-4_comparison.jpg

A bit of good news to report I guess. I finally got the plugin project moved to my home machine. Why is that a good thing? Well imagine working on xplane stuff all day and ready to go home. Who wants to stay late and work at the office when you have dinner and family at home? Not me. I don't mind working on the plugin at home, it can be a bit relaxing...so it's nice to get it set up. With that in mind, I made some progress on the quadrant. I'm putting in code to cater to the hardware and keyboard users and that's being a bit challenging with the custom datarefs. But the props are up and working, throttles, condition levers, etc....dare I say I'm cresting the difficult stuff and hopefully moving downhill. I suspect I'll work on this a few times a week in the evenings and get this thing out.

Sorry...I use the term 'exe' generically and not in the literal *.exe sense. The installer is consistent across Mac and Windows.....I think it is a dmg on mac :-P I honestly don't know because x-aviation does the packaging. Cameron? ...and for those folks who might wonder why I wouldn't know, let me just say it's the fact that x-aviation handles it for me and I don' t have to deal with deployment issues is why I go with x-aviation in the first place :-) ...so I can worry about development!

Thanks for your input, but your view is very limited. If I have a DRM product and 60% of the market is legit and 40% is black market, yet I make a million bucks on the 60% and that is sufficient for me...what do I care if 40% if pirated? The goal set upon in the production of the product has been reached and/or exceeded. You're arguing a point from a minority of users, who's view, while understandable actually, represents a minority of pirates. What people fail to realize is that we are software users ourselves....and I have pirated software myself also and have a rather solid handle on why I pirate and to what ends I pirate and whether or not it violates the spirit of the software license. I have never used pirated software in the pursuit of income or pleasure. Having dealt with DRM ourselves, we are keenly aware of the "annoyances" associated with DRM and work to alleviate those annoyances. We think we have succeeded to a pretty good degree...enough so that I even have DRM versions of my own products on my own machine. I actually have to get licenses from x-aviation to run my own stuff!...and you know what? It ain't that bad. I have nothing to offer those who find it offensive or troublesome. My personal opinion is that we deal with rights management all the time....whether digital or otherwise and if people get put off by having to enter a user name and password or send an email to troubleshoot a problem once a year, then screw em' They're just lazy and inconsiderate and I don't care to have them as a customer. I am doing well enough to gladly not have to deal with the whiners. I am committed to my customers and have contingencies should I or x-aviation disappear to make sure my customers have access to the product they paid for for all time. I can offer no more. If someone doesn't like it, they don't have to buy it....or they can try and pirate it and crack it! ;-) Good luck on the MU-2...the DRM was programmed by one hell of a programmer! By the time a product gets so in-demand that someone moves to crack it...chances are I'll be more than happy with my income and probably won't care and be on to other things.

A "cockpit object" is a 3D polygonal mesh created in a 3D program like any other 3D shape, but it has a few special conditions on it. Unlike regular objects that make up the parts of xplane aircraft like the wings, gear or fuselage (the ones found in the 'objects' folder), the cockpit object is a special object and x-plane recognizes an object as a 'cockpit object' when it is named properly and located in the proper location as Zach mentioned. You can have only one cockpit object per aircraft* (Two actually if you use the INN / OUT method...a topic for another time). What makes the cockpit object special is that the cockpit object can possess special commands in it (remember it's a text file) that allow x-plane to interact with the cockpit in 3D. The way you get these commands to work is through using special tools in the 3D programs Blender or AC3D, which has plugins that allow you to do this. So if you had an object you wanted to make a cockpit object, generally you'd get this object into Blender or AC3D, do what you need to do to it and then export it and put it in the right place in the aircraft folder. The "do what you need to do" part is the vast part that requires a good amount of reading, practice and pretty much lots of question asking.

WHOA! Will definitely fix that in the next update! Thanks for pointing that out.