Pete Dowson

So you are running ProSim on the P3D PC, but have your axes on a client PC. Seems like a problem with that 'Hardware connector" module. I've not used that. i've always made sure all my axes are connected to the main server PC. WideFS will transmit button presses to FSUIPC for assignment, but not axes. It can be done via a Lua plug-in, using the COM library to read the USB device directly and writing the values to a user offset. Then using my freeware "vJoyOffsets" to make the offsets operate virtual joystick axes which will be seen by ProSim as normal axes. Or you can actually make ProSim read the offsets for the axis values directly. The problem with this is that there might be too much latency (i.e. a delayed response), so I can't really recommend it. To avoid the delays inherent with a Lua plug-in you could write a program to do the joystick reading and writing to offsets. The possible delays over the network is the reason WideFS only implements client buttons, not axes, though since that design the speed of most folks' networks is easily enough to cope with minimum latency, so it would be a worthwhile future enhancement (but would need some serious changes in FSUIPC to cope). If Prosim support really can't resolve your problem, it might be worth running the Prosim program and MCP on the Client. I had mine configured that way originally, only changing it when upgrading my main server considerably. The only problem i ever saw with that original arrangement was the slight loss of control by the A/P when using x2 time rate in P3D, and complete loss of control at x4. Pete

How does the Server PC (the one running P3D) 'see' the joystick on the Client? Where do you see this happening? Pete

If you have no assignments in FSUIPC then FSUIPC is not doing this. FSUIPC is simply logging what it sees occurring. If you genuinely have no assignments in P3D either, then it is an add-on doing it, so stop all add-ons including ProSim. Do this one at a time to find which is doing it. Pete

No! writeUB will set the VALUE, not the BITS! Use setbitsUB to set the bits, with those variables, as I said!! Pete

Sorry, no, there's no such GPS controls at all provided via the SimConnect interface which FSUIPC is using. The only GPS controls are those which you can assign to operate the GPS buttons (see the List of Controls document). There may be a way withing the "PDK", an advanced lower level set of interfaces available only internally, but I don't know this at present. In any case this would only be applicable to P3D4, nothing earlier. You mentioned the FMC for this, so are you talking about an add-on aircraft? Those with their own autopilots will be following the route without programming a route on the default GPS. Pete

FSUIPC's axis assignmnet tab shows the values received from Windows DirectInput. FSUIPC does not manipuate these in any way. If they are "cut off" it is Windows which is doing it. I suggest a full uninstall of the device in Device Manager, including any driver software, and a re-boot of the PC. I think the RAW button needs to be set BEFORE making an assignment. Just remove the assignment and try again. However, RAW mode still uses DirectInput. It simply tells Windows not to use its calibration. There's been no change in FSUIPC to make a difference. It must be something in your new install of Windows. Pete

If you want the byte in 5400 to contain a different integer depending on those doorflags then you should use "ipc.writeUB". Your code using "ipc.setbitsUB" will OR bits in on each use. For instance, if all 7 doorflags are set the result in 5400 with your code will just be '7'. It looks really as if you want a different bit to be set in 5400 for each doorflag. In that case the values should be 1, 2, 4, 8, 16, 32 and 64. Just remember: "setbits" means set the bits in the supplied value, OR'ing them into whatever is there. "clearbits" does trhe reverse, removing those bits (i.e. changing them to zero). This method can set and clear mutiple bits in one instruction. You seem to be thinkning that the functions use bit numbers (0-7) which it does not. Pete

I think you need to compute that from the difference between Lat/Lon positions -- i.e. a bit of spherical trigonometry. There are formulae for such calculations on the web (try Google). Of course if it isn't the straight line distance you'd need to sum all the inidividual distances. If the recordings are made at short enough intervals, or the aircraft is moving slowly enough, more simple formulae could be used assuming a flat surface instead of curved. I don't know but I rather doubt that GPSdistance is what you seek. Pete

There is certainly nothing wrong with the version we supply to all through our regular hosts. As I said, I need the Install log from the FAILED attempt. And I need to know what version it is you found on that site. No one else is supposed to host it, and using out-of-date versions is not supported! There's no way we can identify and fix problems with the zero information you've actually supplied so far. Pete

What's an "ON-ON" switch? Surely it must have an OFF position? If you mean the difference between a button which when pressed is on, when released is off, or a similar spring-loaded switch, and a latching toggle, then it depends. You need to examine a realy overhead panel, or maybe the one in the NGX. The battery switch is definitely a simple latching toggle. it is either on or off. It doesn't change by itelf. The APU switch is the 3 position switch with one position spring. so it of OFF / ON / START with the start sprung to centre. I can't really help you specifically with PMDG producrs. You need to go to the PMDG forums for that. But your switches should first be at least close to what the real NG uses. If you are not going to use any rotaries how are you going to manage tohse switches needing rotaries, like the Landing and Cruiseing altitude settings on the Pressurisation module? The switches for the electrical display are multi-position of course. and many others are three position. Pete

RC4 doesn't use the FSX/ P3D menu facility. It's menus are sent to FSUIPC as a basic text display, not a menu. FSUIPC just sees a new text string (all lines are in the one string) and that it sent to the normal text interception as a change. The only way to see if the menu below this is the same would you be skip the first line (skip to the characters after the next line feed or return character). Pete

Registration is always via the Installer. The message that the version is installed is just a confirmation that the Installer doesn't need to change it. It then continues to the Registration options, which evidently you by-passed originally. First off, make sure you are using the very latest Installer -- download it again just in case. You can get it from FSUIPC.COM or in the Download Links subforum above. Then don't forget to run it "as administrator" as it says in the instructions provided. If you then still have a problem you need to post here, in a message, the contents of the Install FSUIPC4 log file, which you will find i the same folder as the Installer EXE you just ran. BTW, I moved your support question from the FAQ reference subforum to here, the Support Forum, so it could be answered. Pete

Localisers aren't like regular VORs. They either activate your needle or they don't. There are several ways to detect this -- see the offsets from 0C48 to 0C70. Once determined that it is a LOC not a VOR (see code flag bit 2^7 in offsets 0C4D and 0C70) the sure indication of detection for a needle signal is the 256 seen in offset 0C52 or 0C62. (for NAV1 or NAV2) But really there's a superfluity of information there for you to use, so there are many ways from which you can choose. Pete

In FSUIPC you can assign a button to send a key press. It's in the User documentation. Pete

FSUIPC3 doesn't work in FSX or FSX-SE. FSUIPC3 is for FS9 and before. So it seems you were NOT changing from FSX to FSX-SE as you said, but from FS9 to FSX-SE. FSUIPC4 needs a new registration. if you want all of its facilities you need to buy it! If you already purchased it then you need to use the FSUIPC4 registration information you got from SimMarket, not the registration for FSUIPC3! Pete

I can't check your Client code for you (I am not familiar with Paul's work), but have you tried checking those L:Vars with either the FSUIPC list LVar control, or viewing changes live using the Log LVars lua plug-in provided in the Lua Examples ZIP in the FSUIPC Documents subfolder? That might at least show if it's the code or something else. Also, you need to make sure you are using the current FSUIPC5 release, 5.153, because before that the limit on L:Var name lengths was 32. Yours are longer than that. The limit was increased to 64 in 5.153, released last month. I know this was specifically for macros, but it may affect the offset being used in the programming interface. Pete

If you are using the correct details (name, email AND key), then it will not fail. Nothing has changed in this since you purchased it in 2016! The message about it being not overwritten just means that you already have the correct version installed. Don't worry about that -- it means it is okay. Pete

This sounds as if you are running FS2004 "as administrator" (i.e. with elevated privileges), but trying to get programs to talk to it which are running normally. If you must run FS2004 in such a way then you will have to run all of the FSUIPC applications with the same privileges. Pete

There's no need to uninstall unless you want to stop using it, in which case the easiest thing to do is just delete it. I'm pretty sure there's a section in the documentation about this. The installer is not dependent upon it being "uninstalled" first. You just run the Installer as administrator. How does "it" stop you running the Installer. Sorry, but you have to be more specific. Do you get an error message at all when trying to do it? BTW, you posted your question into the "FAQ" subform, which is for reference, not support. I have moved it for you. Pete

Can you try the same assignment in P3D to see if it works okay then? because all FSUIPC will be doing is sending the same control. It may be that that aircraft has its own Spoiler Arm system which doesn't use the built-in system. You might want to ask in the FSLABs subbort forum. The other thing to check is if you have a spoiler/speedbrake lever assigned which might be having a contrary affect. Pete

So, you already had FSUIPC installed, and the same or later version. You don't specify the path, FSUIPC's installer works it out for you! Why? If you already have an existing registration, as you have an existing FSUIPC installation, you could simply click "Not now" as it says in the instructions and it would use your existing registration. Ah, so you were NOT updating from FSX to FSX-SE, but from FS9? FSUIPC3 is for FS9 and is a different product to FSUIPC4. If you've not purchased FSUIPC4 that's now what you need to do! Pete

I think you need to show me the two INI files, the one from when you say it was okay and the one from now. and i still do really need version numbers, please. Pete

Of course, because that's what you wrote to it. Only if you select "RAW". see this part of the explanation about those offsets: Note that by default FSUIPC assumes that the normal input here is in the range 0–127, and scales it accordingly. For applications supplying a greater range, possibly up to the maximum allowed for joysticks (–1 6383 to +16383) you can either use the “RAW” option, or, better, let FSUIPC adjust its scaling to suit the range being input. It will adjust this automatically upon seeing the extreme values, or you can preset the scaling using a parameter added to the axis assignments line in the INI file. But 16384 is the maximum possible value for an axis! Your +22000 seems to be an uncalibrated input. Unless you use RAW you need to operate the axis a few times to let the auto-scaling operate. Is that with an identical FSUIPC INI file? If so then there's something odd, because nothing in FSUIPC has been changed in that area. Could you confirm what version numbers you were using, both in P3D3 and P3D4? Pete

That's a bit like "brushing the problems under the carpet". I'd look to getting it solved first, being it in the A320 code or not.

FSUIPC is reading all those SimVars in order to populate the offsets, just in case something wants to read them. It's really part of its basic function. Pete