Pete Dowson

No, that couldn't possible cause such a problem. It would simply result in two probably different axis values being received by P3D and show up as jitter or erratic movement. Only something of driver status could had had the effect you experienced, and I expect the actions Thomas recommended did the trick. Pete

Only with a huge amount of work and very likely introducing lots of errors. It was at least a 4-6 week job back then, plus weeks of testing and debugging, and I was younger and more intelligent back then. I'm 73 and have now forgotten it all and getting more stupid daily, so would effectively have to start again from scratch. I'm really not willing to risk the stability of FSUIPC and its future to do it I'm afraid. The whole reason for implementing Lua into FSUIPC at the time was so I can avoid major programming in a future where I knew I would not want to get into such nitty gritty, allowing others to implement new features. I think it would be quicker and more reliable for you to learn more, and take the source of the module you need and rework it to fit with FSUIPC's Lua module interface. You have a good start as you seem to understand socket programming, which is more than I do. But this is exactly what your Require is doing, trying to load the library you have. It is exactly what happens with other external libraries, sch as saitek.dll for Saitek devices, gd.dll for graphics, luacom.dll for COM component access. It should do the same for your renamed socket DLL, but there's a linkage problem, the export needed to get the module to provide it's list of contained functions is not being seen or is declared differently. I did offer to look at it, to see if I can identify why. Pete

If they are all in the same workgroup, as you say, then the problem must be the firewall. Try disabling it. When you have any problems with my programs it is always useful to show the relevant log files, as these may contain the details which help diagnose the problems. The relevant files in this case are the WideClient.LOG from one of the Clients and the WideServer.LOG from the Server. You can paste these text files into messages here, using the <> button above the edit area. Pete

Seems that the dependency issue to removed at least. But the problem now won't be VS libraries. The error it refers to is a procedure the Lua 5.1. version I have built into FSUIPC-needs to call not being found, or not exported, within the module. Now this is not done by any code I understand. The loading of external modules seems to use one of a variety of loaders, being called via very dense Lua code which is beyond me. However, I think the gist of it will be that the module you've managed to build is not loadable by any of the loaders built into the version of 5.1.I used. Possibly a difference between 5.1 and 5.1.4? I don't know. The package I used dates from not long after 5.1 was first released in 2006. When was 5.1.4 released? FSUIPC's Lua is able to load external modules successfully -- there are other examples which work fine, and folks have managed to build and compile their own okay. So I'm lost here really. If you'd like to ZIP the module you've built and send it to me at petedowson@btconnect.com I could take a look with a Debugger and work out why it is wrong, but I cannot guarantee to fix it. Pete

This business of modules (DLLs) which are obviously present not being loaded with the error "not found" is annoying. It took me ages to find out what the problem was with my SimConnectP3D2.DLL when used with P3Dv3, but only on PCs which had never had previous versions nor FSX installed. It was because of dependencies in the DLL on libraries which were not installed. The "not found" message appears to mean not only "this file isn't found" but also "though this file is found it cannot be loaded because it is dependent on other files not found". There is a DEPENDS utility (http://dependencywalker.com/) which helped me work this out. Maybe you could check? I got around it for my modules by compiling a new one using the P3D3 SimConnect.lib which was dependent on the same libraries as P3D3 itself. If this is the problem your new sockets module has, maybe the source is available and it can be recompiled with a different library set? Or, maybe easier, install the needed VS run-times. FSUIPC, and its built-in Lua parts, is not dependent on any external libraries other than the standard Windows ones. I made sure of that long ago so that I could have one version which applied to FSX, FSX-SE (again different libraries), and all the P3D versions (so far -- obviously a new version would be required for any future 64-bit one). These changes happened because of moves through from VS2005, VS2008, VS2010 and (so far) VS2013. I expect they'll be using VS2015 soon. Each of these has different language libraries. If this isn't the problem I'm afraid I'm lost. As I said earlier, sockets are a puzzle to me in any case. Pete

Do the Clients and the Server have the same Workgroup name set in Windows? If not then the automatic connection cannot work. Windows 7 uses a different default Workgroup name to WinXP and 98. Broadcasting won't work across different workgroups. You can either change the name, or specify the ServerName or ServerIPAddress and the Protocol in each WideClient INI file. This latter way, the Client knows where to connect to without needing a Broadcast. This is all in the WideFS user documentation, which perhaps you could refer to? If this isn't the cause of the problem, then it's the default Win7 Firewall. Pete

Glad it solved your problem! Pete

Oh dear! This time you posted into the User Contributions subforum. It is not a "contribution". If you want answers, support, etc, please always post here, into the Support Forum! You are lucky I noticed your post! Did you not see the "REV" checkbox in the calibrations tab? It is also documented in the User Guide of course! If you use this option you should check it before calibrating, so if you've already done that I suggest you press the "RESET" for each such axis, then Set, then the REV option, then calibrate again. Pete

Thanks for the information. I note that the very first thing on that page is a link back to the one I'm using: "Network support for the Lua language http://www.impa.br/~diego/software/luasocket" Good luck! Pete

You never need to do any preparation when updating FSUIPC. If your registry still needs fixing and the Installer tells you, just select "Fix". Pete

Yes, exactly. And that's exactly what you want to happen if you are assigning in FSUIPC. It should be all one or all the other. I assume you mean Throttle 1 and Throttle 2! And it still worked okay in a PMDG aircraft? Everyone else says that doesn't work in the NGX -- it gets its Throttle inputs direct only from the AXIS THROTTLEn SET controls. The lower priority input from FSUIPC causes conflict -- or at least that's what others tell me. I don't use any PMDG aircraft. Most of the stuff in PMDG aircraft needs different methods altogether. They have actually implemented a complete set of numbered controls, which are assigned in FSUIPC via the <custom control> selection. I think the list is at the end of the ".h" file in their SDK folder. alternatively there are probably keystrokes you can assign, but i don't know. Pete

Glad it was really an easy one, though appearing so strange at first! Pete

I've released FSUIPC 4.954e, inside an Installer which has the improved "bad Registry path" handling in the way I just described above. It's available in the Download Links subforum, and it's now the official version from the Schiratti site. Pete

It really cannot be FSUIPC. If it occurs with FSUIPC but not without it will be because of something using FSUIPC. To start with I see you use LINDA. Try without that to start with. Also I see that EZCA is only loaded when FSUIPC is running, so try without that too. And try EZCA separately. You are making the mistake of narrowing this down to FSUIPC without considering everything else you have going on. Check all those other things, as I am telling you that there is no way FSUIPC alone can produce the effect you see. You also say But that is not actually true. You might not be able to do it in the Dialogue, but an erroneous entry in the INI could do it, and it can be done by third party add-ons. Also it isn't necessarily the assignment of ESC to a control which does it, but assignment of anything to a keystroke. Pete

You never need to delete assignments in the Sim. You should, however, DISABLE CONTROLLERS in the Sim. That is much more important! What controls did you assign to, exactly (the names in the drop-down list), and in the calibration did you set null zones or response slopes or something? Don't use the Filter option unless you have really terribly jerky controls, that will introduce a lag. But otherwise there should be no lag at all. In fact if you assign "Direct to FSUIPC Calibration" it bypasses a lot of stuff in the Sim and acts very efficiently indeed. However, you cannot use that method with some add-on aircraft, especially PMDG ones (but also those don't like you even calibrating in FSUIPC, because they take the control inputs at the same level as FSUIPC).. Pete

Hmm. You should not really have done that. Just bypass it by exiting from the attempt to find V1. It will carry on to the next -- it has already built the list of versions it will be looking for in the first part, from the Registry. Only the second part involves actually going and finding them for real. Hmm. I see no way in the code for it to bypass that message. The v2 and v3 installation confirmations would have occurred rapidly immediately after the problem because of the v1 registry error. I have FSX, P3Dv2 and P3Dv3 all installed here on my test PC. I deliberately added the entry you have into the Registry, for v1 and ran the Installer. I pointed it to P3Dv3 for v1 and it worked here as it did for you. If you then told to to go ahead and fix" the Registry, it might not have changed your HKEY_CURRENT_USER\SOFTWARE\LockheedMartin\Prepar3D Parameter"AppPath" to point to Prepar3D 3, but possibly added this instead: HKEY_LOCAL_MACHINE\SOFTWARE\LockheedMartin\Prepar3D Parameter"SetupPath" So, if you did that and have since deleted the former, you should go and delete the latter one too. There was also the error that it couldn't install FSUIPC into the DLL.XML file as you did (" Cannot edit the DLL.XML file to activate FSUIPC." ), and once I'd got past all that it reported Installed okay for P3Dv2 and the for P3Dv3. They would have both been very quickly done after the error messages. I think you must have missed one or misread it. I think I might add some extra sophistication to the Installer. When it can't find the desired folder, instead of going directly into getting the user to find the EXE, prompt saying something like If this version is installed, press "Find" so you can point the Installer to the correct location. If it is no longer installed, you can select "Fix" instead to remove the erroneous entry from the Registry. Or to bypass all this entirely and ignore this version, select "Bypass". with the three buttons Find, Fix and Bypass. Pete

Details are in the Lua PDF in FSUIPC Documents. To quote: In addition to the built-in libraries, full LuaSockets support has been included, with all the major modules also built in. This is a package by Diego Nehab, and thanks are due to him. For reference data and the full package, go to http://www.tecgraf.puc-rio.br/~diego/professional/luasocket/ I don't know if that's been updated since I first added Lua (towards the end of 2007 -- at the time the Lua version was 5.1 and that is what is built in as well -- as also stated in the documents.. Maybe, if you need the later one you can use the modules externally? You might need to rename them from "Sockets" as else the "Require" for sockets will no doubt choose the one already loaded. [LATER] I've just looked at the website linked above, and it seems to still be the same version there, quote " LuaSocket version 2.0.2 is now available for download! It is compatible with Lua 5.1". The authors copyright date above is 2004-2007. I see the current version of Lua on the main Lua site is 5.3.2. I'd rather stick with 5.1 because most of the available books for Lua are 5.1 oriented, and it;s a LOT of error-prone work building the stuff into FSUIPC so it works smoothly in that threaded environment Pete

Do these things happen with other aircraft? Is it only with PMDG? PMDG aircraft are continually sending controls to FS, all the time, and very fast. I wonder if there's something caused by that? There is no way anything in FSUIPC affects keyboard use outside of the simulator. It isn't possible, because when the sim hasn't got the focus it doesn't see any of the keyboard inputs. Press the control key and release it. If the Control was pressed and not seen to be released, the system may just be waiting for a "keyup". But unless you've been making assignments to keypresses, nothing will be doing this in the first place. Having axis assignments in both places, even if they do not (currently) seem to conflict, is NOT a good idea. You can still assign everything in FSUIPC -- for exactly the same effect as assigning in P3D. Just assign to the regular Axis .... controls and don't calibrate in FSUIPC. What FS and the 737 sees then is indistinguishable from what they'd see with P3D assignment. Pete

I'm afraid I don't know Lua's socket library well enough to help here. Not only that, I don't really know a lot about sockets and don't understand much of your post. The stuff built into FSUIPC, augmented by the separate parts provided, is all directly from the Lua stuff freely available. If you can get it working independently, with the Lua run-time setup, then it should work identically in FSUIPC. FSUIPC's WideServer does have an optional Broadcast mode with UDP for transmission of data to multiple clients, useful when most want the same data in any case, but I've looked at that code and I don't really understand it now even though I did write it myself. Most of my Network code is derived or even straight copied from MS examples. I think I'm also getting senile. :-( The other broadcasting used by WideServer to broadcast its name, ip Address and protocol uses the Windows "MailShot" facility, which is easier to understand and works well. Pete

I cannot tell what is going on without the Installer log -- one is always produced by the Installer, and contains all the details about what it found and didn't find in the Registry. Please find that and paste its contents complete here. Pete

No idea, sorry. FS9 weather control was always precarious at best, and the code doing this stuff is a good 12 years old. Have you tried turning pressure smoothing off? You might want to ask FSRealWX folks too. I'm afraid I don't know that program. Pete

I just get the former one. Sounds like you have something else also processing ESCape, maybe via FSUIPC. FSUIPC doesn't. It isn't aware of what you are doing till it gets a notification that it should close down. Whenever asking for FSUIPC support, please state the FSUIPC version nmber and paste the relevant FSUIPC4.LOG file from the Modules folder. Pete

Sorry, t doesn't really help. Pete

You payment covers ALL versions 3.xxx. You are expected to keep up to date in oder to receive support as old versions cannot be supported. Where do you mean by "market store"? If you mean SimMarket, they don't supply the program, they just give you a link which takes you to the ZIP file which is actually hosted here, in the Download Links subforum. It currently links to an FSUIPC.ZIP containing FSUIPC 3.999z9b Changes.pdf Install FSUIPC.exe Installing and Registering FSUIPC.pdf That installer program installs version 3.999z9b. I suspect you've installed some other old add-on which still overwrites newer versionso of FSUIPC (and possibly other things) with ancient versions which may have been current that many years ago, when your add-on was released. You'll need to run the Installer you downloaded again. Pete

The only supported version 3 is 3.999, and this has been the case for over 4 years now! Version 3.48 dates back to April 2005, more than 11 years ago! There have been at least 15 major releases since then and many minor ones! Until you update I'm afraid I cannot offer you any support. Pete