Pete Dowson

Thanks. Very strange. No sign of anything specific to Lua or sockets. There wasn't a list expansion against the FSUIPC.DLL entry, was ther?. It something got loaded by FSUIPC (effectivel), then it might be there, like a subfolder entry. I'm going to have to set up to PCs running P3D4 with my LuaSockets example (from the Lua Examples ZIP) -- a Master-Slave link to make one sim follow the other. Not sure when I can fit that in though. Pete

Sorry, how do you find "mess". I'm not sure what you mean. Don't mess deleting files, please. you could make things worse. There's no point in looking in folders. In Device Manager you would normally find Game Controllers like the Saitek devices under the entry "Sound, video and game controllers", but if there's nothing there remotely looking like your devices, they could just be listed under "Human Interface Devices" as "Hid-compliant game controller". If you can't find them, I can only think I'll have to edit your Registry for you. (I'll supply a .reg file which removes just the culprit entries). It doesn't need anything but the default Windows Game Controllers driver. If you've deleted something which is a default windows driver you may need to run Windows Repair, or even re-install Windows. In fact, with all the time and messing about we are doing it might be quicker just to reinstall. But don't do anything at present EXCEPT in the Device Manager as above. Failing that, I'll first just do it by deleting the entries in the Registry. Sorry, I don't understand this part. Pete

Hmmm. I don't understand how that's working. If you have time and the inclination, do you think you could download Process Explorer and run it when P3D is running and check what DLLs are in use by the process. It will be an almighty long list though, so don't bother if it looks too daunting. https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer Pete

Posted twice, for good measure? You seem to have started P3D before connecting the devices. Is that right? FSUIPC signals that devices were connected after everything was started and so re-scans. The INI file report that only the Throtte was connected, as you said, but it appears to be listed with the same GUID as the Stick. Did the Throttle respond okay in the Axis Assignments tab? Check now if you don't know. I need to analyse the log further -- it's a rather complicated sequence because of the re-scanning. but it does look to me like a screwed up Registry for these devices. It's the Registry entries for the two devices. I am not convinced you uninstalled the devices properly at all. As John said whilst I was away: and I requested again last Friday: but to which you replied, rather confusingly and ambiguously: If you do this properly it should clear out all references to your devices. To be sure it does, first unplug them. Then, knowing it's the devices themselves which need uninstalling (not explicitly drivers now), you use Device Manager (one of the Control Panel apps). When you select uninstall for a device entry you are also asked whether you want to also uninstall drivers. Just say yes. Confim everything. Re-boot the PC. THEN In case there are multiple entries as you suggested Friday, do all that again. Keep doing it and re-booting until there are NO entries for those devices there. ONLY THEN reconnect them Oh, one other thing, whilst in Device Manager: find all the USB devices and ensure that 'power management' is turned off in the Properties of every one of those which has such a facility. Now start P3D. Let me know the result then, with those three files again. I'd like to compare the result you then get with what you already supplied. I honestly think all of this is down purely to the mess some Saitek installs seem to make of the Registry. Please, if there's anything you don't understand or can't find, do not guess. Ask. Pete

I had to delete that post. You included your Registration for others to copy. If SimMarket find that now being distributed for others to use they will invalidate it and you will have to purchase another. it is a violation of the terms of sale! Please ONLY post the three files I listed!!! Pete

You would have to try using that instead of the one you are using. Pete

Well _tl appears here as a function call. I just don't know what that function is. I would have used the more usual (I think) if read.LVar("L:AB_MPL_FD") == 0 then I don't see how your _tl is reading the LVar to compare with 0. It looks like some function you forgot to include from wherever you got it. Surely there's a syntax error reported in the FSUIPC4 log. Did you check? They might be, but does it tell you how to use them? But FSUIPC provides a built-in control to List all current L:Vars and their current values, and there is a live log provided, on screen, by the example Lua plug-in provided to Log them. I doubt you can unless some other user has experimented and worked it out. I'm surprised they were supplied with the aircraft files -- that is most unusual. The aircraft makers don't provide them for user benefit. Pete

Is it complete there? What is _tl("L:AB_MPL_FD", 0) Did you use the Lua plug-in to Log LVars as they change to see if that FD one did operate with 0 and 1? What list did you use? In some aircraft implementations the L:Vars you find are indicators not actuators -- they just indicate the state of the switch to other parts of the cockpit implementation. Have you considered using Mouse Macros instead? FSUIPC3, FSUIPC4 or FSUIPC5? Don't edit the [LuaFiles] section. That is generated automatically! You are loading 6 lua files automatically, no matter what aircraft you load. Is that what you want? And how am I supposed to tell if you are loading the one you are asking questions about? You say some things work. if so, then surely it must be loaded? Pete

Why lost? Run P3D4. Then provide THREE files, not TWO: FSUIPC5.INI FSUIPC5.LOG FSUIPC5.Joyscan.csv You just forgot to supply the log file as requested. The whole point of adding those two lines, which you did, was to get more information in the log, but I cannot use that information unless you supply that log. Pete

And the Lua file doing your UDP exchange is running in FSUIPC5? If so, that is weird. I certainly don't think a 32-bit DLL can run in a 64-bit process. I see that the "socket.lua" file uses a DLL called "socket.dll", not "socket_core.dll", though I suspect that the socket.dll needs socket_code. Do you have a socket.dll there? Pete

Not yet. But if you have it working there will be other DLL's (as well as FSUIPC5) either in Modules or in a subfolder in Modules, like Modules\Lua or similar. Pete

Oh, so they have -- at the start! ;-). I looked at the end, where most folks add them. Apologies. Pete

Unfortunately, the LuaSockets files needed aren't included in those ZIPs. They appear to be the main Lua interpreters and ancillaries. Pete

Could you explain how, please? That "socket_core.dll" is definitely the 32-bit version. Are you using P3D4 and FSUIPC5? Pete

And still no log. the INI and CSV are no use on their own. I asked you (twice before now) to add two specific lines to the INI and supply the resulting log. Pete

By having a miimum of 4 acceptable, if there is a delay after 4 characters are received then you will get what has already arrived. The delay may be from the Arduino end, or it could be a higher priority action happening in the PC. Altough I do set the comms input at high priority, it isn't at "critical" level, which would be needed to have exclusive use of a processor core for that thread, but not warranted and problematic. So why not use that? Fixed length messages are bound to be more reliable and easier to handle. 3823203 LUA.0: A=00 3823218 LUA.0: 261 This illustrates what I said. 4 characters arrived but there was a delay before the "261" part. 3823297 LUA.0: A=00259 3823422 LUA.0: Here the delay was before the terminator you otherwise wait for. In any case, shouldn't you be discarding invalid input? Pete

MOVED TO SUPPORT FORUM Please ALWAYS post support questions to the Support Forum, and certainly not to "User Contributions". (After all, this is a request for help, not a contribution to help others). =================================================================================== The error message is from some program you are using interfacing with FSUIPC, it is not from FSUIPC. It will simply mean that the program could no longer talk to FSUIPC, which isn't really surprising if you'd closed P3D down! The program is evidently not noticing that P3D has closed. maybe try starting it using the {Programs] section in FSUIPC with a "CLOSE" or "KILL" keyowrd included? Pete

They don't change names. The name, email and key will be those you originally registered with and as notified per your SimMarket account. The same three fields apply thoughout the life of FSUIPC5, they won't change. Pete

The values were 8182 and (separately) 16384 for the two actions, and they would be Parameter fields for the relevant "custom control" number(s) you already know. Pete

Sorry, i should have been clearer. The full release is 5.14, but there's an interim update 5.141e, which is available (DLL replacement only) in the Updated Modules thread of the Download Links subforum above. That's where all my software is availalbe. Actually I misspoke when I implied 5.14 wasn't supported. it still is at present. But it is best when dealing with problems that both of us are using the same. Pete

Thank you Fred! Pete

Yes, but I did think it included both. If not, I'm sorry, I think more searching is needed. Maybe some good user will post a better link, or even supply the actual file(s). I'd then see if could host them here to make things easier in future. Getting in touch with Luis Damas would be a good idea -- I've sent him a PM. Pete

Unfortunately, it appears to be a 32-bit DLL. I've sent a PM to Luis Damas, the poster of the original link. Pete

Like what? A is the Stick and B is the Thottle. IDs 0 and 2. You must have had a third device at one time as there are assignmwents to a non-existent device 1. You have, so far, not bothered to provide the extra logging with the option I requested added to the INI file. Also you are still using FSUIPC version 5.14. Please update to the currently supported version. Then do that logging I asked for on Friday, and supply Log, INI and the Joyscan CSV file. Really your INI file is a bit messy. You have odd Profile names like " p3d" and "Prepar3d" which must be hard to differentiate, as well as "axc" and "CRJ900". I can't really analyse all of that, so, as a test, try moving that INI file out, or renaming it 9so you don't lose it), then let FSUIPC generate a fresh one. Pete

So, what's different from Friday? REally, that symptom is definitely indicative of a hardware problem with the throttle(s) themselves. It could just possibly be a conflict with something else affecting throttles -- you would need to Log axes and see what the axis inputs to the Si, look like. Logging Tab, axis events. Also log other events in case it is interference from another control altogether. Lookng at the INI file I see that FSUIPC is not actually involved in the Throttles. the assignments are to the same controls as if assigned in the Sim, and they are not calibrated at all. So FSUIPC is actually doing nothing different to P3D. Pete