tkyler

we've been addressing our bug list and todo list and thought I'd snag a screengrab while bug chasing. ---removed video. there are a few things we have yet to clean up and don't want to set notions about what will be released. TomK

pffff....more vaporware pics? TomK

I love linux....used it for a long time, but never, EVER, blamed anybody for not supporting it. I knew the risks when I used it and that was on me and your usage is on you. Trying to act like its someone else's fault is really in poor taste. You drive down that road, you take the curves that comes with it! TomK

yea..it's been debated endlessly but its a matter of perspective IMO. Take a car rolling backwards slowly next to another car. For an instant, a person questions whether he/she is rolling back or the other vehicle is moving forward...and for that instant, you don't know and have to look a little futher to make a final determination. Some folks would say the car is moving back, others would say the adjacent car is moving forward. The whole "perception" of too much torque is attributable to multiple factors and each person has a different perception of what the cause is (I know I'm resolute on my conclusions) and my whole point during the forum conversations was that the torque reaction is not the mathematical problem...but rather the lack of other factors fidelity that put torque in the spotlight. BUT.....of all factors, adjusting a torque effect in sim would be the easiest solution to compensate for other algorithmic limitations no doubt. So all this time, I just don't like the words "torque is wrong" or "torque is broke" or "fix the torque". Torque is one of the easiest and most fundamental quantities to calculate. Its right, but is the final motion of the aircraft "realistic" is the "effect" realistic? Definitely not always as Larry can attest with his experience......should torque be "tunable to compensate"? yea...I think so. Desktop simulation is a compromise in many areas and I like that fact that folks can fine tune things. It just so happens I prefer not to tune the torque, at least not on the Moo I'd tune it down on some other aircraft though, but I'd never say the torque was implemented wrong in x-plane. TomK

Hi Dave, welcome to the jungle. I'm not sure I'll answer everthing, I'll just ramble on and we can at least start a dialog. When you click and insert anything in WEDs map window, you are specifying a latitude and lontitude point for that "click"...as I'm sure you know. 3D objects are what we call "single point" objects, as they only have a single lat/lon point and a rotation value. This is in contrast to polygons and other things that occupy "area". Therefore you can put objects anywhere....the problem is that with WEDs plain black background, unless you have some kind of visual reference like a accurately imported image map underlay, placing those objects is not particularly easy. One way to get around it is to use google earth and determine the lat/lon point you want to place the object. Then in WED, you place the object in the window in a random location and then in the properties palette, you manually change the lat/lon points of the object. The object will then "disappear" from the screen though as it will relocate when you type in the new values and this creates yet another problem (that MAY be fixed by now....I requested it ten times). In the past, you could not zoom into single point objects....so after you type in new lat/lon points...then getting that object back into the map view to use as a reference in placing other stuff isn't as straightforward as it may seem. It maybe though that feature is in the latest WED....I've been off of WED development for a while and haven't tested it. After the object has disappeared, you would select it in the outline panel and then try and zoom in using the menu: "view > zoom selection'. If that menu is grayed out with the item selected in the heirarchy panel, then the "zoom to point" feature STILL isn't in WED yet (but man it should be!!) You might could zoom out, select the item in the heirarchy and see the bounding box handles in the map view though. There are a few "unknowns" here though that I myself have not tried. I am unsure if you can do a scenery export without having at least one airport specified in the heirarcy pane. Now that doesn't mean you have to have anything on the airport, or it could be an "empty" one...or even import a nearby one just to get you in the "vicinity" of where you want to place objects. If it was me, I'd probably import the nearest airport layout using "Import >apt.dat", then zoom into that to get me "close" to where I want to place objects....then I'd place the object randomly in the map window...type in the lat/lon coords manually and once zoomed into that places object....assuming I was placing several objects in that same area.....place other objects and finally export. If the objects are so far removed so that there IS NO nearby airport...then I'd just try placing the object in the window and typing in coords manually, zooming into the area and try exporting. The exclusions zone aren't something you 'attach to' per se. They are simply a shape where you can tell x-plane not to draw or place autogen entities and you should be able to use them irregardless of airport affiliation. I guess the big question is can you export out a scenery with no airport "created" in WED. I'll find out and report back. TomK

Hi jcomm. I do not subscribe to Dan's 'fix',...there is a reason BenS cautioned him and I would not make any recommendations or expend any effort to alter the torque in the MU2 as I've flown the darn thing and it simply has a ridiculously strong roll tendency; however, I fully understand the desire for users tweaking to their comfort level though, after all, it is your personal enjoyment you are seeking, but folks are on their own on this one. The torque in x-plane is fine, its real, and accurate and mathematically I can demonstrate it. What is not real and accurate though are a whole host of other factors that exacerbate the perception of the effect though so I can easily understand why some folks would want to "turn it down" to compensate....its just happens to be one of those areas, cognitively, that I find accurate and acceptable and therefore am not the one to expend time to investigate the 'fix' or the implementation. Do post any results you find though...I'm sure other folks are definitely interested. Certainly swapping one of the prop rotation directions is the fastest way to lose the MU2 roll...but perhaps you're only seeking to minimize it a bit. If you can't get it to work though.....then there is another tweak you can do and ironically, its what we do in the real MU2. Use aileron trim TomK

As for a bona-fide report....We are most definitely working on it, doing small 3D bits and details, texturing the other parts of the cockpit, the gallies, specular map work, etc...doing mechanisms on the flaps and gear...small areas you don't normally see in screenshots. We expect to wrap up the 3D fairly soon and then will turn our focus to unfinished programming tasks, gui and documentation to round it all out. We're moving along fine. TomK

think its been a long week for Cam

The moon is in retrograde....we don't work when the moon is in retrograde.....or on 2nd Saturdays of odd months or if the Saturday falls on a Tuesday...but we'll get there. TomK

I changed offices since my last update...working out of the house now.....approach over obstacle makes landings a bit long. TK

1. Open Plane-maker 2. Open the aircaft in question 3. go to the menu: Standard > Landing Gear. Click on the "Gear Loc" tab if you're not already on it 4. towards the bottom, description is: "eagle-claw, leg length" You''ll see two boxes for each landing gear...so six boxes across usually. The second box for each landing gear is the leg length. (The first box usually is zero). Lower that number just a bit and go back and forth till you get it like you want it.

Make the "leg length" variable in x-plane just a bit shorter.

SASL is a tool for developers...I am a developer. What do I have against SASL? Not aggressively developed anymore, Philipp patches it as needed.Very limited feature set compared to the x-plane SDKNo LuaGL...means only "low level or simple" custom graphics through SASL API.....only suitable for simple stuff.No access to, nor patterned after a large portion of the x-plane SDK, limiting design optionsAircraft only. danklaue makes this sound bad, but guess what? A push back plugin needs to be global...gizmo can do that. "Smart" ground operations or automatic jetways or catering trucks? In sim flight planner, moving maps...All that's gotta be global. You won't see SASL doing that. Gizmo author is most talented 3rd party programmer in the history of x-plane, has a history of longevity and success that goes back over 10 years. I think the original author of SASL is "gone", but this is heresay. I know Philipp has had to take over some patches of it.And finally...as far as Gizmo "causing problems", you don't know 1/10th the story...you've bought into the .org hype or haven't done your homework lately. In the last few months, we're seeing the MU2, Falco, Saab and 737....released or about to be released with absolutely minimal technical issues and showcasing some of the most sophisticated simulations available for x-plane and we've only scratched the surface. Don't see SASL doing this for developers.....don't even see DreamEngine doing this: https://dl.dropboxusercontent.com/u/955680/sound.mp4 TomK

Here's how I do it....just an FYI. I use a CAD program myself as a "virtual measuring tape", measuring the offsets in CAD and then just input the data into Plane-maker. This is akin to Ben's suggestion above but I find the 3D objects in PM can visually get in the way sometimes and they don't show up in the section editors anyhow. This only gets me about 75% of the way towards the right shape though....as I mainly hit the "major dimensions". Then I go "by eye" from there adjusting the and this is the tougher part and will not be the same for everybody as to whether it is easy or difficult. I happen to have a history of dealing with boat line drawings and can "see" shapes rather well visually so this works really well for me. BUT I don't import 2D images into Plane-maker as it's just a major pain to deal with IMO. I know those who do not have access to CAD software are not as fortunate. As an aside, you can type numbers into those numerical field boxes in Plane-maker..you don't have to use those up and down arrow keys. That speeds things up a bit. TomK

"Difficult" comes in many flavors and is different for each team member, so I can only give my own perspectives. There has been difficulty with the 'tediousness' of the work, difficulty with maintaining motivation, difficulty with team dynamics, difficulty with algorithm concepts etc....but in a more tangible sense, the most difficult part...conceptually... for myself was developing the lnav route calculation algorithm. Its done in spherical trig and attempts to be 'smart'. If you have a right turn over a waypoint for example..but decide to make it a left turn, we re-run the algorithm with the new data, considering aircraft performance and draw the new route...and if its doable (i.e. next waypoint not inside the turn radius)...then the plane will follow it (see screenshot below). This is an ongoing 'difficult' problem though and we still have several issues to solve...but I think the fact that the FMS route calculations, both lnav and vnav...being the last thing we have to tackle pretty much sums up that it's one difficult challenge. TomK

No I haven't, I just have a different perspective thats all. Do what you feel you must. TK

Yes and no Steven. You are picking and choosing your battles here, conveniently I might add. Laminar got publicly blamed for delaying the 757 project but after a series of investigatory emails, the truth was ....well....lets just say, 'hidden' from the org membership (*cough....lie). You want to out Vmax and the 757 team for both lying AND defaming Laminar along the way? That is what its about no? Let it go, its Carenado and Nicolas' battle....its one guy and the org higher ups are just as manipulating for their own ends....you won't change anything. TK

Little follow up for those who think that above video is too crazy to be true! http://www.sfgate.com/bayarea/matier-ross/article/KTVU-producers-fired-over-Asiana-pilots-fake-4685627.php

When I first got into simming.....or perhaps looked at it "again" after a long absence....I do recall thinking, "I wonder if this is EXACTLY like the real thing....how cool would that be to have a serious airliner simulation for under 100 bucks that teaches me everything I'd need to know to fly the real thing". There IS something cool about that whether I bother to learn the simulation that deep or not...just knowing its there should I choose to go a bit deeper on some day when I'm bored....there's satisfaction in that to me...it's like an interactive classroom and so I can't help but aspire to that level for my stuff. We all have to bow to the whims and necessities of the market though, especially during this (longer than I thought) adolescent process x-plane seems to be going through. From the developer side though, I see things here now that I didn't have a few years ago and don't see anything but better and more accurate simulations in the future. Once FSX starts to wane, that's when the ROI will start to hit probably......its definitely a labor of love for now......darn-the-DNA. TomK

Solving the electrical systems depth in x-plane is a deceptively nagging problem that requires one to ignore most all of x-plane electrics save the battery charge. and TBH, it really is the only 'system' in a small GA. You can tie a few circuit breakers to default datarefs but that usually still leaves a lot left. For example, alternators commonly have a field winding tied to a voltage regulator...so there are TWO ways to disconnect a generator (THREE if you want to fail the voltage regulator)...via the generator switch (which disconnects a relay) or the field switch / fuse, which disengages the voltage regulator (not modeled in xplane). In addition, most avionics work on a voltage range...so when the alternator goes down, you will have 'x' amount of time before the battery drains below the minimum level to drive a device...and not all devices have the same voltage range, so you may lose one device before another and x-plane doesn't do this by default either. You need a battery model (different for Ni-Cad vs. Lead-acid), a charging model and a discharging model to get really accurate......but really, what user simulates alternator failure in a single GA or cares if an instruments dies in 10mins vs. 15mins. Is it that we enjoy knowing its there? Most aircraft don't have truly accurate systems and most users don't know it because they always operate the aircraft in a predictable manner and as long as the author makes sure things look right down that path and users don't deviate too far, they're golden. Most developers who claim they have "realistic systems" don't have truly realistic systems....but what they do have is "realistic enough for most folks to enjoy them" systems and there is something to be said for that....BUT at the same time, having truly realistic systems satisfies most all types (there are folks who claim they want accuracy but then complain when they actually get it) so there's something to be said for that too. I think in the end, a product follows a developers preferences and standards and folks who share in those can share in the enjoyment of that product for what it is. TomK

still working away! Details towards the end can drag out a bit making "the end" not so much "the end". We are finishing up 3D little stuffs and working full force on the documentation. We have a '5 document' documentation package (actually a little more, but 2 of those so called "documents' are really a series of documents)... and we're not simply cutting and pasting the real POH. The sim market, while wanting a high degrees of accuracy is still not reality and a lot of what's in those manuals just don't apply to sim users (though a lot does) and we do not feel the need to burden users down with extraneous information for the sake of trying to imply that having a real manual means you have a more accurate simulation or to simply save time. In addition to the POH, we also want to provide training materials as many sim users will be stepping up to this level for the first time and will want to learn how to operate the aircraft in a more training oriented way...its not just for experienced users and so we have documents with these users in mind also. So we are writing from scratch for the most part and this will take a few months while we clean up the simulation in parallel. So we are still moving! Tom K

Thanks Kris/mike....but I don't have my thumbprint on this flight model, its all Morten and the rest of the team and I have to say, it really is winning me over. I've never been much of a "heavy" enthusiast, but this thing does kind of feel "uncanny" in its flying qualities...very surreal, which is the whole point. The goal for us is to just go after reality period...not any one thing the like the systems, visuals, flight model etc, but whatever your eyes and ears take in (sorry, no smells, touch or taste yet) whatever you take it with your eyes and ears...how a needle moves, how something sounds, what the light looks like, etc and of course the systems and physics dictates all that stuff so if we wanted to achieve it at the sensory level, we had to start at the lowest level....all we really want is to simply feel like we're at the controls of a real 737-300....as much as we practically can anyhow. Reality is a tough hombre to catch though and a never ending chase so there will always be something more to chase. TomK

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