draci

Thanks John, do you think a simconnect stall could lead to this behaviour? Especially for the edited part in my above post concerning FSUIPC?

Hello, I use Active Sky as my weather enine and I use REX SkyForce for cloud textures injection in P3Dv5. I have a strange issue in P3Dv5: Quite regularly, mainly after a few hours flight time or over the ocean my clouds get deleted completely immediately after injection by Active Sky. I can see the clouds for a sec and then they get cleared. It happens for example when flying over the ocean, although Active Sky has complete coverage through interpolation I lose clouds and shortly before the coast, thex show up again. But this happens also over the continent, where coverage should be complete. The strange thing is that this doesn't happen with all clouds, especially departure and arrival weather is usually correct. It seems that overcast conditons are especially prone to get removed, my trans-atlantic flight with overcast conditions from Newfoundland to Ireland happened in clear weather. Very annoying. Since Active Sky uses FSUIPC to inject weather, I hope that someone here can help me. What should I log? Can it be a simconnect stall? Or are there some interfering weather engines active? is it FSUIPC overruling the weather injection? I made sure that the REX engine is off and only the cloud sync facility stays on. A very strange issue is also that after a few hours flight time the FSUIPC inflight menu behaves very strangely: If I click on a tab, the tab vanishes, if I click all tabs, the FSUIPC menu is empty, no way to recover the tabs. Any help appreciated.

Wrote a little simconnect client to implement the above functionality. Works without any problems, no recursive calls at all, brakes failures efficiently blocked, me a happy camper. 🙂

Ok, I have tried to reset the P3D brakes failure via .lua scripts for weeks without success. Here's what my main problems are: 1. Writing to the offset 0B63 with ipc.setbitsUB and ipc.clearbitsUB doesn't work. The failure in the PMDG->Vehicles->Failure Menu persists for Left and Right Brake. 2. Toggling FS-controls 66310-66312 via ipc.control(6631x) in order to reset randomly occurring failures doesn't work either or seems to end up in infinite recursions since event.control(6631x,"callback") is called everytime the callback-function calls ipc.control(6631x). Cancelling the recursion via event.cancel("callback") does not help. 3. The FSUIPC Fs-controls "Toggle Left/Righ/All Brakes Failure" surprsingly DO work to trigger a failure, however, repeated use doesn't clear the failure. However, since there are Add-Ons like FS-Flight Control which can both trigger and reset failures, there must be a way to control the failure state somehow. My lua scripts are correct and FSUIPC Debugging/Tracing for them doesn't reveal any issues with my code, the logic runs as intended. What else can I try?

Thank you John, I'm going to try your suggestions.

Corrected the typo: leftFailed <-> LeftFailed and rightFailed <-> RightFailed, but still no success.

Hi everyone, I have an add-on that randomly triggers brakes failures in my sim which is really annoying. The only FS controls I found are toggle_left/right_brake_failure which are controls 66311 and 66312. The following simple lua script brakesresetevent.lua intends to reset the brake-failures when ever they occur randomly. The second script brakesevent.lua (further below) should give me the opportunity to overrule the resetting such that I can sill fail the brakes if I intend to. brakesresetevent.lua: ipc.set("leftFailed",1) ipc.set("rightFailed",1) local lfail = 0 local rfail = 0 function leftreset() lfail = ipc.get("leftFailed") if(lfail == 1) then ipc.set("leftFailed",0) ipc.control(66311) ipc.sleep(1000) ipc.set("leftFailed",1) end end function rightreset() rfail = ipc.get("rightFailed") if(rfail == 1) then ipc.set("rightFailed",0) ipc.control(66312) ipc.sleep(1000) ipc.set("rightFailed",1) end end event.control(66311, "leftreset") event.control(66312, "rightreset") The problem is that although I try to prevent recursive triggering of the event with the global vars leftFailed and rightFailed this seems to happen. In general lua there is the possibility to temporarily unregister and reregister an event. Is this also possible in FSUIPC? brakesevent.lua: ipc.set("LeftFailed",0) ipc.set("RightFailed",0) ipc.sleep(200) ipc.control(66311,0) ipc.sleep(100) ipc.control(66312, 0) ipc.sleep(200) ipc.set("LeftFailed",1) ipc.set("RightFailed",1) ipc.runlua("brakesresetevent") The idea is the following: The first script runs from the beginning of the sim session (Run by FSUIPC.cfg). Whenever I hit the key combo, the first script gets killed by KillLua and the second script is started when releasing the key combo. That's why I restart the continuously running first script at the end of the second script by ipc.runlua. However, whatever I try I get recursive callbacks since the brakes flicker wildly from on to off. I'd appreciate if anybody could help me see my mistake. regards draci

Ok, the problem is resolved, using "toggle brakes failure left" and "toggle brakes failure right" WITHOUT the "toggle all brakes failure" does the trick: it resets the failure on both brakes. However, pressing the key a second time does NOT reactivate the failure, so it's not really toggling, but I don't mind, since for my purposes resetting the failure is all I need. Thanks anyway.

Dear John, thanks for your reply. The 0B63 was just a typo, unfortunately also the parameter 7 has no effect. If I let the brakes fail in the P3D menu, the FSUIPC assigned key does not remove the failure.

Hi Pete and John, I noticed that one of my add-ons triggers random brake failures on my PMDG 747 in P3Dv5 (Unfortunately, I don't know yet which). It's not the PMDG failure from the FMC being triggered but rather the P3D failure from the Vehicle->Failures Menu. So I tried to use the Offset Byte ClrBits Command on the 063B offset with parameter 2 (to reset all brakes at once) but so far without success. If the offset is not working (?-SimE), is there another method to achieve this or am I simply applying the wrong command? Any help appreciated. Regards draci

Thanks John for helping me. I realised that the problem is in fact the SHIFT-key. If I use key-combos without SHIFT (eg. TAB-1, TAB-2, .., etc) the toggling works fine as if I used a button. However, I didn't know that the SHIFT-key doesn't work in FSUIPC commands. Is there a special reason for that? Kind regards, Maik

I'm trying to fool one of my Add-ons into believing that one of the aircraft doors is open when in fact it's still closed. This is needed for the Add-on to work and doesn't influence my PMDG 747 since the aircraft logic uses its own offsets for doors anyway. In order to achieve this I use the "Offset Byte Toggle Bits" Command on the 0x3367 offset in FSUIPC and hand over the bit to toggle as a parameter. This works flawlessly on all doors if I use a joystick button to trigger the toggling (at least on the most important ones since the aircraft has 10 doors but the byte has only 8 bits to toggle). The problem is now that I don't have 8 buttons to spare for the toggling of individual doors, hence I use key-combos (SHIFT-1, ... SHIFT-10). However, if I try use the very same Offset Toggle Bit commands with these key-combos as a trigger nothing seems to happen. This puzzles me a little since the logic of the FSUIPC-command should be independent of the trigger so I'd expect the toggling to work either with both or none of the triggers. What do I miss here? Any help appreciated. Thanks in advance. Kind regards, draci

Thank you John for your valuable help. I will try to do this and report back.

One of my add-ons deletes the P3dv5 GPS-flightplan after touchdown. This is a problem for other add-ons relying on the GPS-flightplan to work properly and that are active until gate arrival (for example a Traffic Board displaying user flight information). All these add-ons immediately fail after touchdown. I had the same problem in FSX times and I remember that I could solve by using the FSUIPC event.intercept function to inhibit the deletion of the flightplan, but unfortunately I don't remember how I did this. Perhaps anybody can point me in the right direction. For example: Which is the right flightplan-event variable to intercept? (I don't find anything suitable in the event list) And how exactly do I do this? Is simply intercepting the event enough to prevent it from happening or do I need to inject the flightplan again after the interception?

Hi to all, I occasionally get sim freezes of a few seconds on long haul flights. Whenever such a freezes takes longer than usual (eg 5 seconds) FSUIPC logs the freeze and afterwards doesn't work correctly anymore: I can't use my lua plugins anymore, if I want to open FSUIPC GUI via Add-ons menu all the tabs are empty! Also Active Sky seems to behave very strangely: after download clouds get injected and stay for half second, then they disappear and skies remain clear for the rest of the flight, even if metar says overcast. I tried to make the simconnect_stall-time larger in the FSUIPC.ini (12 sec) but that didn't help much. Here's the relevant log part: 1439953 ### Mode: PAUSE on 1801891 ### Mode is NORMAL 7377110 ### Mode: FREEZE_ATT on FREEZE_ALT on FREEZE_LATLON on 7436563 ### Mode is NORMAL 12464485 **** Restarting traffic scanning due to non-reception *** My flight still continues without crash but FSUIPC quit logging which indicated for me that is does no longer consider the sim running. I'm running latest P3Dv5.3 with HF2 and latest FSUIPC6 registered version. Is there a way to prevent FSUIPC from quitting? Regards draci The full log is attached for convenience. FSUIPC6.log