mgeiss

‎If only that were true... UUDD? Not in database. ZKPY? Not in Database.

It's just a placeholder because the Mac version is not yet available. The PC version was also prized around 12 million before it was released. The 747 II is $228 million: https://www.precisionmanuals.com/ProductCart/pc/viewPrd.asp?idproduct=107&idcategory=0

Looking great! I didn't have a chance to watch the whole video yet and was wondering if anything was said about downwards compatibility in XP11 regarding planes and scenery from XP10? But I guess it's too soon to be answered yet.

This will be sufficient, although there might be differences between the interfaces regarding their sensitivity to very short button presses, which is what the interface practically sees when the encoder is being turned.

You don't need to do any programming. A rotary encoder basically works like two buttons. One is triggered in every detent when turning clockwise, the other one when turning counter-clockwise. They are also used in real cockpits. The only thing you need is a standard USB-Joystick-Interface (which you might already have), which translates the encoders output to two joystick-buttons. I use Leo Bodnar's interfaces for all axis, buttons and encoders: http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=94&products_id=204

What you need is called a "rotary encoder". I would not get the cheaper ones, as I experienced sone quality issues like imprecise behaviour and bad durability with those (they were the cheapest of the ALPS line of encoders). Most stores for cockpit building stuff also sell encoders.

So i wrote a lillte bash script to generate 1x1 deg exclusion zones for objects, forests, roads and facades. It's not perfect jet, but text2dsf does output a working dsf which can be imported into WED without a problem. I still need to test if it serves it's purpose... If you are interested in the (not yet pretty, I do that once a year maybe) code, you can take this as a basis #!/bin/sh #area lat_start=32 long_start=-124 lat_end=38 long_end=-114 #variables lat=$lat_start long=$long_start lat_prefix="" long_prefix="" lat_n_prefix="" long_e_prefix="" #output while [ $lat -le $lat_end ] do while [ $long -le $long_end ] do if [ $lat -ge 0 -a $lat -lt 10 ] then lat_prefix="+0" elif [ $lat -ge 10 ] then lat_prefix="+" fi if [ $long -ge 0 -a $long -lt 10 ] then long_prefix="+00" elif [ $long -ge 10 -a $long -lt 100 ] then long_prefix="+0" elif [ $long -ge 100 ] then long_prefix="+" fi if [ $(( lat + 1 )) -ge 0 -a $(( lat + 1 )) -lt 10 ] then lat_n_prefix="+0" elif [ $(( lat + 1 )) -ge 10 ] then lat_n_prefix="+" fi if [ $(( long + 1 )) -ge 0 -a $(( long + 1 )) -lt 10 ] then long_e_prefix="+00" elif [ $(( long + 1 )) -ge 10 -a $(( long + 1 )) -lt 100 ] then long_e_prefix="+0" elif [ $(( long + 1 )) -ge 100 ] then long_e_prefix="+" fi echo "A" > ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "800" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "DSF2TEXT" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "# file: $lat_prefix$lat$long_prefix$long.dsf" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/west $long_prefix$long" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/east $long_e_prefix$(( long + 1 ))" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/north $lat_n_prefix$(( lat + 1 ))" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/south $lat_prefix$lat" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/planet earth" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/creation_agent WorldEditor1.4.1r1" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY laminar/internal_revision 0" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/overlay 1" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/exclude_net $long/$lat/$(( long + 1 ))/$(( lat + 1 ))" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/exclude_obj $long/$lat/$(( long + 1 ))/$(( lat + 1 ))" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/exclude_fac $long/$lat/$(( long + 1 ))/$(( lat + 1 ))" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "PROPERTY sim/exclude_for $long/$lat/$(( long + 1 ))/$(( lat + 1 ))" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt echo "# Result code: 0" >> ./Daten/$lat_prefix$lat$long_prefix$long.dsf.txt long=$(( long + 1 )) done lat=$(( lat + 1 )) long=$long_start done

Thanks again! As far as i understood, an exclusion zone should to cover the entire tile but it should not be larger. Is there a simple option in WED or Overlay Editor quickly select a whole 1x1 Tile (like Ctrl+A in an Editor) as the area for the exclusion zone, or do I need to draw the rectangle and position it exactly over the tile boundaries?

Thanks crisk73! I'm afraid I have to use exclusion zones, but putting them in a seperate scenery pack seems to be a neat solution! I read about creating seceneries for a while yesterday, and for a large number of tiles it seems to be a good option to make text files with a little script and to use a text-to-dsf tool to create the finished scenery tiles.

Thanks, kickremi! I think exclusion zones would work (I don't have any experience with WED or Overlay Editor). I was hoping there would be an easier or at least semi-automatic way to achieve this.

I am starting to generate photoreal scenery for the Pilotedge service area using G2XPL. However, while it's common practice to combine photoreal with autogen, I want to achieve the opposite. I'd like to completely get rid of all objects, roads and trees within the photoreal tiles without losing any objects in custom airports. Because of this, I can't just set objets to none in the rendering options, as this also affects airport objects. I could set roads and trees to none and re-enable them when flying over "normal" scenery, but of course it would be nice If this could be autmatted. Is there an easy way to tell X-Plane that it shouldn't show any objects, roads and trees for a given tile wthout affecting airports? Or - if that's more simple - can I temporarily disable X-Planes autogen system alltogether, and put it back to live for stock/HD scenery?

I don't know, i neither use TOPCAT nor TOPER.

That's right:

There is a version of TOPER for the 737 classics: http://secure.simmarket.com/toper-calculator-tool_b737-classics-%28de_8354%29.phtml

I don't know if it's optimal, but I use the following as a roule of thumb and it works fine for me: Short flights under 180-200nm: Flight level = distance rounded up and adjusted to even/odd thousands for westbound/eastbound ops Longer flights: FL180 or FL190 if heavy, FL200 or FL210 if light

From your Log.txt: Seems that you have installed X-Plane in a folder which contains special characters in it's name. Maybe that could be a reason?

Just a guess: Are you using MisterX6's KSAN scenery? Many people report having CTDs when flying in/out/near that scenery. MisterX6 has not found the cause or a solution yet. Try to remove / disable the scenery temporarily if you have it installed.

No questions about wing flex yet? That's sad...

Should be a case of "works as designed":

Release is scheduled for June 1st: http://www.avsim.com/topic/489057-24may16-pmdg-dc-6-cloudmaster-for-x-plane-update-and-release-info/

As Jan would probably say: Works as designed.

I have mine locked to 1/2 refresh rate also, and it's very smooth. 30fps is totally adequate for flying, but you might feel the need to unlock your fps when using TrackIR, as higher FPS values can give a more smooth/responsive feel to head movements with TrackIR. That being said, I keep the 30 fps lock when using TrackIR from time to time and it's a.o.k. for me.

Hallo Jan, no problem, it's probably something I'll get used to after some more flights. But it's nice to hear that you are considering some optimizations.

This is not an important issue for me, more a suggestion for some optimization in a future update when the bugs are taken care of. When using some switches on the overhead panel, I often find myself accidentally toggling the switch next to it. Most of the time this happens with switches that are sitting next to each other in rows (lights, window heat, elec/hyd pumps etc.). I have the feeling that this could be because of the location of the click spots, which seem to be sitting towards the base of the switches. Naturally, I tend to click on the end of the switch (the white "hat"), just like you would do it in the real world. I don't know if it's even possible to have a click spot towards the end of the switch, which then also changes it's position when the switch is moved. But I would like to inquire about a possible optimiation to the click spots. But the again it might be just me having some little issues with that ( talking about bean counting ).

It seems that we won't have to wait too much longer for the DC-6: http://www.avsim.com/topic/488271-08may16-pmdg-dc-6-update-beta-testing-nearly-finished-for-x-plane-release/