Pete Dowson

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

As well as what Thomas says, I would certainly be wondering how it suddenly became "unregistered", because Registration has nothing to do with version numbers -- version 4 is version 4, and that's what the Registration ties to. Regarding the Installer for an updated version, it sounds likely that your registry is in a mess. Have you been using a migration program to install things for P3D? They tend to mess things up such that Installers which do understand all these FS versions get misled. When you say "it keeps looking for FSXSE" what do you mean? It looks for each version of FS which in registered as installed, but it only checks once. It never "keeps looking". It just prompts you to point it to the correct folder and EXE file for any one of those if it cannot find it where the Registry points. If you want me to help with the installation problem, you need to show me the Install log, which is always produced by the Installer and which will contain the exact reasons for what you see. You can paste it complete into a message here. Pete

Ah, that explains it. (But what is "FI" ?) A one or two line lua plug-in for each button you want to assign would work too. You just put the Lua files into the Modules folder and assign the button to "Lua <mame of plugin>". For example, to click the left hand button: mouse.click(0) To scroll the wheel forward 1 click: mouse.wheel(1) To scroll the wheel back one click: mouse.wheel(-1) I think just moving the mouse makes the pointer show, so a couple of lines should do that without moving it far from its previous position: x, y = mouse.getpos() mouse.move(x+1, y+1) Lua plug-ins run internally to FS of course. Pete

I've analysed this as far as I can get. The place where it crashes in the version of API.DLL you are using (FSX/Accel) is deep in a small routine called in many places. Without a debug trace it's hopeless. tracking back up could take so many branches reaching the calling API function could take weeks. Not only that, but the code in my version of FSX (FSX-SE build 62615) is substantially different. So I'm not convinced it would even happen at all here assuming I had the aircraft in question. You should also note that this thread started which was a different crash altogether, though there was never any relevant data supplied. It was that one to which the aircraft's author was presumably referring in his response here, some time back. Quite honestly, the aircraft author is the person best placed to sort this out. If he does identify something FSUIPC is doing which explicitly somehow conflicts (only!) with his code, then I'll gladly look at resolving it as best I can from my end. [LATER] It's just occurred to me that the very last entry in both Logs you submitted end on the line ".PLN". Now this line should be giving the name of the flight plan which SimConnect tells FSUIPC has just been loaded. But it has no filename at all! Could this attempt to load, into FS, a flight plan with no name somehow crash API.DLL? I know that DLL is involved in interpreting flight plans. It seems to me that something you are doing, or the add-on is doing, may be attempting to load a plan which is causing that process to fail. Can you check the FSUIPC log from a run with new of the FSUIPC versions you say "works"? What are the lines shortly after the one saying "Advanced Weather Interface Enabled"? I just checked, and the second log posted by the thread starter also had this ".PLN" line in it: 354031 Advanced Weather Interface Enabled 653344 Sim stopped: average frame rate for last 301 secs = 6.0 fps 653344 Max AI traffic was 23 aircraft 653344 Average weather filter write interval in that time = 37677.8 msecs 944406 .PLN 969656 System time = 22/05/2016 20:41:16, Simulator time = 17:11:03 (15:11Z) 969656 *** FSUIPC log file being closed It was soon after that line that the sim closed down. No error, just a close. The user says he didn't close it! Pete

Strange. I've never had such a thing happen. There's always a reason given -- unless the user or another program has instructed Windows to restart. There's no such code in FSUIPC. No, I am saying no such thing. Except for the remote possibility that something has actually instructed Windows to restart, I was saying that only software with driver-level privileges can cause a crash which make Windows restart. Nor I, because it cannot, and it cannot be anything to do with FSUIPC. However, everything in the FSUIPC Settings dialogue is handled by standard Windows dialogue libraries, and of course the changes on screen are handled by a video driver. I think you need to go through a process of elimination. Start by doing things without the PMDG aircraft running. Don't have anything else running apart from FS + FSUIPC. See if that still does it. If not, add things back bit by bit. Yes, exactly. I'm surprised you've not set up any generic controls already, really. You should make profile specific settings as and when you find you need them, and you can then always base them on the settings you already have. Note that some bits of some of this add-ons are probably still running even when you are not using their aircraft. I know this happens with the PMDG stuff. So we might need to take further steps. But try the easy way first. Pete

Yes, but I needed the crash data and Log for the same event. The main use of the Log is for the "Module base" and the versions of each of the FS Modules linked to. C0000005 is an access violation. I described why this is proably happening earlier. I think something in the Add-On aircraft code is using an incorrect, unchecked or uninitialised pointer. I'll see if I can track which action in API is being used when it crashed, but I don't offer much hope. We'd really need a stack trace, and that would mean running it under a debugger. If the API crash is so easy to reproduce I'm amazed the add-on author hasn't done this already! I don't have the aircraft and I'm not going to buy it to find a problem in someone else's code. Pete

Where are you looking in FSUIPC's options? You need to be more specific. The assignment of axes is done in the "Axis Assignment" tab. If that is where you are looking, and there is no response, then your joystick device is not correctly registered in Windows. Is it a Saitek by any chance? Because their installers seem pretty bad. If this is the case, please check the FAQ subforum -- the thread "fixing joystick connections not seen by fsuipc/" is relevant. But I should also ask -- why are you wanting to assign in FSUIPC? You do know you can calibrate joysticks in FSUIPC without assigning there. You can leave them assigned in FS. The most usual reason for wanting to assign in FSUIPC is for more flexibility, especially being able to create profiles for different aircraft using different controls for different aircraft types -- stick or yoke, for example. Pete

Well you certainly need to adjust that. Even during takeoff and climb they'd be a lot quieter from the cockpit. There will be parameters controlling the engine volume levels, maybe in your aircraft's "Sound.CFG"? But the engine sound is so diminished in the cockpit that you'd probably need Superman's hearing to tell the difference, especially over all the wind noise. That's possibly true, but then your previous paragraphs are rather irrelevant, aren't they? Any way, even with airframe transmitted sounds, I think you'd find that, in the cockpit (not necessarily in the passenger cabin of course) ,the wind noise overshadows all that. Pete