Ray Proudfoot

Hi Pete, Nice to hear from you. 🙂 Nothing else updated for quite some time. I did update the BIOS today - first time since getting the PC 3 years ago. The only update to FSUIPC was a little addition John did for me for Day Number of Zulu date a couple of months ago. No change to WideClient. I’m going to test a pause tomorrow with just the lua file running and nothing else and if the time I display on it doesn’t update after a pause that may offer a clue. Maybe enhanced logging might help. I see v5.3 is out so will update in a couple of days. Assigning cores looks interesting and could improve fps.

John, I’ll run a test tomorrow with P3D running and just wideclient on the FSSUPPORT machine. That will be running the lua script and nothing else. Pausing P3D for a few minutes and observing what happens when it’s unpaused may reveal something. This is something relatively new. I’ve had this version of RC4 for 15 years and never encountered this problem with previous versions of flight sim. v4, v3, FSX et al.

John, RC4 was running on FSSUPPORT. DELL-XPS15 was running a program showing Ai aircraft in P3D. Very light use of wideclient. I didn’t try restarting RC4 because I could see the data in a lua file displayed on FSSUPPORT was also not updating. That shows current Zulu and local time so I knew the problem wasn’t just limited to RC4 as the time displayed differed to that in the sim.

No, the logs are for the same flight today. The wideclient log I attached was for the session from launching wideclient up to the point after I unpaused P3D and realised I couldn't talk to RC4. At that point I terminated wideclient and started it again. I haven't supplied that log as everything was okay. The wideserver log was started when P3D started today. Nothing relates to any previous flights. No hurry. But if you can spot anything that might explain why pausing the sim for 40 mins would cause the connection between wideserver and wideclient to 'break' I'd appreciate it. I had a similar problem yesterday but haven't supplied any logs for that.

I suppplied the FSUPC one earlier but here are the wideclient and wideserver logs from today's session. The wideclient is the one from the session I had to terminate due to a lack of comms between the two PCs. There are some disconnections on the server. Might that be the reason? Ray_WideClient_Log.zip

Hi John, here's the log. Can't see anything obvious. Can SimConnect get blocked up with data when in pause mode? RayP3Dv5 Log.zip

It happened yesterday when I paused the sim two thirds of the way to the destination. Same symptoms with RC4 very sluggish and not keeping up with my progress. But after landing I checked Task Manager - Details and noticed couatl64 was hogging the CPU. That didn't happen today. I'm inbound to Madrid and will post the log after landing.

Hi John / Pete, Running FSUIPC v6.1.5b and WideClient v7.156 with P3Dv5.2 HF1. I setup a flight and started Radar Contact v4 on the client. Half-way to the departure runway I paused the sim for lunch. When I returned I unpaused and continued to taxi. I had an RC instruction to contact Tower but when I pressed the button to acknowledge RC was unresponsive. I then noticed the lua display on the client was showing the paused time, not the current despite me resetting it. It looks like comms between the two machines has been broken. I had to restart WideClient and the other programs including RC4 to get back to normality. Any idea what could have caused this? Would a FSUIPC log help? The sim was paused for around 35 mins.

Thanks John, works a treat as shown with the aircraft parked at Honolulu - 10 hours behind GMT/UT.

Hi John, That's very kind of you thanks.

Hi John / Pete, In the FSUIPC Offsets PDF there is an entry for Zulu Day of Week. Reading this value and together with other offsets and a bit of code I can display Mon, Tue, Wed etc in a LUA display on a wideFS PC. I find this helpful when checking Ai timetables as I can see the local time and date in FS. See attached image. However, the Zulu Day Of Week value has no corresponding Local Day of Week value. So, for example if I'm located in Hawaii or New Zealand at certain UK times the Zulu Day of Week value is for the wrong day. It shows my day of week rather than the local day of week. I appreciate if there's no value in P3D you can't extract it. But is there any way it can be coded in LUA to show the correct day of week?

I would have to learn a whole new system John. It might appear clunky but it works. I tried right-clicking on the separate door lights on the overhead hoping it would make them move. No chance. The CDU system seems the only way in combination with GIT to get the LED on my T8 panel to light up.

John, I have to say FSUIPC is very impressive to run this code so precisely. When you consider it’s navigating its way through the CDU menu it does it extremely quickly. It just needs the user to get things right. 😃

The opening sequence was fine. Just the closing. 😀

Problem identified and solved. I didn't tell you the full picture. I also use GoFlight Interface Tool so I can get the LEDs to illuminate and extinguish depending on the door state. I had already programmed front Left and front Right into GIT and was repeating the action via my code above. So front left and right were being operated twice - hence the problem. I've removed the offending lines and now the code works flawlessly. Thanks all for your suggestions. 👍

I may have a solution. Looking through the events these are listed... // Custom shortcut special events #define EVT_LDG_LIGHTS_TOGGLE (THIRD_PARTY_EVENT_ID_MIN + 14000) #define EVT_TURNOFF_LIGHTS_TOGGLE (THIRD_PARTY_EVENT_ID_MIN + 14001) #define EVT_COCKPIT_LIGHTS_TOGGLE (THIRD_PARTY_EVENT_ID_MIN + 14002) #define EVT_COCKPIT_LIGHTS_ON (THIRD_PARTY_EVENT_ID_MIN + 14003) #define EVT_COCKPIT_LIGHTS_OFF (THIRD_PARTY_EVENT_ID_MIN + 14004) #define EVT_DOOR_FWD_L (THIRD_PARTY_EVENT_ID_MIN + 14005) #define EVT_DOOR_FWD_R (THIRD_PARTY_EVENT_ID_MIN + 14006) #define EVT_DOOR_AFT_L (THIRD_PARTY_EVENT_ID_MIN + 14007) #define EVT_DOOR_AFT_R (THIRD_PARTY_EVENT_ID_MIN + 14008) #define EVT_DOOR_OVERWING_EXIT_L (THIRD_PARTY_EVENT_ID_MIN + 14009) #define EVT_DOOR_OVERWING_EXIT_R (THIRD_PARTY_EVENT_ID_MIN + 14010) #define EVT_DOOR_CARGO_FWD (THIRD_PARTY_EVENT_ID_MIN + 14013) // note number skip to match eDoors enum #define EVT_DOOR_CARGO_AFT So rather than program events to navigate through the CDU these may be the solution. More later...

Yes, it’s LSK5L from memory to move up one level in the CDU menu. The top level is two levels up. I’ll try the logging option and see if it reveals anything.

Luke, I have no experience with LVARS. Given the completeness of the PMDG SDK you would expect all this to work. I’ll check with them if there’s a direct command for the doors operation. The commands beginning with P are the on switch action and U the off switch action. They’re identical for each switch.

Hi John / Pete, P3Dv5.2HF1 with the PMDG737 NGXu and FSUIPC6 v6.1.0.2. There was an excellent tutorial posted here a few years ago that showed how to program actions for the PMDG737 using GoFlight hardware. I used it back then for the 737NGX and have copied / pasted it for the 737NGXu as the SDK is identical for these purposes. One multiple action is to open and close Pax doors (left forward and aft) and the other is for cargo (forward and aft). So 2 doors for each of 2 switches. Whilst the opening sequence always works more often than not the closing one doesn't with one door on each sequence remaining open. I've reexamined the instructions but cannot see a problem. The sequence is shown on the attached jpg. Any help would be appreciated for this frustrating problem. The sequence starts by selecting the MENU option on the CDU and navigating to the Doors menu. After actioning the doors the menu actions take the user back to the top level of the CDU so each sequence starts at the same point.

ShowMultilineWindow=No SuppressSingleline=No SuppressMultilineFS=Yes Has fixed the problem. 👍 No need to delve into very old code. Thanks!

Hi Pete, Happy to do the test you suggest. I’ll report back later today. Thanks for checking this.

Pete, don't spent much time on this. It's soon sorted but it would be nice if it didn't appear at all. Shouldn't SuppressMultilineFS=Yes prevent the RC window from showing? The options in FSUIPC don't make any reference to SimConnect and like most, I'm not an expert on how these things are controlled.

Hi Pete, I use ShowText on a WideFS PC for Radar Contact. Have done for years. No extra space on that monitor for another lua script window I'm afraid. This seems to be a long-standing issue. I had the same in v4 but just lived with it. It's not a major issue but it just seems that if I select the option not to show a multiline SimConnect window for RC it should work.

Hi Pete. Doing that would also suppress the Active Sky stuff wouldn't it? I want to keep that as it's useful to know when the wx is being updated.

Hi John / Pete, Running v6.1.2 in P3D v5.2. I use Radar Contact on a separate PC/display so have no need to see the window for RC on the sim PC. I have selected Suppress Multiline in FS's Window so in theory should not see the RC window. But I do when it's first launched. I have these settings in the ini file:- ShowMultilineWindow=Yes SuppressSingleline=No SuppressMultilineFS=Yes Can you spot anything wrong with those options that would cause the RC window to be displayed?