Pete Dowson

Only the KILL keyword, which forcibly terminates it just like using Task Manager to end its process. Not friendly, but normally harmless unless you've changed parameters you want it to save. Different programs take longer to close depending on their "tidy up" at the end. Pete

Well, that's not right! No. That's where they are already. Run run them from there, assuming you don't have a Simconnect installed already. If you've been running other add-ons like the 737NGX you already has Simconnect installed. Ah, if you were using an out of date version of FSUIPC4 then of course it won't work with a later version of FS! How could it be made to work with anything unknown when the version you were trying to use was made? You ALWAYS need to check for the latest version of FSUIPC. Older versions will NEVER work properly with later editions of FS (or P3D) -- things change each time! And note that anything older than the current release is not supported in any case. SimConnect is part of FSX-SE, as it was always part of FSX. You can't "remove it". And if you try to remove the SimConnect.dlls you presumably installed (or which were installed in any case) you will probably wreck things, even possibly necessitating a later Windows reinstall if you ever want to use virtually any FS add-on. FSUIPC depends entirely upon the SimConnect part of FSX, FSX-SE and P3D. SimConnect is a fundamental part which provides the interface for many many add-ons! The DLL's you installed are simply the interface to SimConnect, which actually is embedded in many of the parts of FSX in the FSX folder -- the other DLLs, each responsible for different aspects of the Simulation, and each of which provides some of the functionality of SimConnect and thence addons like FSUIPC and others. Pete

If EZDOK promotes itself to foreground there's not really much you can do about it. Are you loading it with the "READY" keyword too? If so try leaving that off so it loads whilst FS is still loading. However, if you aren't having FS starting at the initial selection menu, and going direct to the full screen mode for a default flight, that might not make any difference. Sorry, there's no facility for that, though I suppose you could look at having an automatically loading Lua plug in which send the relevant keystroke combination. I use OpusFSI for my view controls as I find it rather better behaved, and if you minimise it it loads up minimised next time too, so not taking the screen. Maybe EZDOK will do the same? Pete

I don't know Pascal at all, but in C/C++ and I think even Basic, just copying the number to a variable of the other type will convert it for you. Of course you lose any factions, so in C/C++ I would do: int myias = origias + 0.5; or, to stop warnings from the compiler, int myias = (int) (origias + 0.5); This latter trick is called "coercion". There must be a way of doing it in Pascal. it maybe by using a function. Don't you have any references? Otherwise isnt there a support forum for your product or language? Ah, sorry. You'd didn't say in your first post that it was an MCP value. That's different for sure with PMDG. Pete

In what language? Are you sure the IAS is not also available in the normal place even for PMDG aircraft? I'm sure PMDG stll actually use the flight simulation part of FS, they don't only use it as a graphic display vehicle. Take a look at 02BC which is an integer x 128. Pete

Well, yes, you could write a Lua replacement for EPICINFO, doing the serial port reading and interpreting the results and sending the relevant data back similarly. At least, I have a vague recollection that EPIC interfaced via a normal serial COM port (or an emulating driver like the FTDI ones, these days). There are quite comprehensive COM facilities in the FSUIPC Lua libraries, and I would have thought these would cope. But it sounds like a it could be a lot of programming. I'm afraid i remember nothing of EPIC these days. Sorry I can't be of more help. Pete

You can do what you want, in the way you suggest, but only by using a Lua plug-in. You'd need to actually send the brake controls (the ipc.control function) from the plug-in after checking, by reading the "on ground state offset (by the ipc.readUB function) and checking you are on the ground. You'd assign the Lua plug-in for the Y axis instead of the brake. You wouldn't be able to select the elevator control in the "Direct to FSUIPC" list, but assigning to the normal FS control will be fine in any case. Pete

Sorry, again it isn't clear. What do you mean by 'script'? If you mean Lua plugins, there are documents and examples supplied, and the functions involving controls do say controls. A complete list of all FSX and P3D controls is also included. Pete

Sorry, what "issues"? And how can you search for the word "controls" and not find that in many places throughout? Pete

First, please ALWAYS post support questions to the support forum NOT to the assorted reference subforums which are for reference. It won't get replies there and might be missed altogether. You are lucky I saw it! Second, the FSUIPC installer relies on the Registry correctly stating where your FSX, FSX-SE or P3D is installed. As you can see from the log extract you showed this isn't the case -- none of the valid places for that path name are in the registry. It looks like at some stage after installing FSX-SE you restored the Registry (maybe Windows?) to an earlier state. I can't think was else would lose the entries required. If the Installer cannot find FSX, FSX-SE or P3D through the Registry it will ask you to find the correct place (with FSX.EXE or Prepar3D.exe) and it will then even fix the Registry for you. Didn't you get this option? It doesn't care where you run it from provided it in on the same PC. It is totally dependent on the correct entries being in the Registry. All proper installations of FSX, FSX-SE and P3D do place all the details needed in the Registry. You have somehow got that messed up! If that is where you put the Installer (the EXE) then the ONLY file it "dumps" in the same folder is the Install log, which you showed a fragment of. Next time you post a log please show ALL of it. Fragments do not show all the necessary information and just makes helping you properly near impossible. I suggest you uninstall FSX-SE and get Steam to reinstall it. That should fix the registry. And if I were you I'd install it anywhere but in Program Files or the X86 version of it. Folders in those locations are protected by Windows and you'll then have much difficulty with many add-ons. Also, FSX-SE is 32-bit program and "Program Files" is the repository for 64-bit programs! The X86 one is for 32-bit programs. It might well be worth uninstalling Steam as well, and starting from scratch without Steam going into Program Files. Pete

Yes, of course. That's what the parameter is for. Yes. All the drivers I've written, for FlightLink EPIC stuff many years ago, and for all the PFC stuff a little more recently, does this. Whether you encode for fast and slow separately (it isn't needed for some types of values), it is always best to display locally immediately, send values at sensible periods to the sim (certainly not faster than it can display), and also ignore values sent for display from the Sim until the user has stopped turning the dial for a while (1/2 to 2/3rds second in my experience). This applies even to the fine encoders I have. Pete

I've not opened all that stuff, I'm not interested in proof that it goes wrong because I believe you. Did you try the reconnection to SimConnect after changing to multiplayer as I suggested?I And what about just showing me the FSUIPC4.LOG? I deliberately added a line which logs the user aircraft ID whenever a change is noted. I did tell you these things. Please refer to my previous answer. BTW are you the only person out there using multiplayer, with FSX or P3D? I'd be interested to know if this problem is specific to P3D, because if it is it will be up t Lockheed-Martin to fix it -- FSUIPC is doing the same with both FSX and P3D. There is no difference required in any of the SimConnect interface it uses. Of course it may be specific just to your system, but I've no idea what the reason could be for that. I think it would still need the P3D guys in L-M to resolve it. Pete

Yes, it certainly is. "Offsets" are hexadecimal numbers in the range 0000-FFFF which represent positions inside FSUIPC memory which contains data. You can normally read all of them, and write most of them. Writing to them usually makes some actions happen -- FSUIPC detects the write and determines what to do about it by the offset value. The PMDG offsets aren't writable -- they only provided a way of reading all their data so it could be displayed. "Controls" (also known in FS as "Events" or even "Key Events", are numbers representing an action, a request to be passed. The assignments you make in FSUIPC or in FS, whether for keys or buttons, are to controls. They don't represent any data specifically, but a thing to be done or set. They can provide data (via the parameter). I think pretty much all of the PMDG cockpit switches and dials have their own assigned custom control numbers. That's because Lekseecon was programmed to do this, to interpret the offsets for you. No. PMDG did things differently. It wasn't until later versions of the 737NG that you could do anything like now -- no custom controls, no data readouts. The stuff they did later and published in the SDK was an eventual concession to cockpit builders and the like. But I still don't believe it's the right path to take for full hardware implementations of cockpit controls. I use a flight model with no cockpit at all. My cockpit support is external, via Prosim737 at present -- it used to be Project Magenta. There's also SimAvionics. Pete

None of the PMDG offsets are writeable -- they are just readouts for display. You have to use the controls they provide. Pete

FS and FSUIPC handle frequencies xxxx.x (1234.5) , but there are many add-on radio stacks which only support 4 digits. For the PFC serial port stacks, I had to use one of the other ADF buttons to switch between displaying (and adjusting) the xxxx (1234) and xxx.x parts (234.5). Pete

If there's a limit it isn't imposed by anything in FSUIPC. FSUIPC simply calls the appropriate functions in the panels interface to FS, same as a gauge might. That is related to how long to allow if you try to re-run the same plug-in, to alloww it to terminate before killing it and starting it again. The list is the same for each in any case. I suspect they are created by a common component, not a specific gauge. Maybe a DLL for that aircraft And how are you stopping the gauges not being checked from running in any case? You'd need to keep editing the PANEL.CFG file and reloading the aircraft. Pete

The PMDG 737NGX and 777X add-ons do NOT use FS systems, and certainly not the default APU. Both of those addons have their own mapped offsets which are documented in other documents into your FSUIPC Documents folder. But you must also set some parameter correctly in a file associated with the addon to make it export those values. I'm afraid I cannot support PMDG aircraft since I do not use them and don't know enough about them. Check the SDK folder in your PMDG folders, maybe there's help there. Else ask in the PMDG forums. The offset lists predates things like Lua by many years. Are you volunteering to do all the work? The whole system you are trying to use is aimed more at system implementers and programmers who have at least learned some basic programming. One of the basic things you need to understand in all programming languages is the types of numbers you can have. You only have to tie the number types together. In the case of 0B54 the words "32-bit float" occur in both the description in the offsets list and the description of the ipc.readFLT function. Why not match these up as I suggested? Pete

Why on Earth are you guessing? UB = Unsigned Byte (i.e. a single byte). There is a column in the offsets list which surely isn't hard to understand. It is headed "Size". The size is in bytes (the offset numbers are actually byte numbers, in hexadecimal). So 0892 is two bytes, or a Word (W). And the names UB, UW and so on are described in the Lua library reference, for each one. So why not simply try to match the one to the other? Surely that is simple enough? If not, why not? In the case of 0892 a UB would actually also work because the value there should never exceed the capacity of that one byte (0-255). 0B54 is listed as a 32-bit float. Why not find the correct read function in the library to match that? It isn't hard, and it certainly is not SD. (Both parts of SD are wrong -- an RPM can't be negative so it isn't signed, and it isn't a DWORD (D) which is a 32-bit integer). Do try looking things up. It takes more time for you to come here posting such questions and for me to see it when they can be so easily answered yourself faster with just a little effort! Pete

That's not surprising when you are reading 34B0 as a two signed DWORD (32-bit) structure into one variable, and discarding the other. If you refer to the offset list you'll see 34B0 is a double float value (64 bits or 8 bytes) which you'd read using ipc.readDBL. No way can you read just half of it in the wrong format and expect it to be anywhere close! Also it is in metres (as, again, you'd see if you referred to the offsets list). So just multiply by 3,28084 to get feet. A stabilised jet engine is one with more or less the correct N1%. Mostly the Start switch trips automatically from GND back to off just as it reaches around 20% I'd check for something between 18 and 22, then wait another second or two. Pete

The FSUIPC installer wouldn't have created that. There are other installers for other programs which use the Modules folder. Pete

I don't have a program called "FSClient". Do you mean WideClient, the remote part of WideFS? Why do you need both? WideFS supports FSUIPC applications on a separate computer. It doesn't need a registered FSUIPC to work with. And FSUIPC supports applications on the main FS PC without registration. Purchase of FSUIPC is only necessary if you want to use any of its user facilities or plug-in capabilities, not for application support which has always been free. Anyway, the package deal is on both the FSUIPC4 and WideFS7 purcjase pages. Just select the package where is says "Select Package" just below the picture icon top left. The selection to the right of those words contains the bundle which you select. Anyway, I think you need to read more of the PanG manual. It just downloaded it to take a look (I've never used PlanG). For FSX PlanG doesn't need either FSUIPC or WideFS to work over a Network, it can use SimConnect which is preferred. It's up to you. If you are likely to want to use FSUIPC/WideFS for other things, go for it. But I'd always check the actual needs first if I were you. Pete

Not in FSUIPC itself, but I think someone wrote a Lua plug-in to do that a while back ... ... Yes, take a look in the User Contributions thread I think the thread entitled Throttle manager to allow axis forwardreverse toggle Pete

Assuming that IP address is correct (check), it looks like a firewall type block on one end or the other, probably the server. Pete

For help with that you'd need to show me the WideServer.log and the WideClient.log files. An updated FSUIPC won't change it. Pete

Sorry, I don't actually have the PMDG aircraft and I don't know the SDK at all except that I mapped the read-out data to offsets. You really need PMDG support. I'm pretty sure the default radio controls will work. I don't know any add-on aircraft which implements radios separate from those built in -- all sorts of things like ATC, on-line flights, etc, wouldn't work if the radios weren't the ones simulated in FS. PMDG just build the graphics round them in the gauges. Pete