tkyler

x-pilot and x-aviation are just coming out of it's infancy for the most part and there are some "growth things" desired for the future, including advertising. Though it's probable that blatant repetitive spamming isn't too cool and wouldn't last long, you certainly are welcome to let people know about your stuff in a cursory post....heck, we may want it!

This is a common request but because the MU2 is not wired that way in reality, that feature will have to go in as an "alternate" after I'm satisfied I have the major functions taken care of first...but your request is "in the queue.

We've got you covered on all points except the GPS and weather radar. Other than those, if you have the Falco, you'll have an idea of what this will be like...the lights will work just as in reality...no electricity, no lights! Lights will be fully adjustable on every rheostat exactly as in the real thing...and of course the instruments are all MUCH more legible! X-Plane has a "weather radar" instrument, but I'm holding off a bit to see what Austin comes up with for version 10. With a whole new weather engine, I'm not sure what he'll do regarding weather radar...and there's no room to put one in at the moment :-P. Once I've taken care of all those "original" complaints like resolution and some missing functionality, I'll look to start adding in some of these other features you mention. Regarding the GPS, a GPS simulation is a pretty tall order and one that is LONG LONG overdue in x-plane. It would take a very dedicated effort just to simulate a basic GPS. At the very least, I'll look into tying the HSI in with the GPS though the particular model of HSI in most of these MU-2s don't couple with the GPS...but I'll certainly see what I can do.

I have been immersed! Still a ways to go on the lighting but the "feel" is starting to come around.....almost felt like I was in the real thing. Most of the major instruments have their lighting and I still need to gt to each of the switches and knobs and then the glass lenses for reflections, etc. Youtube video too.

Well adding in features is pretty easy. The system is designed to build upon what's already there as opposed to rebuilding. I can initialize any of the controls / fuel / payload to whatever positions I want based on certain criteria. For instance....a "cold and dark" night setup ala Falco will have enough light for you to get going. When we flew the cargo runs on the MU2..first thing we'd do is hit a button near the door that would light up the cabin and part of the cockpit enough for us to get the cockpit lights going....that and a flashlight! x-plane's at least puts 'even amounts" of fuel in the left and right sides, so users probably won't notice anything at all. Now in Version 2.0 of the Moo...I would like to have legacy or history to the cockpit using a config file such that where you leave the controls on shut down is where they'll be on next startup. This will make things a bit more interesting..and in addition, I'd like to add a pop-up fuel panel so you'll have to keep refueling your Moo. This isn't terribly hard, it's just requires more time as usual.

Fuel Transfer Nirvana! The fuel transfer system is working 100% perfectly. ..and I don't mean just keeping the main tank full! The left and right switches work independently from one another so it's possible to stop fuel transfer on one side of the aircraft and alter the balancing of the aircraft. You can even get it so that the left side is full of fuel and the right side empty..enough so that the imbalance will counter the roll torque on take-off. Of course the plane is designed to fly balanced though and the automatic system is also designed to keep the main tank full. So if the main tank if full, the amount of fuel transferred is limited to the fuel burn of the aircraft. The fuel amount never increases so this should be good with xeconomy. Now sometimes, when x-plane just loads up, it puts in "random levels" of fuel in the tanks. This means that the main tank will be less than full and you'll notice fuel start to transfer from the outside tanks immediately...it's very obvious on the fuel level indicators. The current MU2 does this, but this takes it to another level. The fuel transfer is now based on bleed air as in the real thing. No engine runnie, no fuel transfer from that side. The exception to this is the "outer tank" pumps. The outer tanks are not the tip tanks, but tanks in the outside portion of the wing. There's a pump that will transfer fuel from these tanks to the main tank and it is electrical. That means you can turn the tip tank transfer system off (required to get the outer tank transfer to work) and then turn on the outer tank pump to get fuel into the main tank before you start any engine..just like in the real think. Also, the rate of fuel transfer is based on whether one or both sides are transferring fuel. If you set one side to "off", then the transfer of fuel from the other side will be a bit slower....in other works, the flow rate from the transfer system for each side is modeled. Two pumps push more fuel into a tank than just one. Now Mitsubishi designed the system to be fully automatic so honestly, you don't need to mess with it much; however, the startup protocol will now require that you turn your main fuel switches on and your fuel transfer switches off until after engine start...and yes, if you flip the main fuel switches to off/closed, it'll shut that engine down since the valve it controls is about 2 feet from the engine..which sucks that fuel in about a 10th of a second. So from here, I have to program in the yoke behavior (smooth the motion and account for autopilot control), and do the lighting textures.....then there's quite a bit of plugin work to add in commands for hardware guys and to also initialize all the controls based on startup mode and time of day.

The ADF frequency band can accomodate four digits in reality but you do not see it much. x-plane can support four digit frequencies...it's just that the default instruments are programmed to only enter 3. A plugin would enable you to enter four...OR use the plugin "dataref editor" where you can enter the frequency in using the keyboard. http://wiki.x-plane.com/DataRefEditor The frequency is probably not in error as there are a few four digit NDBs out there.

Yes I can do that Simon....just lazy on my part ya know...drag to a folder etc. I'll start doing that from now on. things are moving nice and smooth...I've stayed late at the office and am getting the pressurization and autopilot consoles to work....which I think will just about wrap up all the control interaction. I still have to program some functionality to some of those controls...but we're awfully close.

I don't think it will be that long Dozer...but can't blame you for asking! OK, it's finally starting to look normal...have the yokes in and the autopilot console cover. It's been one heck of a transition! I'm finally starting to get "that feel" of being in the real thing during those cargo runs. Ok..Some big screenshots.

I mentioned earlier about having multiple options for manipulations, but I am reconsidering. What I'm currently adopting during this development is "click for 2 position" and "drag for everything else". So for example, the landing light, being a 3 position switch would be a drag situation. I have shortened the drag distance rather substantially since V1.1.1 such that it doesn't much feel like a drag. Dragging the mouse 30+ pixels onscreen can take longer "to the brain" as you try and "grab" the manip....than flipping a real switch. So shortening the distance for some drags means that you click and just "move" slightly and the switch flips. Fortunately, after the update, I can take some feedback and updates can be darn near immediate, it'll take longer to package and distribute the update than to make the change itself. I have finally reached nirvana and do not have to edit my files at all after export from Blender...so changes are as simple as adjustments to blender > export > done! This is a new level of maintainability and ability to improve product lines. The transition from V1.1.1 to V1.5 is a real testimony to how things can be improved OK...a video below showing some work on the cockpit lighting. There's lots of loose ends, so ignore funny stuff....everybody should know me well enough by now to know I won't do anything that isn't natural looking if I can help it. 12.4MB quicktime MOV. So first, what I'm doing in the video is demonstrating the overhead flood or map light. This light is for broad lighting of the cockpit. After that I follow with the overhead lighting rheostat and then the engine instrument rheostat lights...none of the other ones have been wired up. Total time on lighting has been less than 8 hours so things are moving pretty quick. http://dl.dropbox.com/u/955680/cockpit_lights.mov EDIT: It took me about 4 minutes to add a new dataref and manipulator in blender and get it tested in the sim. The following video shows some options that can be put in in addition to swaping the overhead switches from a drag to a click. By strategic placement of mouse click spots, you can either drag or do a "quick click" to set switches. See 7mb quicktime link below. Seems the longest task left is writing documentation telling everybody the new features and how to use them. http://dl.dropbox.com/u/955680/switch_options.mov

I still have to try some interface combinations, but my thoughts are to move the switches one at a time with the mouse by grabbing the "tips" of the switches and dragging (as in the video)....then also by moving them both at the same time by grabbing the space between the switches at the surface of the overhead panel and dragging...and finally by command that skips the "extended-off" position and toggles between the retracted and extended-on position. The impetus for dragging both switches at the same time is that is what I think is the best "natural feel" in that you reach up and flip both switches at the same time with two fingers in one swift motion....so for myself, I like reaching up, grabbing and dragging both switches on...it gives me that "flip the switch" feel...and timing wise, takes about the same amount of time that it did in reality.

More progress. Every knob and switch on the overhead is animated, manipulated and a few of them programmed thus far. Every control will function independently as will the anti-ice current meter. The video shows the wiper switch controlling wipers (after I remembered to turn on the battery). All the lighting rheostats work and will provide really nice lighting inside the cockpit. The overhead will bring the cockpit up to about 90% completion towards the update...and definitely downhill from here. I have to do some work on the copilot side and the pressurization system...then a few tweaks on the quadrant..some lights and call it good. 11.1MB quicktime movie http://dl.dropbox.com/u/955680/wipers.mov

I have not seen that particular one but it does not surprise me. The current version of WED is known to have several bugs...and with regards to import, it doesn't surprise me as WED has no idea what it might be getting. If you get that error consistently, and I'm guessing you do, then you're out of luck for the moment unless you can figure out what aspect of the scenery is causing that. Unfortunately, the message itself gives no clue. Through the course of V10 development, WED has improved greatly and will even moreso here shortly. As we develop V10 scenery using WED, we come across many things that need stability and improvement and since we use WED to build the scenery, it gets better. Expect an updated WED sometime after V10 ships and Ben can stabilize it...but it's secondary priority to V10. Because of the nature of a beta run...you probably won't see WED updates till sometime after x-plane 10 goes final....and I'm not speaking for Ben...only speculating.

Oh I definitely will Keith. The network didn't let down at all. It's quite new and I understand that fully and am glad to be able to give some feedback. I think you have a great platform and foundation to build upon and are doing so with each day. I need to keep trying it out because I'm still fettering out my MU-2 1.5 update features and need to ensure it's viability for online flying. I definitely understand how tough it can be managing both technical growth and marketing growth.

Ah? what is the supported format then? Can't say I've been a CSL guy in the past. Flight was fine, technology was great and smooth....the chat frequency is very nice. A few comments from a newbie perspective: I think I anticipated a bit more organization than I experienced...which was my folly. It's an informal "event" to be sure, but it didn't come across as an event in the sense that it lacked coordination other than a location and a block of time. After signing on, I listened to conversations and had many internal questions like, Is the canyon run a group run? Do we all take off together? Is there a flight lead? ...Will someone "call everybody over" and say, "let's go!"....or is it just a block of time to do what we want? etc. After listening a bit more, I gathered that it was just a block of time and we do what we want....so showing up by myself and not being part of any flight, I simply flew the canyon on my own and after leaving KGCN, didn't really see anybody. If I had shown up with some of my own friends, it would indeed have been more enjoyable. The VERY GOOD thing about this is that is pretty much mimics reality, which is what pilot edge is all about. Having confidence that you're in a scenario simulating reality is very important; however, being a event that relaxes "real world" rules.....with at least a partial purpose to attract newbies, I would suggest that newbies be engaged by the more experienced users and welcomed into the group...they really have no idea what to expect. The forum postings were informative as to "time and place and rules", but I would have welcome a bit of a "what to expect" for new guys walking in the door, either by someone letting me know what's going on over the chat frequency or by a bit more information in the event description. It's my opinion that welcoming new people during events like these would encourage more people participate on the servers in general....either that or let them know in advance that they're on their own once they sign in, which is fine as long as they know in advance. Overall, the technical experience was very easy and reliable, the programming is done very very well. I did some testing of my MU2 radio and transponder programming during regular hours and the ATC was professional and accommodating while testing. I don't know if you plan to implement audio filters to simulate the unique "sound" of radio comms, but that would be a welcome feature.

I'll be participating and have included a CSL folder of my aircraft for anyone interested. I'll be flying under N1XS. Download, unzip and place the xscenery folder in: Xplane > Resources > Plugins > VSPro Resources > CSL http://dl.dropbox.com/u/955680/xscenery.zip

If you can get used to GIMP, it has a pen tool and is more than sufficient for texturing. It's all I use for my texturing and about 600.00 cheaper than photoshop. Everybody has their own environment they feel comfortable in I know so it's not for everybody...but my point is that money doesn't have to keep you from getting results. GIMP is available for mac/windows/linux.

Ok here's a cool one for the online flying folks. Since I originally started the MU2 as my own online flying IFR machine..I've always lacked a true "staging" frequency. The old radios on the MU2 did not have fancy integrated circuits for storing frequencies but instead used a source select knob (TX1 / TX2) to swap between the com radios 1 & 2. So you'd transmit on com1 and stage the next frequency on com2. When you were ready to transfer to the next frequency, you just turned the source select knob to TX2 to use com2 and then staged the next frequency back on com1 etc. As of now, Pilotedge and VATSIM only use x-plane's com1 frequency for voice communications so you couldn't use the TX1/TX2 switch on the Mu2 before. Well now you can. This won't mean much to the "non-online" flying crowd, but when you need to transition from ground > tower > departure ATC etc, then this will be exactly like the real thing....well not exactly like a Marquise because that radio panel is different but exactly like all the previous models :-P. What's different about this is that you can't use a swap knob simply without causing the frequencies in the MU-2's com windows to swap. Of course the frequency readouts in the MU2 are mechanical rolling digits so swappie is not an option.....so you have to use a plugin to keep the com window displays consistent while always using com1 for online flying. Eventually, pilotedge will move to using com2 and this wont' be so fancy. If it doesn't look special at all and looks perfectly simple and normal...then I did my job :-) The video link below shows using com1 and com2 to tune into a local ATIS station. The text mode is turned on in xplane so whenever the ATIS is tuned in, a gray text box appears at the top of the screen...it's a bit tough to see. Anyhow, you''ll only see the gray box appear whenever one of the coms is tuned into 135.12 AND the source knob is selected to that radio. http://dl.dropbox.com/u/955680/swap.mov

I'm starting to chip away on the light texture which is a good thing because it's towards the end of this update feature list. There's a little ways to go but you can see that this is way better than the previous version and there's still subtle effects to be added. I'm a bit partial to a nice night texture because most of my MU2 flights were in the late night and dawn hours....it's a cool time to fly. I had some very good success implementing the custom commands for the hardware guys...and if I miss anything in the update, it should be a very quick and simple matter to add in more. I've ordered a USB joystick controller so I can build my own quadrant and also develop more functionality for the hardware guys...this is getting to be some fun.

New corporate RED livery on the org. http://forums.x-plane.org/index.php?automodule=downloads&showfile=12746 Per Dozer's recommendation, when using GIMP, turn png compression OFF during development, it'll speed things up a lot BUT do remember to apply compression for your final livery PNGs...and for those on windows and Mac, use 'xgrinder' by Ben Supnik to turn your PNG to DDS and according to Ben, that will use much less VRAM than png....haven't tried it myself, but I'm going to soon!

We're making progress and hopefully you're learning and that's what counts! So what was it that allowed you to see your texture finally? Using the "texture draw" mode? or using the "image > replace" menu command? Actually, that error message comes up after a successful export so you are exporting the file...it's just that the script is not writing any filepath before the texture name. Now that error message is fine and indeed common as long as the file path given in the object file points to the texture. It is very normal when you have a custom x-plane object, that the texture file be located in the same folder as that object. If the x-plane export script is unsure of or doesn't trust the filepath to the texture (for whatever reason I don't care to read the code to find out), then it will simply write the name of the texture file in the object file with no preceding path. If the texture is located in the same directory as the object, then this will work in x-plane. So even if you get that error message, as long as the object and texture are in the same folder, you will be fine. What the error message is saying is that it has no idea what path to write to the object file so it's just going to forget the path and write the name of the texture file only...and as I said, by having the texture and object in the same folder, this works. I cant' tell you more without seeing the file structure of the converted scenery. Now I can't say with any certainty, but if you use the UV menu "Image > open" instead of "image > replace", then you might not get that error message....it seems that each of those commands handles filepath info differently..but they'll both yield the same result onscreen.

Excellent...that's what I expected. For my users, I want them to be able to use the com selector to flip between com1 and com2, using each opposite com for staging the next frequency. This is how we did it in the real MU2 and I want users to get that same experience. It's no problem managing the coms behind the scenes in the plugin to always transmit on com1 for pilotedge.

hello Keith....really cool work you're doing here. I was wondering how the network handles voice in relation to x-plane's com frequencies. IIRC, xsquawkbox only used COM1 for voice transmissions. The reason this is relevant is that the MU-2 uses a transmitter switch to swap between COM1 and COM2 in reality, there is no 'swap' or STBY frequency in the MU-2's setup. So for VATSIM usage, I manage the com1/com2 frequencies 'behind the scenes' with the plugin so that you're always transmitting on COM1 for VATSIM. Is pilotedge similar?

don't worry about the ATTR_no_blend. Is your 3D view in "textured" mode? If not, you need to be..and if it is, then do the following: 1.) Import that object with PNG textures per above instructions 2.) split your windows in Blender so you have a 3D window and a UV editor window open 3.) Select any object in the 3D window and hit "TAB" to go into edit mode. 4.) In the UV editor window, go to the menu "Image > Replace" and in the ensuing file dialog, navigate your way to where the PNG file is and hit the "replace image" button. Note...to navigate "up" a folder level in blender, click on the two dots at the top of the file listing. What you're doing here is telling blender explicitly where the texture file is 5.) make sure you're 3D window is in in "texture draw" mode.

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.