Pete Dowson

Thank you! Pete

Are you just pointing out that the P3D4 bug stopping Client Data working properly was not fixed till the HotFix? If so, and you noticed CPF_PAOLO was not up to date, then well done. I should have noticed that. Maybe I will go ahead and test on the other PC after all. (But not till next week now -- busy tomorrow, hospital appointment, then off to my daughter's in Plymouth for the weekend). Pete

You mean in WideClient? If you browse through the Lua Libray reference document, you'll see some functions or even libraries marked as "Not WideClient" or "WideClient only". below I append a list for you. event.timer is okay. i use it quite a lot in plug-ins. There's something else awry in your code. There's no way changing from one type of "loop" (by time) to another should do that. Unless your loop doesn't inlide an ipc.sleep so that you don't hog the processor. Try ipc.sleep(2) if you want to do it at the same speed as the timer, though i think you'd find the timer method only gives you 2 msecs approximately. You might need to allow more for a contained loop. Ah. I don't think you mentioned that before? I would guess that, because the WideClient process won't be as "busy" as the FS process, your timer events were arriving much closer to the 2mSecs than when you were in the FS process. I'm pretty sure that with TCP protocol, and maybe UDP too, the Windows functions allocate buffers from system space for each block , or each block requested even if not arrived. Maybe these were accululating more rapidly that they were freed. Try a longer timer value. 500 times per second does sound rather extreme. Try a much longer time (say 20) then wor downwards if needed. It would need someone who can make some sense of the very dense, uncommented, code in the "socket.core", "mime.core" and "ltn12.core", which are the parts which are simply built into FSUIPC4 as ready-compiled code. Or if you can find 64-bit compiled versions of these which are Lua 5.1.x compatible. By "go back", do you mean to P3Dv3? Pete Here's the list i mentioned: [Not WideClient] ipc.ask ipc.axis ipc.buttons ipc.clearflag ipc.getLvarId ipc.getLvarName ipc.readLvar ipc.readPOV ipc.RestoreFriction (not in FSUIPC5 yet) ipc.setdisplay 9dummy provided in WideClient) ipc.setflag ipc.SetFriction ipc.setowndisplay ipc.testbutton ipc.testflag ipc.toggleflag ipc.writeLvar mouse: library not included event.button event.control event.gfd event.intercept event.key event.Lvar event.mousehoriz event.mousehoriztrap event.mouseleft event.mouselefttrap event.mousemiddle event.mousemiddletrap event.mousemove event.mousemovetrap event.mouseright event.mouserighttrap event.mousewheel event.mousewheeltrap event.param event.vriread [WideClient ONLY] ipc.setbtncol ipc.setbtnstate ipcsetbtnstateonly com.gethidbuttoncount wnd complete library display complete library

It souds like they've broken the Client Data facility n their aircraft which FSUIPC uses to populate the clients. The facilities for "custom controls" aren't related to that. But then, earlier, how come you got 65A2 doing what you want? Is that no longer the case as well? Have you still got an older version of FSUIPC? According to Nervures, in an earlier message, the 777 ones worked in 5.103e. At present I'm still unable to test here but there's no point in me trying if the latest PMDG updates have messed the Client Data facility up. If you can't find 5.103e please send me an email on petedowson@btconnect.com, as I could do with verification of Nervures assertion. (Something is very wrong on my normal test and development PC. since my last message all loads for any of the aircraft, whether on P3D3 or P3D4 simple cause P3D to hang solid with a black screen. I'll have to wait till I can test on another PC.) Pete

Well, there's something wrong here. I've installed the 737, 747 and 777, for P3D3 and P3D4, and .... nothing in any of them work, in P3D3 or P3D4. The mouse pointer does not change at all when moved over any of the switches. There's no way I can find to get the electrics on (battery and so on), so I'm not sure whether all the zeroes I get (both for P3D3 and P3D4) are correct or not. It looks like the PMDG code uses the external (IPC protocol) connection to SimConnect. I know this doesn't work on my development PC (I would need to reinstall windows upwards to fix it). FSUIPC uses the fast internal "pipe" so works in any case. I think I proved this difference with the PMSG aircraft by disabling the Simonnect options (in its XML file) except for the Auto" one, which uses Pipes internaly. I'll have to instal the aircraft on a different PC to test the offset data. I might not get to this for a few days now, but I'll make a start today, perhaps with just one aircraft. Pete

That sounds like conflicting assignmens. Go into the FSX settings, control assignments and DISABLE controllers. Pete

All those can be assigned in FSUIPC, with more options and choice of assignments. What's more, using Profiles you can have different assignments for different aircraft, automatically changed on loading aircraft. If the £erratic inputs" are due to hardware malfunction, interference between separate inputs, or a bad connection, then yes, of course. But if, as I suspect, they are due to conflicting assignments, then having them all assigned in one place and properly calibrated you should be fine. Pete

Can you report it to PMDG please? I now have test licences for all three aircraft, so I will check here now and also report to PMDG. I assume this is only for P3Dv4? The P3Dv3 version works okay still, I hope? Pete

Well, the cause is still unknown, the change is really just a work around. Pete

Not that I know of, but if you get conflicts that's one of the things to look at. Pete

You seem to have just sent a repeat of an older message, superseded now by many others. I suggest you go basck and browse through the thread and see what you appear to have missed. Pete

Okay. Those are two different errors. I'll take a look, tomorrow probably. Okay. So it looks like it isn't related to Sockets itself. Must be something else. Are you sure the Lua plug-in is using only facilities supported by WideClient? Mind you, if it is using libraries or functions not included you should just get a Lua error report saying so. Pete

Yes: 1. The log entry saying "waiting for DLLstop was added later, and 2. Calling "Simconnect_Close used to cause crashes on some systems with earlier versdions of P3D, so it was optional disabled defaulted to not do it). Don't you see the 12 second gap between 61750 Sim stopped: average frame rate for last 33 secs = 27.1 fps and 73984 === NOTE: not calling SimConnect_Close ... The values on the lft are in milliseconds, so that's a bit over 12 seconds! Pete

It will suffer the same an the documented HIDE option -- if the Window first opened by the app is NOT the final one (and I think PSU is like this, as here it does take quite a while before it's main Window appears) then it can't change it. Pete

I see my colleague Thomas has tested this now, and found it to be okay, and working as it should. Thanks Thomas! Pete

Custom controls are the way. PMDG went out of their way to provide a really comprehensive set of facilities both for cockpit control inputs and display and indicator outputs. It's a shame to even contemplate using something a crude as mouse macros, which are, after all, a hack direct into code which changes as software is developed. Pete

That's quite short. I've not idea what SimConnect is doing in that time (here's in both P3Dv3 and v4 it's more like 30 seconds) , but it isn't FSUIPC that's holding matters up. I think it is P3D tidying itself up -- after all FSUIPC does make it extremely busy! Not the "problem", but the indication of what it is doing. Until Simconnect actually calls FSUIPC's "DLLStop" function, FSUIPC cannot proceed to clear its own stuff down. Otherwise you'd get a crash for sure. Well, FSUIPC has asked SimConnect to do an awful lot -- everything really. FSUIPC is the biggest customer SimConnect has, by far. It isn't "wrong", it is just the way it is. FSX and FSX-SE are similar. Pete

I've tested here both scenarios: with an INITIAL.LUA starting before P3D4 runs, and a (restarted) WideClient running AFTER P3D4 is full loaded. No problems with the socket requeire call, or any subsequent socket activities, though i dodn't actually connect to it from another PC. For tresting I'm using the Lua plug-in supplied for that -- "testsrvr.lua" in your Lua examples ZIP, in the FSUIPC Documents subfolder. Maybe it is something specific to the plug-in you are using. You cannot always run the exact same Lua under WideClient that you can on FSUIPC, or vice versa, as some things are only applicable to their own setting. Could you try with that testsrvr.lua instead, just to prove that it isn't related to the Networking side of things, which is what we were trying to deal with. You can run testclnt.lua too -- they'll just connect to each other (see description in the example list in the Lua plug-ins document). Pete

No. here's absoluely not enough offset space to justify this. No, sorry. This would wreck far too many existing implementations. And even if it were a user option, the changes in the code at this stage would be far too error prone to risk. The purpose of these tables is for TCAS indications on the aircraft ND. Nothing else. The facilities SimConnect provides for other purposes are perfectly good, and it is those facilities used by many programs needing more than just supporting TCAS images on the ND. If I was going to change either table it would be to reduce the ground table and increase the airborne table, but it is too late to rectify that mistake too. In any case, no matter how many aircraft there are at your airport, why on earth would you need to identify in this way more than those you can see form your position? The table does give the nearest 96, not just any old 96! Pete

As stated in at least one of the documents supplied with FSUIPC5, mouse macros are not supported in P3Dv4. they may well be one day, but certainly not for some time. They depend on facilities from L-M being implemented. They've been requested and are "under consideration". Why? That's one of the aircraft you certainly DON'T need mouse macros for! It comes with a complete set of custom controls to operate every switch in the cockpit. See the list in the .h file in the aircraft SDK, installed when you install the aircraft. Pete

64C8 is not an "offset", it's an actual memory address in the WideClient process. The offset being written at the time is shown in the line before: Offset=9BFC, Size=4 which is used internally between WideClient and FSUIPC to handle the Lua display window on the FS PC. Are you using Lua display facilities? Where's the log please? Any crash details from Windows? I really need such information. Just saying "crashes" is really no help. So, is P3D4 running by then? If not what changed since the first time? Can you show me the WideClient.INI file you use to run WideClient on the same PC as P3D, please? Pete

That's okay. It has been confirmed as okay (see earlier in this thread). That is very odd indeed. I don't see how the 777 is okay but not the other two. the code is identical, except fron the exteas like the three 747 CDUs, and of course the IDs, which are most vertainly the same as they were for P3Dv3. I can't really do anything else about this at present. I'll chase them if I don't get a reply soon. Pete

I've checked the code in FSUIPC. It is as it should be, and it is doing exactly the same 9but with different IDs) as for the 777X which is confirmed as working. So if you can check your end and that looks okay, then I think it's over to PMDG. (I'm still waiting for a response to my request about this). Pete

Yes, got them. The logs for both Auto and Yes show that FSUIPC has requested the offsets and is just waiting for Simconnect to supply. This is the message confirming that: PMDG 737 offsets enabled So, either I have a bug, only in the 737 request not the 777 one (which I'll double check now), or the problem is with the PMDG 737. Did you enable the offsets in its own configuration file? Pete

It's the LOG file I need, not the INI. And have you tried after changing the "Auto" to "Yes" in the parameter PMDG737offsets=Auto ? Does the aircraft name or path include the sequences PMDG and 737 somewhere? If it only says PMDG and NGX then I'll need to do another small change for "Auto" to work. (It's for this sort of check, as well as other things, that I need to see the LOG file). Pete