Pete Dowson

What are the symptoms? Have you reported these to PMDG? Did you uninstall the original completely before installing the updated 747? Pete

Probably because only FSUIPC is querying Payloads so its offsets are correctly populated for applications to access -- as it has done, using the correct SIMCONNECT requests, and code unchanged, since 2005. It is easy to blame FSUIPC. I get used to it (though it is really depressing). But in this case it should be obvious that it is down to something changed in the P3D HotFix. I have added appropriate comments to the thread you referenced. Pete

See earlier posts in this thread. It's the same thing, as you must have seen else why add to it. but then why repeat it almost word for word. I explained why it probably only happens with FSUIPC -- the payload stations are always read, via SimConnect, by FSUIPC. What is the problem facing you in any case? The content errors are advisory. They don't cause a problem. There are often hundreds of them with some add-ons. Just turn the reporting off if it worries you. It's an option mainly intended to help content add-on providers to debug their products. It has to be an error in P3d related to the HotFix. "Content errors" are just that, errors in the content, not errors in an application. I see it isn't only marked as "RESOLVED" but the thread has been locked too, with no sign of anyone in L-M contributing one word. I find that odd and rather irritating and I've written to them about it. Pete

I was going to ask how that arises. I thought \ was used in paths whilst / is used in URLs. Though it shouldn't work some times and not others either way. Seems odd -- someting more complex than it appears on the surface then. I'll try and fit it in tomorrow. Pete

Well, the code is still there, and it is unrelated to to the conversion to 64-bit, so whilst i've not specifically tested it (it is pretty impossible to test everything every time), yes, it should be fine. Let me know if it isn't. Pete

Maybe. Sorry, I don't know. Generally there can be lots of "content errors" logged. You can worry about then, report them, or ... just switch them off. Pete

I've searched the complete source, and the only "Invalid Argument" error using built-in messages only occurs with WideServer, and Windows socket errors. The latter from the original Lua code. The *** ERROR message is produced by FSUIPC when it receives an error from the Lua code, and the part of the message which explains the error is actually supplied by Lua -- I think it might get the bfull error data from Windows, which has a function to do that given the error number. For "runlua" the *** ERROR can only occur when it calls Lua code to "loadfile", and the only parameter is the path. So something seems to go wrong with the path occasinally on repeats. The full path os made up of the FSUIPC path (i.e. the Modules folder, plus what you add to it. I can log that, but it seems to me that it would be far more productive if I could reproduce the error here so I could track to down to te actual error within the Lua code (i.e. the code that isn't actually mine). So, do you think you can provide anything? Pete

Are you assigning in FSUIPC? If so, what versions of FSUIPC are you using in each? The currently supported versions are 4.969 and 5.103. Pete

It shouldn't happen with 4.969 unless it DOES identify itself as a joystick type device. So I can see what is going on please add these lines to the General section of the FSUIPC ini file and show me the Log file and the CSV file. Debug=Please Logextras=x200000 Pete

FSUIPC may be the only thing causing P3D to access that section of the Aircraft CFG. As it didn't happen before the hotfix is might well be an L-M problem. Report it to them. And without FSUIPC loaded, see if accessing the payloads menu in P3D causes them. Pete

Ok Can you create a small Lua which recreates the symptom? Lua files aren't kept open, so access whilst the previous incarnation is active can't be the cause. When I get back I'll see what can give rise to that error, and add more logging if necessary. "Invalid parameter " doesn't mean any sort of file access problem unless the path is crazy -- i.e. not even recognisable as a path. I'll leave further responses till I get back -- it isn't easy for me on a phone! Pete

Seems like on of your aircraft has a bad payload definition section. Did you update FSUIPC to 5.103, the version for the HOTFIX? Pete

I'm out this afternoon, so this is from my iPhone. I'll be brief. You said it occurs with 4.964 too. So it must have been happening for many weeks. Or have you changed something to bring it on? It looks odd having that Error line with no Lua line number. Is the report from FSUIPC or your code? Pete

Whether a Lua thread is running or not shouldn't prevent RunLua finding the file. Or are you saying it gets loaded then killed? Why are you killing it before RunLua in any case? Running the same Lua again automatically kills the previous edition. You should leave it all to FSUIPC. There's no relation in the timing between the KillLua in one thread and any other threads or "RunLua" action. You cannot predict the order with separate threads -- it depends on Windows threading, loading, processor usage, hyperthreading, etc. Nothing in any of that. In any case you mention 4.964 from long ago. BTW 4.968 is superseded by 4.969. Pete

Good news. It should work in P3D4 as well then. Pete

First off, that is the very original version ofr P3D4 and it has been superseded over three times already. If you want support you MUST check that you are using the latest version first! The currently supported version is 5.103. Please also update your P3D4. The Hotfix for lots of problems, including with SimConnect, was released yesterday. What is the point of that, then, even if I could support an old version? You need the log up to and including the "freeze"! Pete

That shows you are using FSUIPC 4.966c, which I cannot support. The currently supported version is 4.969. Pete

Blimey! You shoud have said up front! Remember I said "The 64-bit solution for external 64-bit programs interfacing to FSUIPC5 is now available"? It is even quoted in an earlier message in this thread! Note the FSUIPC5. Sorry, there will never be 64-bit interface into FSUIPC3. I am no longer in any position to make changes to that 14 year old version! I am amazed anyone is still developing anything for it. It seems to make no sense at all when the latest versions are so good. I may not even develop a 64-bit interface for FSUIPC4, though I could do one there relatively easily if someone asks. Really my 64-bit development was only intended for 64-bit simulators. For FS9 you'll need to adapt the source of the LIB Read and Process functions to avoid using the 32-bit pointer as a pointer -- maybe some 32-bit index into your own data repository, or a 64-bit pointer converted into a 32-bit offset from the base of your code. The pointer itself is never used as such in FSUIPC, so you can adapt it to do whatever you want. Pete

Strange. It works fine here. Which version of FSUIPC are you using? It should be 5.103 now, but the 64-bit client features were added in version 5.102, at the same time as the 64-bit SDK release. Always check you are up to date with FSUIPC! Assuming you are now using the supported version of FSUIPC5, yes. Check the data format built up for the request being sent by the SendMessgeTimeout. i.e. the data in the buffer allocated as the shared memory-mapped file. It's the same as for 32-bit except the Read header has a different ID and the pointer to where the Read function will deposit the data is, of course, 64-bit instead of 32. Pete

Has nothing changed on your system leading to this? Because the software won't have changed -- well, except by possible corruption. The Log is odd. It finished just after this: 188 ---------------------- Joystick Device Scan ----------------------- 188 Product= Microsoft Nano Transceiver 1.1 188 Manufacturer= Microsoft 188 Vendor=045E, Product=07FD (Version 3.21) 203 ------------------------------------------------------------------- Now that point is where it tries to Acquire the identified devices so they can have buttons and axes assigned. Can you tell me what a "Microsoft Nano Transceiver 1.1" is? Is it a joystick type device? i.e. does it have buttons or axes you can use in FS? My guess is that it's a device which is not amenable to the normal DirectInput calls, and this is the cause of the problem. There was a similar report a while back, but for a different device. However, I tightended up the criteria for deciding which devices FSUIPC scanned, and released interim updates for 4.968 which proved successful, so my advice would be to download and install the newly released full version, 4.969, and try that. It is linked from the usual Schiratti site (the text there is stil out of date) and it is also available in the Download Links subforum above. Pete

You have an error then, in the data you are providing. The same source is used in the library which is supplied and linked to the UIPCHello demo. Check your code. Check the data accumulated in the mapped memory before calling SendMessageTimeout. Why are you using the original source and not the compiled LIB file? Maybe you have something ncorrectly set for your compilation. Anyway, you need to do your own debugging I'm afraid. I can't do it from here. Pete

I'm afraid the detection of the FSUIPC interface is in the province of the applications you use. To check that the interface itself is working just use one of the free programs provided -- TrafficLook or WeatherSet, for instance, in the Additional Useful programs part of the Download Links subforum. Maybe the versions of those applications you have obtained are intended for use with FSUIPC4 and FSX? Pete

Delete them when FS is NOT running I hope. As an index of profiles is read initially and maintained in memory. Maybe that's what you are seeing happen? Also, just deleting the Profile section itself does not destroy it in any case if there are any sections carrying that profile name (Buttons, Keys, Axes, Calibrations). You can edit buttons, keys, calibrations, axes, and just use the "reload" buttons in the appropriate tab to get FSUIPC to see them -- or not even that, if they are for a profile not currently in use. But you can't do this with the profiles themselves. The index is preloaded for speed in searching when you load a new aircraft, and is especially important if using "UseProfiles=Files" as then there are multiple files involved. Pete

To get them logged in the next versions you'll need these in the [General] section: Debug=Please LogExtras=x10 Or, with just Debug=Please there, you can edit the LogExtras value in the Logging tab. The sorts of lines in the log you'll get then are like these (for one being SENT by or through FSUIPC, as opposed to being received -- you won't get so many for an interception only: 432248 ExSendEvent(196881, 12345, 0) 432248 ... evnum mask=0, preval=0 432248 ... not intercepted or in options 432248 Sending "????" 196881 [0x30111], Param 12345 432279 *** Intercepted EVENT (direct): Cntrl= 196881 (0x00030111), Param= 12345 (0x00003039) <unknown> 432279 *** EVENT: Cntrl= 196881 (0x00030111), Param= 12345 (0x00003039) <unknown> 432279 FS Control Sent: Ctrl=196881, Param=12345 Pete

Ok. There are flag bits already for logging more "event" information. It'll be one of those, so you'll get other stuff too. More details next ... Pete