tkyler

You'll have to fix that if you want to do this regularly. The first thing on OSX is to make sure you have the GDAL command line tools available. You can do this at a mac terminal by typing any of the following: $ which gdalinfo $ which gdal_translate $ which gdalwarp ....and hopfully you'll get back something that looks like this: /opt/local/bin/gdalinfo /opt/local/bin/gdal_translate /opt/local/bin/gdalwarp If you get nothing back but only see another command prompt appear, then you don't have the gdal command line tools installed and you should go here: http://www.kyngchaos.com/software/frameworks and download / install the "GDAL 1.10 Complete" package. (maybe 1.9... depends on several factors but start with 1.10) THEN after you do that, try the "which gdalinfo" command again and see if you get a path back as shown above. If you do, then you're 70% of the way to where you need to be. Advise you avoid anything that says 'python' or ends in .py Once you have the GDAL command line tools installed, you should not have to 'cd' to their directory to use them as their path will be put in your environement variables by the installer (I don't expect any of this to make sense to you but need to negate Chris's advice to 'cd' above as it probably isn't relevant in your case, being on a mac and using the above installer; however the concept of "cd'ing" around a computer's directory structure from a command line is as fundamental to using the command line as walking is to humans so best to understand it before attempting anything else. You use one of these programs by typing in the name of the program, the parameters you want it to do (usually called "switches") then the name of the input file (along with its path....UNLESS you have cd'd to the directory containg the file) and a name of the output file (which you pick). for example to change formats, you would type something like so: > gdal_translate -of GTiff path/to/the/file/somefile.jp2 path/you/want/to/save/to/the_converted_file.tif the switch, "-of" stands for "output format" and what you are doing is calling gdal_translate...telling it to convert a file and output in the Geotiff format, taking "somefile.jp2" as the input file and spitting out "the_converted_file.tif" as the output file. I cannot stress just how simplified this is and I can think of a dozen things that would cause this not to work right off the bat and the potential pitfalls that can crop up in this type of scenario including whether or not gdal_translate actually supports the jp2 format (which I don't know). It is not my intention to teach you how to use the gdal tools or even see you to success on this one task but only provide further information because the puzzle is large and each piece helps. Command line work on geo files can be glorious or laborious. I've auto-merged, resized and automagically cut up and auto-named 192 super high rez orthophotos in x-plane with nary but 4 gdal command lines (the planets were in alignement that day)....but also spent hours trying to convert a single image because it was lacking some info in its header. Geo files are like a box of chocolates......you know the rest. And finally....when you try to use a command line tool and it just "spits you out" or gives you the "help/usage instructions" instead, then 9 times out of 10 (if not 10 out of 10), you have not supplied the right arguments in the right order the program was expecting. Most every GIS command line tool expects arguments to be typed in a certain format and a certain order (but not always) and NO typos allowed. If it expects a number, you can't be providing it a letter, etc. For really long command line entries, its super common to mess it up a few times and leave out parameters. Suffice to say though, if you can get the GDAL command line tools available to you on your mac, then you'll have quite the toolset for doing just about anything and your next step will be to read all you can on GIS processing. I recommend the following book if you plan to go deeper into geo-processing for x-plane. This book has numerous examples for working with all sorts of open-source software, including the GDAL tools (or enough of them for you to research the net on your own thereafter) http://www.barnesandnoble.com/listing/2688978942539?r=1&cm_mmca2=pla&cm_mmc=GooglePLA-_-TextBook_NotInStock_26To75-_-Q000000633-_-2688978942539 You will find though that the problem is usually finding the right data in the right format...that can be a needle in a haystack hunt. Just wait till you download that killer 1.0GB orthophoto only to find that it's in a .sid format ...and the gdal tools are useless.....and its off to the mrsiddecode tools.....only to find that the converted sid doesn't have the right projection information and you have no clue what projection it is....oh there will be frustations. TomK

wouldn't it? and some other stuff too

How about rough 'inprogress' cabin shots. Don't bother pointing out any inaccuracies, this is all development stuff

we would not rule it out, indeed we have passed it to one individual on a bit of a trial basis. We still have some exterior areas to touch up before we do that though so if we do this, it would probably not be until after Aug 1 at the earliest. TomK

We haven't said much in a while so here is a verbal update. We are moving along nicely and we don't like showing in progress work before certain milestones are reached. We are working on the interior cabin, cockpit shell and galleys and such, most of it is modeled and we are doing texturing and modeling of details in these areas. This is nearly the last 3D to be done so we have been somewhat keeping our noses to the grindstone as it were and haven't looked up much to post anything. I would like to think in 6-8 weeks or so, we might get another video up with a lot of the new work in, but there are some other factors that will weigh into this that take higher precedence. We are staying aggressive trying to reach a late year release if we can. TomK

I can get on fine with my mac..... no problems whatsoever other than a bit of nausea. TomK

64 bit simply allows greater memory...which means you can load up more stuff and not have x-plane crash or give you an error message. Think of it as a bigger bucket to put more detail in. It is generally only relevant when you load up lots of stuff. For example, if you set your visibility to max, then x-plane loads "more scenery" way off in the distance so you can see it. If you crank up your autgen density, you load up "more stuff"...more buildings, etc. The performance is not all that different from 32-bit. As more and more stuff is crammed into x-plane, then 64-bit allows for this kind of growth. Without it (32-bit), x-plane would either crash or give you a error message if it did not have enough memory. FPS doesn't change much between the two and is more related to folks hardware than the fact that 64-bit is 64-bit. It is a bit different for each. TomK

No offense taken. just a quirk hiccup that doesn't happen often and one we'll all soon forget about TomK

go on Steven DO IT!

UPDATE....Cameron is reworking the core product page of the Moo and is at about 95% but hit a few programming challenges that are taking some hours to work through, though the effort is warranted. We've been doing 15 hour days to it seems like one big long day to us for the last 3 days...but this is our current task and when its done, the Moo will go out. TK

The Falco has officially been adapted to the new Gizmo workflow pipeline and is 90% converted to Gizmo (in only 7 hours of work). This does NOT mean it will come out in the next week. I am using the Falco for testing 2 new frameworks for electrical and sound systems. It is fair to say though that the 64-bit Gizmo version of the Falco will probably be out sometime in the summer if not sooner TomK

Hey guys. So we did not quite make it out on the weekend....but we have been on it the entire weekend and still are now....and as it typically the case, the work has resulted in some tangential work being performed that a release usually brings to light as having been needed. It should be out in a day or so at worst, we are actually working on the web store page to show the new features and such for new customers, but the Moo work is done as is the what's new docs and the manual has been revamped. So not too much longer. TomK

Software is an odd beast that folks don't generally do not view as having a "shelf life" like they do say cars or an appliance, but from my perspective they really do. X-Plane is in an adolescent awkward phase relative to the entire market and this stuff happens. My final assessment is I'd much rather have it this way than any other way thought. Thanks for the sentiments Steven, we'll keep working on good products. TK

the gtx330 now has brightness functionality so you can tweak it to your preference.

I see your point; however, the software world is a bit more fluid than that and I've been rolling with it for 35 years. But I tell you what...I will honor your feelings this weekend! the "update" (so called) will be free for all other existing customers, but you can pay 24.95 for it (it will be on sale ) and call it a "verion 2.0" and opt not to buy it if you think I'm such a dishonorable vendor..but since it's vaporware anyhow, its not like it was going to be real for you anyway. I know by putting in a little bit more I made V10 necessary, but my comprehensive market research shows that generally more is better and so I just did it. Some people get it, some don't. http://www.youtube.com/watch?v=OnA3C9Af_oc TK

Well that will have to wait till version 2.0. Development is not linear anymore though. I mean, x years to get to this point does not mean y years to the next. There has been a whole lot of infrastructure development in authoring tools of which the MU2 was a guinea pig. I could not be more excited about the future of development with what I'm seeing now. TomK

OK...tests with XA regarding distribution and DRM done successfully. I have to say, this system is fantastic without being obtrusive. Kudos to Cam and BenR for providing a professional installation and management experience.....I mean, just keep your XA user and pass handy and you should have no issues; HOWEVER, that being said, I think this is the first 64-bit gizmo product to be distributed and though we have endeavored to cover as much as possible based on past experiences, this will be a new "trial" on a mass scale. This MU2 1.5 update will be for V10 only and 64-bit only. The "x-plane consortium", consisting of laminar and lots of devs all agree that 64-bit is the focus and future and we need to leave 32-bit behind...that's just the way of computer technology. My computer is old and ratty and 64 bit works great for me. So....this SHOULD be out during the weekend (assuming no "non-flight sim" related life surprises or emergency reshuffling of priorities). This is not a promise but rather an 'educated estimate' based on my years of troubleshooting and knowing when and what causes delays and issues, at least when close enough to see the finish line (far away estimates are always cloudy). I have tested the MU2 rather thorougly and its performing very reliably on my machine, but my machine isn't your machine so we'll see how it goes. So what is happening now is I am going over the what's new docs, preparing a impromptu video showing the new features and basically cleaning up the package, dumping old legacy files. I am NOT working on the code or flight modeling...that is all done to my satisfaction and now the DRM and activation tests are complete also. This MU2 is head and shoulders above the "old experience" and sadly, the last free major update of the version 1 run. (minor bug fixes will still be performed if needed) Tom K

You HDR guys should like this. ....and to think this Moo isn't half of what it could be. One day after the 737, this guy will get the super-treatment. TomK

Not much to show that hasn't been shown in the past. Here's the garmin in the "Count down timer" mode and in the middle of code entry, but with the count down timer expired....and when that happens, the timer shows "EXPIRED" and the timer begins counting up. Great for non-precision approaches and really challenging navigation "old school". The radios show some zeros for frequencies, but that happens a lot during development and I keep programming errors and those variables go to zero....won't happen in normal ops. ( I hope!) TK

Garmin transponder port to Lua 95% done...putting the final touches on it now. I'll coordinate with XA this upcoming week on packaging and stuffs. We still have to do some tests but by this evening, I am very confident that the technical work on the MU2 will be done and only the distribution and registration stuffs remain. TomK

Eventually I will convert the Falco yes. TK

Totally understandable, I was just expounding for others, I never took it offensive at all This GTX330 simulation is really all that stands in the way and it's just a matter of time. My beta tester found a few issues but darn near negligible....and if he can't find many, then I am really happy. I've been the Moo in all sorts of situations and (so far) it just works without any fanfare....which means you just enjoy the darn thing. I'm kind of excited to finish the GTX330 myself and jump on vatsim with it...that's what I built it for in the first place. TomK

I posted here last night, then Morten posted it on x-plane.org as many org members don't come here so we keep folks informed at both spots. TomK

We are having fun tying in the cool parts of the simulation and wanted to share a bit. There is a lot going on behind the scenes systems wise in this video so here is a quick commentary. We are beginning to tie in a lot of interdependent systems code in this video. You will see electrical, lighting and sound systems working together in subtle ways to maximize cockpit immersion. In this video, I basically play with the generator and GPU switches...but as I do, you'll see some things happening. You can hear cockpit fans running, there are more than one and as the power is flipped on an off, you'll note the cockpit fan noise changes a bit as a fan loses power. Also, when switching between power sources (GPU and generators in this case) the system automatically has to disconnect one bus fully before connecting the other and this momentary disconnect of electricity causes bus loss of power which causes everything that is not on the battery bus to "flicker". The loud sound you hear as generators are connected/disconnected are the main bus breakers, which because they carry heavy electrical loads, are big and heavy and make a loud noise in the cockpit. You'll also note the EHSI and EADI go off and on with power...but they have a "self-test" duration period every time they power on so they don't come on as quickly as the go off. We are still wiring up stuff in the cockpit though but thought you might have fun watching it as it progresses. https://dl.dropboxusercontent.com/u/955680/breakers.mp4

Hey guys. a report after a bit of testing yesterday. I have to convert my Garmin GTX330 transponder to Lua...not the GPS. This looks to be bit more work than other code I converted. I'll have to take some time to reverse engineer my code (its been a while) and then represent it in Lua. I originally thought I could do this in a week, but think it will be longer. The good news is that I am working on it and if history is any indication, once the "idea" is solidified, the code goes very quickly. So in the larger "context", a few more weeks is acceptable to me, but at least it is not indefinite. I am actively working on it so its not sitting on the shelf. From the testing I did yesterday, I am really happy with the performance though my beta tester is having some issues we have to work through. Besides the GTX330 transponder, the Moo is operating great! As far as x-plane GPS goes, we at Laminar know its a weak point and we know it needs addressing so it will not be a one trick pony forever. TomK