tkyler

You mean. very very very very close? Seriously. writing (and rewriting) the docs is exactly what I'm doing. I'm going through the POH making sure as much of the information is current as I can....and also rewriting the autopilot section to include more info and some examples of operations. Tedious work this document writing stuff. Spent half the day doing it yesterday (other half with greasy fingers tryingn to fix a motorcycle)..and will probably work on them all day today. Too close to stop now.

As I chip away on the MU2. I realize that in a way, I'm trying to create my perfect sim experience. When I got into simming...It was VATSIM that caught my interest. At the time..there really wasn't any good 3D cockpits for xplane and I really wanted the immersion of being in a cockpit while flying on VATSIM. I was most interested in short IFR hops of 2 hours or less yet wanted to fly decent distances. Not being interested in airliner complexity or long jaunts.... I needed some speed, yet simplicity....and hence the MU2 project was born. As I test fly it now, getting ready for the update...I realize Im' really enjoying it and thinking, "hey...this would be fun on VATSIM"...yet of course x-plane still needs scenery. Notice that I mess with scenery too? I wonder if I'll ever get to the point where I can do an aiport to airport flight in IFR conditions with a great 3D cockpit...flying over scenery worth looking at (when popping out the clouds of course) and dealing with good ATC along the way. That's what I'm after. I'm wondering what other simmers are after or what experience they'd really consider a cool sim experience. -Tom Kyler

Looks like I did miss that one. I just submitted it off to laminar and it should make it into the next release. Sorry! Tom

well I like to stay mum nowadays on projects that I'm involved in as I never know where they're going to go..but one of the committments is laminar and another the MU2. The other 2 committments are xplane related yes and will hopefully see light of day by end of summer. They both will be top of the line / state of the art works. I am definitely putting my laminar experience to use. Where I go from there depends a lot on the outcome of those two projects. A lot of developers get a plane or two out as a hobby whereas we are trying to build a business and production machine and given the quality bar we shoot for, that requires lots of experience and infrastructure, which is a lot of what we're doing now. In the end, we hope to produce more top quality works faster. TBH, the MU2 is becoming a bit of an anchor, but one I'm fond of and won't stop improving until it's darn near perfect....but it's not a prime income generator and thus has to be "gotten to" as I can get to it. We have some great ideas here beyond scenery aircraft and TBH, I can't move fast enough. I think x-plane's best days are still yet to come.

There have been changes to the facade format in order to optimize the rendering and that message is definitely indicative of the most recent changes. I have only just recently re-exported (yesterday) out all the facades to comply with the new enhancements so hopefully you won't see the issue with the latest release (think it comes out today). If you do, then I probably missed one and in that case, definitely let me know here. Thanks! -Tom Kyler V10 Scenery V10 Aircraft

well let me tell you what's up. You see..I'm involved in about 4 committments at the moment. So when I work on the MU2 and don't reach a goal.....I usually have to wait a couple of days or more before I can get back to it since each committment has imminent needs. So a I generally rotate on the work....and let me tell you, some work pays a lot better than the MU2 sales and well....gotta feed the family still! Well tomorrow is MU2 day and with the MU2 pretty much ready to go (minus some niggling annoyances) tomorrow is pretty much "write docs day". ...and if all goes well, I'll ship it all off to XA for packaging and prepping of screenshots and newspages, etc, which will take a couple of days probably. What can I say...it's getting closer

Version 10 OBJs support a parameter called "GLOBAL specular" which exists at the top of the object file. You'll see this in the V10 King Air stuff. This basically replaces the "ATTR_shiny_rat" method, which is so cumbersome. The assumption here though...is that when you use GLOBAL_specular...you will also be providing either a normal map or a grayscale specular map and controlling specularity with the alpha channel of the normal (or the grayscale only map). I am sure you would agree it's a better way. I usually begin by making the whole plane matte and then "virtually polish" it, which to me, seems to be more in line with the real world where you have to work to make things shiny I'm excited about version 2.0...whenever that may be. I've learned a whole lot in the last 5 years and I think 2.0 will be light years ahead of 1.5 in overall visual quality and resolution.

Some do some don't. The Moos I flew in actually had a bulkhead while others just had a cargo net. A cargo interior is planned for the future also.

Thanks so much Leen! I didn't know you distributed it. No changes to the mapping in the 1.5 update. Version 2.0 will be next and probably some time in coming in that it will have new UV mapping, higher resolution texture, new engine model, new 3D cabin etc.

A little rough... will clean up and distribute with the 1.5 update. No normal map unfortunately. Will address that one day I hope

The problem starts with the fact that I use Austin's FADEC to limit engine RPM. This setup goes way back to well before I even had the option to override I believe so it just kind of stuck. If I were to override the throttles and use "throttle_ratio" and "throttle_ratio_use", then I would not be having this problem BUT I would also have to write my own "fuel controller" and also my own prop governor. This isn't insurmountable but it is time consuming...and since I didn't really get to this issue till I was almost ready for release, I just decided to do a workaround. As you know, x-plane will not let you assign custom datarefs to a joystick with it's hardware interface. You can only use the ones in the pull down menu. The standard throttle datarefs have all sorts of intrinsic behavior with the mixture_ratio and prop mode...which clashes heavily with the MU-2s rather specialized behavior. So the only way to take standard joystick input (the throttle_ratio) dataref and do something custom with it is to override the throttles and use "throttle_ratio_use" to actually send fuel to the engine. This de-couples the joystick lever from what goes into x-plane...which is my desire, but as I said, when you do that, you lose Austin's FADEC. So if you completely roll your own engine model...you probably won't see what I am seeing. My next step will be to do exactly this. I'll override throttles and by doing so can read the standard joystick lever position and write my own custom behavior. I suspect I'll probably have to do a bit more than this because there are 2 different ways you can interact with xplane's throttle as it applies to the MU2. The conventional way of course is to use a command to toggle between reverse and forward...but once I have built my MU2 hardware with real detents, then the behavior of the lever will be different. I hope to be able to have a configuration whereby users can do either eventually. There is a setting in planemaker for the "roll trim rate". It's relatively subjective...but obviously higher times gives finer control. It's easy enough to set yourself in PM. V10 seems to have different rates than V9..but I haven't looked into this thoroughly. -Tom

I will give all you guys a heads up here on the throttle issue for joystick users. I have always had, in the back of my mind, a desire to be able to tie my work into hardware. This usually means going above and beyond what x-plane provides for datarefs for some controls because well....x-plane just doesn't simulate garrett engines and/or beta range properly. I don't really fault Austin for this because the fact of the matter is that a simulator and gaming hardware just isn't the real thing and there are practical limitations when "approximating" a cockpit. The end result is compromise of some sort. Either something isn't exactly right or something isn't convenient....so which is it gonna be? Well of course that will be different for each of us...and might even change on a different day as it did for me.....but none the less, some path has to be chosen. So regarding the throttle, here's what is going down for joystick users. The first thing you'll need to do is go to the joystick setup screen and set your throttle to "none". THEN, you will reload the MU2 (or load it if another plane was loaded) and simply cycle your throttle full up, then full down. What will happen is the 3D throttle will begin to animate with the joystick as expected. After that, you'll need to set some button, either keyboard or joystick to a custom "toggle_reverse" command. This will then allow your joystick throttle to work as you are used to BUT this time, using my own custom datarefs. I simply have to use custom for now. I believe I can revert this later, when I rewrite the engine model, but the task is too time consuming to deal with now. If nothing else, this is a good foray into customization and perhaps I'll learn something useful for the future. I am building a quadrant also to use with the MU2 and all of this is a bit new. I will say that once you get used to it, it's not too bad. Set throttle to none, load MU2, cycle throttle, fly. I have provided a "reverse indicator light" on the panel in your line of sight also so you'll know if you're in reverse or not. Being that the throttle quadrant is below the camera view usually...you'll want to be nice and sure you're in reverse when you land. I hope that in the future, I can provide configuration customization so folks can have it both ways....convenience OR accuracy. Without custom made hardware, you really can't have both. This joystick throttle will probably be the biggest change and I do apologize beforehand that users have to set the throttle "back and forth" when switching aircraft (forgetting to set it to none results in some bad behavior). My thoughts on this are that x-plane has not really been the paragon of custom hardware "hosting" and is only just now beginning to explore that area as more competent users come in with hardware programming experience; however, I have always wanted to have my stuff have maximum flexibility and I am certainly not going to NOT pursue features simply because it is inconvenient at times. A great line from a movie I heard recently is: "....First one through the wall gets bloodied up". I'm sorry I'm so messy..I'll try and get cleaned up as fast as I can. Tom

Very good now. I was waiting to test a very specific situation with a tester and we just did this 2 days ago. It was a success and though there was a few naggling things, it wasn't enough to put off the release and I immediately set about continuing on with the "what's new" manual. Soon as I finish that, it's out. I don't know how long it will take because i write, reread / proofread / add more...etc. But no more MU2 work before release, only the docs...so it shouldn't be much longer (I know I keep saying that).

I whole-heartedly agree Rhydian. X-Plane 10 is just getting started and with some of the projects on the table, other simmers will see soon. I can't blame them for waiting...they want proof and that's OK, it's coming.

Doing XA proud. Good job Goran /Theo!

Many have always said that X-Plane 'breaks' the flight model between versions and I have always heavily disputed that....at least to a degree. I have always conceded that every new release brings minor caveats that developers have to deal with and this is part of the improvement process....well XP10 is no different. The MU2 works well enough for release...for Version 9...but the hardware/joystick stuff I've worked on so much for Version 9 doensn't work the same for version 10. So then...as I have been preparing the MU2 for release..and would have liked to have put it out already...the engineer in me REALLY wants to solve this Version 10 issue and with any luck, release a version that works in both XPlane 9 and 10...and that's the source of these few extra days I'm taking. I'm like a kid who doensn't want to leave the arcade...."just one more game"....and I am really on the fence as to whether or not to just stop and put out the Moo, which will only really work well for V9...or keep taking a little bit more time and try to get it working on V10 first. So my answer is that I think I'm going to take a few more days and really try and get this going in V10...and if I can't get it by the weekend, say the heck with it and finish preparing the package it for those who are happy to use it in V9 and then promptly get on a V10 version. That's the current update.

I've known that I needed to up the Mu2 resolution for a good 2.5 years...and TBH, my skills weren't really as sharp then as they are now. After doing 4 aircraft for laminar...each getting better than the last, I am technically ready to go back and "do it right", but at the same time, the Moo is a challenging shape and I just think, 'Ugh'....but know it needs to be done. Though it will never be as popular as a heavy, I certainly want it to be as visually rich and systems accurate as any product ever was. The Moo was the first fully interactive 3D plane for x-plane and I really want to get it back to the forefront....and in time I will. I am working hard at being able to support myself fully with my own xplane work and towards that end, I am involved in some other work that will hopefully pay the bills a bit better than a 3 year old MU2 model...and sometime after that happens, I will turn my attention back to this guy and "spare no expense". I can assure you Leen...the next version will be much more painter friendly in both UV layout and resolution! I'd seriously look forward to what you would do with it. -Tom

Blender 2.49 is certainly satisfactory, I still use it and all the "official" laminar scripts are written for it. Your success in exporting named lights rests in choosing the right light type and naming it in the correct place in blender. See screenshot. Create a lamp, make sure it's type lamp in the shading panel...then in the edit panel, make sure you name it the name of you named light. The default name there will be 'Lamp' when you create it. When you export out from Blender, the script will look for 1.) Type=Lamp (no spotlight, no sun, etc) and then the name. The exported OBJ with one lamp in it looks as shown below. A 800 OBJ TEXTURE POINT_COUNTS 0 0 0 0 LIGHT_NAMED NAME_HERE -3.2854 -5.4923 0.9187 This will get you started with named lights. The newer scripts that I use (not yet available) will allow you to add properties to the light to customize it, but NOT in the way that you think. You will not adjust Blender light properties to adjust the light but rather you will add a property field to a lamp and then type all the light parameters in this text field. I'll probably cover this when the time is right. In the meantime, you can study some of the light parameters of the lights I have included in the x-plane 10 library and cross-reference that with the lights.txt file. You can roll your own named lights if your careful with the lights.txt file. One typo can bring x-plane down. -Tom Kyler

Because its a lot of work ...and I can not stop what I am doing to work on it at the moment. More resolution, new textures and new lighting effects. It's @150 px/meter...there's lots of room for improvement of that number and higher resolution means painting new rivets, new lines, new grunge, new spec map, more textures, more layers, more time, etc etc etc...so much to do. No worries, but I've been busy bringing all that to xplane 10 for the last 2 years Leen! (As much as Lamianr would let me anyhow) I develop flight models / 3D models / UV Layouts/ Textures / 3D object library / Custom Scenery / Plugin programming and well.....I'm just a busy guy. -Tom

I'm on board too Leen, it does look great! The next version of the MU2 will finally come up to speed with normal and specular maps, but till then, you've really done a great job! -Tom

since day 1, I have designed the system to be able to eventually interface with custom hardware....it still has some development yet to go, but in general, I'll simply give you a list of custom datarefs to point your hardware to. Of course it'll be tested already....my teensies are on their way from Paul's site. Paul is really doing something special for xplane.

Ok ladies and gentlemen...we're over the technical issues for this release. This whole "last second delay" thing started when the throttles levers would not animate with the joystick. This is because I use a custom dataref for the throttles. I do so because Austin's default throttle ratio is not very suitable to the MU2 with prop locks. Version 1.1.1 of the MU2 did not simulate prop locks, but 1.5 does.....with caveats. You can override that throttle variable but when you do so, you basically bypass x-plane's FADEC and end up having to write your own..and for the MU2, that means also writing your own prop governor. Once you go down that road, you're committing to basically writing your own engine management systems and while I would like to do it, now isn't the time. So then, first I got the joystick animating...but it was between 0 - 1, meaning that as you pulled your joystick throttle back, you'd go into reverse...and without detents on joysticks, accidentally going into reverse and crashing after your long MU2 flight in xplane is NO fun. It was determined that the "traditional" way of pulling the joystick paddle all the way back, then hitting the period key to go into beta/reverse mode was a more palatable solution for simming and I then had to set about reading differing types of joystick input (windows/mac) while still outputing the same results to the MU2 throttle. This necessetated a custom "reverse toggle" command as Austin's was not suitable either because when you hit the toggle, you change xplane's prop status. In the MU2, the lever position changes the prop status, so I didn't want folks hitting the reverse key and changing the engine model if the throttle levers were in the wrong spot...SO then, I have a command called "reverse toggle" that you can map to the period key. The effect is the same, it's just a custom command and not one of laminars. I am going to make a concession by putting a indicator light on the panel that will light up when you are in reverse mode. In this way, when you can't look down to see the quadrant, at least you'll know what's going to happen when you move your throttle paddle. So with all that done, it's going out for testing and while that is happenging, I'm gathering up liveries, paint kits, writing the what's new booklet and setting up the new installer. I am over the hump and now it's just time to make sure the update gets a nice rollout. I"ve focused on the cockpit and systems so long, I'll problem forget something else that will need to be cleaned up with small updates. -Tom Kyler

windows issues have been resolved and as far as I'm concerned were the last. I'd say I finally made it into the endzone (to coin an American football term)...I only have to kick the field goal. Working on the trivial todos like looking over the paint kit, making the "what's new" pretty and touching up some last minute textures. This thing is about done. Will need a few days to prep it for mass distribution. This is something we would have done already if not chasing the last unforseen programming bugs. Prep for distribution means making sure all the package is in order, the installer is assembled, all promo graphics have been generated, web site updated, etc. That's what we're doing folks, this one is on it's way out the door!!!

If you ever thought about building a cockpit or hardware and looking for specific types of switches or knobs, try this place. When I can find a momentary-off-momentary rotary switch like the MU2 roll trim uses for 6.00, then I've found the right place. Bookmark it! http://www.mouser.com

No way to know Larry. FPS are really system dependent, but I don't think this version hits any harder than the current one. There's nothing significantly added processing wise, only refinement in the code, objects and textures. TK still toiling. I'm a bit rusty compiling on windows and we have something keeping the windows plugin from working. Soon as I chase it down and we get the windows version working, we'll package it up and get it out. Mac version is working to my satisfaction for this release.