Pete Dowson

The names for the controls are obtained from the "CONTROLS.DLL" in P3D, they are not built into FSUIPC. So it sounds as if something has corrupted your P3D installation. Either that or you are using a version of FSUIPC4 which pre-dates your version of P3D3. To eliminate this as a possibility make sure you are using the current supported versin -- 4.965. If this does not resove the issue, then show me the FSUIPC4.LOG file from the Modules folder. This is always needed for any support question. It is a text file and you can pasdte its contents into a message here. Pete

Absolutely none, because you still haven't provided any useful information whatsoever! I cannot deduce things magically! I ALWAYS need Log files as a minimum. Please do not post again without any information. And I've also no idea why you invaded a thread on a different subject. You should have started your own thread, as I said! Pete

Thanks. Yes, looks good. I'll investigate this puzzle, hopefully over the weekend. If not, certainly next week. Pete

But all that is handled by ProSim assignments, as you said, not FSUIPC. It is the pilot who introduces fuel (in a 737 is would be 25% N2), by using the Idle/Cutoff levers on the throttle quadrant. Those, in the sim, are dealt with by the micture value, FULL RICH to FULL LEAN. It is most definitely NOT a good idea to have them assigned in both places. They would both be trying to control those values in the sim and conflicting. Plug it in, get all the assignments sorted and working (in ONE placve, each), and NEVER remove it. Either that or ask Leo Bodnar to supply cards which Windows will recognise uniquely. BTW If the axes you've assigned and calibrated in FSUIPC don't work in the sim with ProSim NOT running and just the one card installed, this means that the sole program responsible for controlling those values in the Sim is ProSim, which makes more sense to me than both trying to do it. And also means you need to ask ProSim whether it can deal properly with two indistinguishable cards, unlike Windows (and in consequence FSUIPC) if you keep removing one. Maybe. You can check for that by swapping all the physical connections over between the two boards. The whole idea of GUIDs is that they are never identical. It's normally just that the ones that are being used are getting assigned to different of the two boards depending on which one Windows sees first. However, maybe the Registry can, in error, have identical GUIDs for more than one device recorded. That could play havoc and would need editing. I could advice doing a full hardware uninstall of both boards, via device manager, but I don't think that cleans up only entries in the registry, so could make things worse. You can't even easily search for specific GUIDs in the registry as they are actually in a binary format whichlooks nothing like how they are normally presented. If you'd like me to look at relevant parts of the registry, let me know, and I'll work out how to get them. It might mean running a little file which I wouldn't be able to send here, so that may involve email, but let me know. But i won't be able to deal with it until at least Saturday. Pete

The currently supported version is 4.965. Please update. Yes., of course. SetBits, Togglebits and Clrbits. Sorry. An error made due to pressure of work at the time. The door assignments in the Aircraft.CFG are incorrect then. The value x0F (or decimal 15) operates all possible doors, like sending 1,2,3,4 for the Ctr E keypress. I use combinations of these regularly, but I take care to check their definitions in each Aircraft.CFG I use. And it is odd that you are using "clrbits" for the one, but not its converse "setbits" for the other. If you want to use Set all the time, the parameter would be x0F (or actually x03 as we discover later) for opening and x00 for closing. But if you only want to deal with the first 2 defined doors, SetBits and ClrBits with parameter 3 (or x03) is better. For only two defined doors use x03 or just 3 in the original assignments above, then. Evidently doors 3 and 4 muck things up in your particular aircraft. In mine door 1 is for left passenger doors, for and aft, 2 handles the supply doors, on the right, fore and aft, and 3 and 4 are the cargo doors, fore and after respectively. These assignments can be changed in the aircraft.cfg file. Well, why did you remove it? Your previous version was okay but for some reason you replaced the = after the .1. etc with spaces! If you want to open or close them separately, of course. How else? The offset is a direct "open" OR "close" depending whether you set the bits or clear the bits. Toggle will open closed ones and close open ones. If you don't know how they were, surely that isn't want you want? Why else are you testing for W3367=0 above? FSUIPC is effectively doing that for you with the SetBits, except it doesn't really need to. it knows which doors are open or closed. You misunderstand and therefore miss the point. Writing directly to the offset to open or close doors removes your need entirely to have a condition. They are entirely unconditional. Setting opens the door, clearing closes it, no matter how it started. Pete

Can you see why the engines shut down? Is it because there's a mixture axis assigned on the other and the lack of one on the second card reads to turn it to cutoff? Why would you unplug and re-plug cards in. Can you nott leave all the connections connected so there's never a need for a rescan? So it is only flaps and speedbrake axes which don't work then? Neither of those can shut the engines down! ProSim has its own drivers to read the axes if you've assigned there -- they won't be assigned in FSUIPC as well, surely? They shouldn't be, just as they shouldn't be assigned in the sim. I think now that you may be in the wrong place altogether and need ProSim support instead. Pete

The FSUIPC Options dialogue, you mean? This problem is normally a video driver problem. Try using ALT+ENTER first to change the windowed mode. There have been some conflicts with other add-ons in the past. I don't know about the FSL A320, but certainly there are add-ons which seem to steal the message FSUIPC should receive to open up the options, or to prevent SimConnect switching to dialog mode. Pete

The latest FSUIPC is obtained in the normal places, of ocurse, on the Schiratti site pointed to by the SimMarket links, and here in the Download Links subforum. You should have started a new thread. Pete

Ah. That's interesting! Thanks. I'll have to look at exactly what the Installer is doing. It shouldn't have changed that part. Next week ... Pete

Right. Something is a bit odd then. I've got something to go on. It would be useful, please, to see the good log. I'll probasbly not be able to get to this till next week now. Grossly overladed at present, and in the meanwhile you are up and running ... Pete

Have you tried the one I gave you a link to yet? Please do that. If that one works better with your 3.3 I will alter the Installer to install that one instead. But as far as I know, the part of the interface I am using changed from 3.2. It was with 3.2 that problems were reported. 3.4 has the same interface as 3.2 as far as FSUIPC usage is concerned. If you try the older version and it works, then I know where to look. If it doesn't, it is a different problem. That was the point of me providing you the link! [LATER] Just saw the earlier message saying you'd tried it as requested! See my next message.

Yes, that version was withdrawn because of the Win10 bugs in the DirectX code. One day I hope to revisit that -- maybe MS will get around to fixing them one day. However, the subsequent releases to improve Joystick treatment were essentially building on the original code, just doing things in a different order, really. Without making an FSUIPC log file? If so, then FSUIPC was not even running. The log you posted above clearly shows successful Joystick device scans, but later shows: which is never recovered. It seems your version of P3D installed on Windows 10 is corrupt -- that message is returned by SimConnect on the attempt by FSUIPC to connect with it. I really don't know any other possible cause except corruption, You could try installing the FSX/SP2 or ACC version of SimConnect and removing the SimConnectP3D3.DLL file from the Modules folder. That might be a workaround. But I would have thought you could have problems in the future anyway with other SimConnect applications compiled specifically for P3D (as opposed to transported from FSX). Of you crash reports you submitted, this one is not at all related to FSUIPC. There's no .NET code associated with FSUIPC or the SimConnect interface it uses. The other one cites: which is the DLL I supply which uses the L-M supplied SimConnect library to interface directly into P3D's SimConnect -- the call it makes to start that process is the one failing repeatedly according to the log. You could also try going back to the P3D3.0 version of my SimConnectP3D3.DLL -- link SimConnectP3D30.zip just use that in the Modules folder instead of the SimConnectP3D3.DLL which is there. But if that works it really only confirms something is very wrong with the P3D installation, because it is only designed for 3.0-3.1. Things changed in 3.2 onwards which made that one crash. And I think that will be the most likely result -- a different crash, but a consistent one. If you do end up using it, remember to save it and reinstall it after any future FSUIPC update. In the end it might be much easier to perform a reinstalltion. You might only need to reinstall the client, which is pretty painless and avoids any reinstalling of other add-ons. Pete

You'd really be better off over in the CTD forum on AVSIM. This one is for support of my programs -- FSUIPC and WideFS particularly. But I can say that crashes in G3D.DLL are almost invariably due to corrupt scenery files. You need to check the scenery in action in the area you are flying at the time. Pete

with absolutely zero information provided I can't possibly help. Where's the log file? In what way doesn't is start? Is there a Windows crash log? There's no way I can guess these things. I have to have information to work from! There's no way anything to do with input devices will "crash" P3Dless you have a rogue device driver which would crash in any case. And FSUIPC's actions won't be any different for version 3.3.5 to any other version. The changes from version to version are to do with internals, direct access to P3D internal functions, and those for 3.3.5 would have been frozen ever since its release. Pete

Sorry, are you in the wrong place? Richard's contribution above was concerned with converting some MakeRunways files into a format which Excel could read. What "dump" or "apps" are you talking about? You give no context, nothing! The only "app" context here is MakeRunways, as must surely be clear from Richard's post. If you want support for any of my programs please post in the Support forum. I think you are in the wrong place. But when you post, please be much more epxlicit. Pete

I think the serial number on the later Bonar boards is effectively part of the chip, not a flahable iten. But I'm not sure. The assignments of GUIDs and therefore IDs shouldn't change, even for apparently completely identical cards, if they are both powered and both plugged in (to the same ports) every time you boot. I'm afraid the GUID is actually how FSUIPC has to access the devices. There's no other way I know with DirectInput, even if it could determine which was which. Getting Windows to always assign the same to each is the only way. Pete

Hmm. Strange. Maybe the parameter for the EXE must be included inside the quotes ("") after all, but that didn't work for you. I'll check into what is going on. Maybe the what I've implemented the facility doesn't support command-line parameters, but I'm sure they've been used before. I'll have to get back to you -- sorry, but due to other pressures it may not be till the weekend. [Later] I just checked. It should have worked the way to had it before. This is from the FSUIPC Advanced Users guide: I'm sure it used to work, and should now, but I'll check it here by or over the weekend. Pete

Aha! In that case it' might be the "" in the wrong place. Perhaps the line should be: RUN4=READY,CLOSE,C:\IVAO\"IvAp v2\ivap_dllhost.exe" C:\IVAO\IvAp v2\ivap_fsx.dll I just feed the stuff after the last comma to Windows. Maybe it was my fault earlier -- I put "" round the lot! If so, Sorry Simone. Please try the above. Pete

Why use a macro when you can do it by just button assignment, as it looks like you've done. Also, you don't need to use keypresses or offset conditions as you've done. Just use Offset byte set, clear or toggle, directly to the 3367 offset! You can combine bits too. For all doors open just assign to Offset byte set, offset x3367, parameter 15 (15 = all 4 possible doors) For all doors close use Offset byte clear, offset x3367, parameter 15 For individual doors just use parameters 1, 2, 4, 8 as appropriate. What happened to the = after the 1.1 etc reference? Please see page 40 in the Advanced Users guide. Of course you only need a one line macro if you write to the offset by Offset byte set. Pete

But if you can launch the program from a menu, you can surely launch it automatically. just find out what the menu item is doing. Launching a DLL is not possible, DLLs are LIBRARIES, not PROGRAMS, and cannot run by themselves! I keep telling you this and you ignore me! What "issue"? Not being able to run a library because a library isn't a program? What do you expect me to try? I don't use IVAP and know nothing about it. Why don't you ask on an IVAP site? t isn't anything to do with any of my software. You only need the proper program name. Pete

If you start IVAP manually, is that what you run? You can't run a DLL directly, at all. Whatever it is you use to start it (I assume you've used it before?) that is what you need to point to to get FSUIPC to start it. Basically it is only doing the same as you. Pete

The "SIM stopped" log entry is just a message it gets for SimConnect every time you go into a menu. It is not specifically relating to exiting the sim. Your problems don't look in any way related to FSUIPC. Pete

The message is appearing BECAUSE your FS is crashing, so FSUIPC becomes unavailable. The message is really littleto do with any of my software, it is one of your addons complaining that FSUIPC is no longer running -- one running the .NET Client DLL by the look of it. You need to find out why FS is crashing. Pete

If you really want to use controls for trim, checkout all the PMDG-supplied "custom controls" listed towards the end of the ".h" document included in the SDK folder of your PMDG 737NGX folder. You can assign to such controls in FSUIPC by using the <custom control> assignment and entering the number computed from that document. Pete

It changes nothing. As an unsigned number -50 IS 65486. Inside the computer where numbers are represented by binary bits, they are indistinguishable. How a collection of bits is used depends purely on how you define them to be used -- code or data, signed, unsigned, floating point, etc. It's all in the definition, and that parameter is defined to be unsigned, as documented. Pete