Pete Dowson

Hi folks, Sorry, there was a silly error of signs in this enhancement in 4.84: I'm fixing it now. Get version 4.844 later today. Regards Pete

See where it says "FS2k only", and see this confirmed in the two columns on the right of the entry showing "No" for FS2002 and "No" for FS2004? This do actually mean that this offset hasn't been usable since FS2000. You'd need to use 3168 (or 3068 if you want aircraft-relative axes). Regards Pete

What is wrong with the normal offsets for these valees? Regards Pete

PMDG only provide information read-outs in their data, not controls. he flaps control is a control sent to FS, assigned to your flaps lever. Use the FS flaps controls, as usual. What do you use for other aircraft? Where do "servos" come in when operating flaps? Regards Pete

Did you lose your files? Have you now installed an out of date version of FSUIPC? Nothing I know in a normal Windows roll-back will change FSUIPC or the files you've placed in the Modules folder, but if it did delete your macro file I'm afraid I cannot find it for you. Pete

1. WideFS does not work at all unless you register it with your product key! 2. There is no specific insdtallation for WideFS. The Server is added to the FS Modules folder (for FS9 and before) or already incorporated into FSUIPC4 (for FSX), and the client program, WideClient.exe is simply placed on your clients wherever you want. 3. WideClient will reconnect automatically when it sees FS again. You give no information about how you are detecting the lack of reconnection, but maybe it is the applications which have the difficulty, not the Client? Without more information I cannot help further. You need to provide version numbers of FSUIPC, WideClient, plus the WideServer and WideClient log files. Regards Pete

But it does work in both CFS1 and 2. It was only CFS3 where it was not possible. Your previous version must have been many years out of date becayse FSUIPC3 has come with an automatic installer now for about 5 years or so. Not possible, version 4 is for FSX and later only. It would cause many application programs to fail. This has never been reported before, and it did not happen here last time I checked. Furthermore, there is nothing in FSUIPC which touches views and so on unless programmeed to do so. However, I will re-check whwn I get a chance. Again it worked fine here last time I tested it. Instead of complaining that the installer is a bad idea and that the website is wrong in its claims, why not try actually reporting your problems as problems, with information, so they can be investigated and sorted? I will re-check here when I get a chance -- but it may be a couple of weeks time now as I am only back for a few days between holidays. [LATER] I just tested the latest, 3.999v, in FS2002 and cannot get anything to go wrong, so without more information on that I can't help much. It'll take longer with FS2000, FS98, CFS1 and CFS2 because i deleted them earlier this year through lack of disk space. I'll go search for the install disks.and put them on a USB stick. BTW i don't much mind if you stick with older versions provided you never ask for any support for them. That and new facilities or fixes is all that you'd miss. But the installer will try to keep folks up-to-date -- that's the reason. I assume folks update because they need the new features or fixes or some support. Pete

If "VAS FMS" uses FSUIPC to talk to FS then it should work the same over WideFS. But don't forget that some add-on aircraft do not use the standard FS autopilot. You don't mention which aircraft you use. Sorry, I don't understand. But maybe you just mean it doesn't work with some aircraft? It is probably only designed to work with the default aircraft A/P. It sounds like the aircraft you are using has the default autothrttle but its own autopilot. You can of course assign MCP knobs and switches in FSUIPC, but I doubt whether thsi VAS FMS program is compatible with such add-on aircraft. Regards Pete

It isn't really possible in FSX due to the different way SimConnect handles the weather. Additionally the ground effects do seem a bit better than in FS9. FSX was left partially developed. Facilities needed in SimConnect were promised but never fulfilled before MS shut down developments. Sorry, Pete

Why not look at it? Pete

There's no way I know it will do that unless: (a ) the registry tells the Installer that your FSX installtion in in your documents folder, and (b ) it actually finds FSX.EXE in that installation path. If you still think it is wrong, please paste the Install log file contents into a message here. Pete

That latter number and name refers to an assignable command (also known as a control or key event) TO FS, not something you read from it. It is assignable in FSUIPC and in FS. Pete

Have you enabled the mouse look facility in the FSUIPC options? Are you holding the space down? If so it'll be toggling on and off. you know you can simply hold the middle button/wheel down instead? Pete

I'm rather surprised you'd prefer the cheaper less professional feel of a GF throttle unit to the superior quality of the PFC one. Not easily. I think it looks like a Game Port (so you'd need an adapter in any case), but I'm not sure it is directly compatible without some rewiring in the plug. I'd suggest keeping the FC throttle unit. I'm away now till next Tuesday (7th). Regards Pete

"Clearing out" the FSX.CFG isn't really the answer. FSX makes default assignments, drawing them from a set of "defaults" files. The only sure way to prevent assignments in FSX is to use the settings dialogue option to disable controllers. It was the same in FS9. No! More confusion! :sad: The D15 plug would be a game port plug, and that is on your FlightLink device, you said. If you are using my PFC driver with the PFC device then it is most certainly a serial port device! Yes, definitely ... for ALL devices handled by Windows drivers -- otherwise you start off with bad values. FSUIPC and FSX both read joysticks through the Windows drivers!!!! This doesn't apply to the serial-connected PFC devices because they are NOT handled by Windows drivers in any case, only by my PFC driver. After today I'm away till Tuesday 7th August. Regards Pete

Aha! Not any old serial port devices, then, but PFC digital protocol devices! That's a completely different matter. The PFC driver is interpreting the serial data. Hmm. I don't know of any way you can get cross-interference from separate devices, and especially separate devices with separate drivers, UNLESS there's some mlutiple assignments going on, possibly ones you aren't aware of. Pretty much all cases like that have been down to such a mix up. Again, that is nothing like you seemed to describe earlier. The device is evidently a bona fide USB joystick type device as far as Windows is concerned. That's okay, but FSUIPC is reading them via the Windows joystick driver, so they need setting up correctly there first. All FSUIPC would be doing is handling assignments and final calibration instead of letting FSX do that. Sorry, now it gets confusing again. Are you saying you CAN set up the FlightLink devices via Windows and you can assign them in FSX, but not in FSUIPC? That makes no sense as FSUIPC is using the exact same Windows functions as FSX -- UNLESS Windows is assigning them a joystick ID or more than 15. FSUIPC can only handle joystick devices 0 to 15. But, since Windows assigns these IDs sequentially according to the number connected, I cannot imagine that number being exceeded. I've never known it happen. How can you do that when it is already USB? If you bypass the FlightLink device which is making it look like a joystick what will it look like? What will recognise it? But HOLD ON. "DB15"? Do you mean Game Port? That's not a normal serial device at all -- serial COM ports are DB25 or DB9. The DB15 connector is the classic Game Port device. You might just need a USB Game Port adapter! (Game Ports disappeared from most PCs before Serial ports did -- though there are still some motherboards with a Game Port header present. If yours has one you can just get a Game Port socket to mount on the rear and connect it to the header. But take care. real Game Ports may still be recognised as joysticks under Windows XP, or not. Less sure still about Windows 7. Regards Pete

There's never been any possiiblity of a "generic" serial port interface in any case, as there has never been a standard for such devices to follow. The same could apply to USB devices too. There are certain laid-down standards for USB devices to adhere to if they are to be recognised without their own specialised drivers. These classify USB devices into things like storage devices (USB sticks and hard disks) and HIDs (Human Interface Devices) of which Keyboards , Mice and Joysticks are standard, but others may do their own thing (like GoFlight devices other than their throttle quadrants). FSX merely uses the standard Windows drivers for keyboard, mouse and joysticks. A serial port driver can make serial port devices look like one of those, but it would be specific to that device. The Windows drivers for known types of USB devices can be generic only because the defined standards for those devices lay down strict rules. That never was the case for serial port devices in general. Pete

Some cheap USB-Serial converters are okay, but many are unreliable. I use BrainBoxes serial port cards. You can get them in PCI or PCI-Express format, and they work very well indeed. But whatever you use, the devices are still serial port devices. All the USB connection is doing in these cases is emulating a new COM port. There's absolutely no reason that a serial interface won't work except for lack of software that understands the particular device! Unlike standard "joystick" devices, which have to abide by a particular protocol to be recognised as such, serial port devices all do their own thing at the whim of the hardware or firmware designer. There's no doubt that your serial devices will work with the correct driver, made specifically to understand what they send to the PC. I don't understand how the devices were acquired without their driving software, but I would have thought the first step would have been to search for such drivers if you have a clear identifier and make for the devices. What i don't understand, from what's been said here so far, is how he got anything from the serial devices recognised at all without some software installed to read them. Looking back, he said So, how on Earth were ANY values at all getting into FSUIPC from the serial devices? You must surely have had some software reading those devices! Regards Pete

If it only works on COM1 that's probably a restriction in their OnTop software, not in the hardware as it isn't aware of its PC connection number. Only if the hardware is designed to work using the PFC serial port protocol, which seems very unlikely to me. You should have asked them about the protocol too. The PFCFSX.DLL is another of my modules, like FSUIPC which you seem to already have found -- you'll find the PFC modules in the same places. In fact I told you explicitly where to find them in an earlier message here, two days ago. Documentation is included and tells you what to do with it. Pete

I'm afraid multi-position switches are not really well suited to those controls which only operate with INC and DEC. The only way to be sure of synchronisation is to always make sure you do enough "INCS" to reach one known end position (or "DECs" to reach the other, whichever is nearest), then the correct number in the opposite way to get to the desired position. It would be better to see if there's an alternative way, one where you can send a control with a parameter number to do the specific selection. Have you considered changing the switch to a rotary encoder, one which sends one button pulse one way and a different one the other way? They are ideally suited to INC/DEC situations. Regards Pete

How is the serial connection working through ot FSUIPC? FSUIPC only reads proper Windows-recognised joystick axes. All others need their own specific drivers. There's no "serial connectivity issue within FSUIPC" because FSUIPC doesn't support any serial devices as it stands. The only way you'd get a serial device to interface to FSUIPC is through other software, or perhaps a Lua plug-in. So what are you actually using? Regards Pete

No, that's a copy of the post-calibration inut value, from the axis. Axis inputs are normally either by assignment directly in FSUIPC, or by sending the approriate controls and paramter values to offset 3110. You will need to find the special tiller control number in the lst of added FSUIPC controls in the Advanced User's guide. (It is 64136). Another alternative is to use the axis inputs normally reserved for PFC devices, at 3BA8-3BC4. 3BC4 is the one used for the PFC tiller.But any would do as you then assign in FSUIPC. No. I think you are misunderstanding something. Both of the above methods lead to calibration in FSUIPC as a tiller. For the arbitration you also need to assign rudder direct to the calibration. If you are intending to do your own arbitration between rudder and tiller then there is no point in trying to put the value through FSUIPC as a tiller. The actual control you are using is called "rudder" (FS9 has no separate tiller, and FSUIPC does not use the one in FSX). Naturally you'd read both rudder and tiller and decide what value to send for rudder yourself. The offset for direct FS rudder control, bypassing calibration etc, is 0BBA. Pete

Not much to sort out. I gave you the one line you need to switch all the lights out. Juyst replace all of your code between this ipc.display ("Please wait, switching off lights!") ipc.sleep(400) [/CODE] and this [CODE]ipc.sleep(1000) ipc.display("All lights switched off!\n Thanks for your patience, Captain!")[/CODE] by: [CODE]ipc.writeUW(0x0d0c, 0)[/CODE] or do you actually want them all going off one at a time with one second intervals? If so, just replace each group like this: [CODE]LOG = logic.And(ipc.readUW(0x0D0C), 0x256) if LOG ~= 0 then ipc.control(66376) end [/CODE] by this: [CODE]ipc.clearbits(0x0d0c, 256)[/CODE] with the "256" of course replaced by the correct bit value. Pete

Sorry, I've no idea. Isn't this a case of checking the SDK information, or asking PMDG support? I don't even use any PMDG aircraft I'm afraid. All I've done for 737NGX users is map the entire data supplied by the SDK onto offsets, en bloc, and published the offset numbers with the descriptions from the SDK. I cannot support them nor interpret them. Sorry. Pete

First comment: You are reading offset 0D0C, which is not only the state of the lights, but also the control for the lights, yet you are then using "ipc.control" to send individual FS controls. All you need to do, and much more simply, is write to 0D0C with the sum of the values representing the lights you want ON. If you want them all off, just do this: ipc.writeUW(0x0D0C, 0) 0 has no bits set and therefore turns all lights off. No need to read 0D0C at all if you don't want to know if any lights are on To switch lights ON, just add together the values you have for the bits, and do ipc.setbitsUW(0x0D0C, N) where N is the sum (e.g. 16 + 128 for Strobes and Wind lights ON). Likewise use ipc.clearbitsUW to turn sleected lights off, or ipc.togglebitsUW to toggle on/off. Second comment. in all the lines like this the last parameter is wrong and is the reason your program doesn't work: SLI = logic.And(ipc.readUW(0x0D0C), 0x16) All the values you have for the bits in 0D0C are in DECIMAL. That's why they double each time for each successive bit (1, 2, 4, 8, 16, etc is a DECIMAL progression). So you must NOT precede it with "0x" which tells the computer you mean HEXADECIMAL! Your "0x16" is actually decimal 22 (1 x 16 + 6). So the above line would be SLI = logic.And(ipc.readUW(0x0D0C), 16) Please see the FAQ subforum thread about bits and numbers. Finally, please note that the only official reference for offsets is the offset lists provided in the FSUIPC SDK. Regards Pete