Dscho

Has anything moved or is in progress? Like this bird so much! Dscho

many thanks Cameron, is there a special upgrade option from Version 1.7 available or "only" the FSGRW Offer for SMP v4 owners?

Hi community, I have FSGRW 1.7 Build #043 (bought it in Oct 2015 from fsim.net), is this sufficient for usage with SMP 4.7.3 and RWC 1.1 or do I need the new ( 404 ? ) version? As far as I can see 1.7 can inject the weather to X-plane, FS9, FSX, P3D V1, V2 and V3 but not V4, is this correct? Can the new version be used for P3D V4? many thanks for enlightenment. Dscho

hello, after replacing my NV GTX 980 by a GTX 1080 Ti, the popup menus like AutoStart, TQ, preferences and other don't react anymore and can't be closed. Drivers for the video card are updated. For the rest everything seems to work O.K. BTW I need to mention that my screen resolution is 4K ( 3840 x 2160 ), plane version is 1.5.1 Many thanks in advance for relevant ideas for what can be the reason ! Dscho

Hi, now I found the reason for the quirk which bothered me: it has to do with fiddling with the condition lever. For those who are interested: At the beginning the condition lever of the throttle quadrant (Hardware Lever) and the condition lever of the virtual cockpit (Software Lever) are at the "FUEL OFF" position. The Auto-Start sequence puts the Software Lever to the "START" indent, but the Hardware Lever remains at the "FUEL OFF" position. Now when I move the Hardware Lever to the "MIN" indent after the Auto-Start sequence has finished, the Software Lever flips back to the "FUEL OFF" position, only for a short moment, but enough to cause the generators to go offline! The solution is either to control the condition lever solely with the mouse, or to move the Hardware Lever to the "START" indent before starting the Auto-Start sequence.

Here the log files attached. As already mentioned i strictly followed the instructions given by "10-Step Quick Start for x-plane 10 64 bit" manual. This time the Auto-Start didn't finish, already during the AHRS alignment the electrical power has been stopped and the engines too. Edit: And as already mentioned sometime it works, sometime - more often - not! GizmoLog.txt Log.txt

Hi, Recently, not every time but very often, electric power supply becomes completely inoperative - sometimes shortly after auto start, sometimes during early phase of flight. I proceeded strictly as described in the manual "10-Step Quick Start for x-plane 10 64 bit". I didn't see this with the previous version. I am at XP 11.11r2. 1. Has anybody of you experienced this too? 2. Did I miss something or is it a bug? Any ideas ? Dscho

Hi Sundog & Cameron, Phfff ... problem solved ! It was/is extremely weird and puzzling: Speech2Go Voice package is the culprit. In order to enrich ATC voices a bit, i installed some ivona voices and with them Speech2Go. If i select one of the ivona voices as default voice for Windows 7, the problem arises under some particular conditions which i am not aware of. As soon as i select a non ivona voice i.e "Microsoft Anna" the problem disappears. It looks like Speech2Go changes the working directory of the X-Plane process to "Program Files (x68)/Speech2Go voice package/x64" and each access to files from X-Plane with a relative ( to X-plane working directory) path is diverted to this location. And of course, there are no files needed by SkyMaxx. This was it, thanks for your endeavour and sorry for wasting your time Dscho

Checked file system - no error, removed SkyMaxx and reinstalled it again: no change Included Log.txt and directory structure of plugin Log.txt

OK many thanks, i will give it a try and then report result

Hello all, since shortly SkyMaxx Pro 4.6 doesn't draw clouds and puts the message "Error initializing SilverLining: 1" into the Log.txt file. Please help! many thanks in advance, Dscho

Merry christmas, Indeed very good news!

hi birdy, i have FlyWithLua installed, but didn't have any script added to the plugin - everything is default. But i had the suspicion in mind, that FlyWithLua is the culprit. And guess what happened after disabling all the scripts: IT WORKS NOW !!! Now i have to find out, which of those script disadjusts the ADF 1 radio This raises the question: does the Saab 340 really need FlyWithLua? (I don't like FlyWithLua very much) By all means: thank you very much birdy Dscho In the meantime i found it out: it's HUD module test: .... -- do some corrections function radio_limiter() if COM1 < 11800 then COM1 = 11800 end if COM1 > 13697 then COM1 = 13697 end if NAV1 < 10800 then NAV1 = 10800 end if NAV1 > 11797 then NAV1 = 11797 end if ADF1 < 530 then ADF1 = 530 end if ADF1 > 1700 then ADF1 = 1700 end if OBS1 < 0 then OBS1 = 350 end if OBS1 > 360 then OBS1 = 10 end if HDG < 0 then HDG = 350 end .......

Hi JG, thanks for responding! First i have to clarify that ADF 2 works perfectly. It is only ADF1, which shows this problem. The control mode switch is at "ADF", then i dialed in the frequency (327 at LOWL) and move the transfer switch to the "UP" position. The frequency engages and the ADF position pointer of the EHSI points at the correct position. Suspicious is, that the RMI pointer remains at 3 o'clock. Then i did nothing and waited until the ADF frequency flips back, every time to the same value of "530". The time interval is variable between 30 seconds and almost 3 mins. Situation: on ground just after engine startup, i hope this helps Dscho

hello, latest version 1.4.1, XP10.51: a while - about 20 seconds - after tuning a frequency into the ADF, the frequency changes back to the value it was before i.e 530. Has anybody of you captains experienced that too? Or did i miss something? Thanks for feedback, Dscho