Pete Dowson

FSUIPC does not directly support PMDG aircraft because they do their own thing, they do not use built-in FS systems. However, you can READ data relating to the overhead via the offsets as listed in the document installed in your FSUIPC documents subfolder. You cannot write to these, however -- you must use the additional controls PMDG have added. You need to enable their SDK and refer to the documents and the header file you'll find within. For examples of interfacing to fSUIPC, please use the FSUIPC SDK. Regards Pete

FSUIPC doesn't support PMDG directly as it is not a default FS aircraft and they do all their own subsystems. For the PMDG 737NGX (only) there are values relating to the overhead readable in offsets, as listed in the document you have installed with FSUIPC. These are just a one-to-one mapping of the data PMDG supply in their SDK, which you need to review and enable. You cannot write to these through FSUIPC. You have to use the added controls which PMDG provide and document in their SDK. If you are not using the 737NGX then I think you are out of luck, unless you pay PMDG a lot of money for their hardware developers toolkits. Regards Pete

There are numbers and there are strings. Strings are collections of ASCII characters and in FSUIPC can be up to 256 bytes long -- the max length is listed. Numbers are any of many types, as listed in the references i've already given you. They vary by size (BYTE, 8 bits, WORD 16 bits, DWORD, 32 bits, Quadword or long long, ot _int64, 64 bits), signed or unsigned, and format (fixed point, integer, floating point). Floating point ones are 32-bit (float or FLT32) or 64 bit (doundle or FLT64). Please see the FAQ on nmubers in the FAQ subforum. Different languages use different names for these various number formats. For VB you'll have to refer to VB documentation. The 0 and 1 are just numbers. you could read that one into a byte. normally, In C/C++ you'd call it a boolean variable, as it is either true (non-zero) or false (zero), but it is stll just a number nevertheless. Depends what you want to use it for. Pete

You would be better off using events in any case. Is the axis your are reading not assignable in FSUIPC's axis assignments? If so then assign it to "luavalue <name of lua>". If you want changes greater than 10 to be recognised then change the default Delta on the assignment page to 10 instead of 256 or whatever it is currently. The wrap your brightness code into a function like function brightness(value) ... end [/CODE] and add [CODE] event.param("brightness") [/CODE] at the end. This will then allow FSUIPC to automatically call that function with the axis value when it changes. At other times the Lua plug-in is suspended. You don't need to test "value" for changes -- if it hasn't changed the function won't be called. You do need of course to make sure the plug-in is running first -- e.g via an [Auto] action or from ipcReady.lua. This worries me a bit: If you only deal with 20 values each with a range of 51 from the axis, why are you testing for changes in 10s? Surely a change of 51 should be needed? Instead of: [CODE] if Value1> -1 and Value1<51 then ipc.runlua("SuperScript_VRS", 120) elseif Value1 > 51 and Value1 < 102 then ipc.runlua("SuperScript_VRS", 121) elseif Value1 > 102 and Value1 < 153 then ipc.runlua("SuperScript_VRS", 122) elseif Value1 > 153 and Value1 < 204 then ipc.runlua("SuperScript_VRS", 123) elseif Value1 > 204 and Value1 < 255 then ipc.runlua("SuperScript_VRS", 124) elseif Value1 > 255 and Value1 < 306 then ipc.runlua("SuperScript_VRS", 125) elseif Value1 > 306 and Value1 < 357 then ipc.runlua("SuperScript_VRS", 126) elseif Value1 > 357 and Value1 < 408 then ipc.runlua("SuperScript_VRS", 127) elseif Value1 > 408 and Value1 < 459 then ipc.runlua("SuperScript_VRS", 128) elseif Value1 > 459 and Value1 < 510 then ipc.runlua("SuperScript_VRS", 129) elseif Value1 > 510 and Value1 < 561 then ipc.runlua("SuperScript_VRS", 130) elseif Value1 > 561 and Value1 < 612 then ipc.runlua("SuperScript_VRS", 131) elseif Value1 > 612 and Value1 < 663 then ipc.runlua("SuperScript_VRS", 132) elseif Value1 > 663 and Value1 < 714 then ipc.runlua("SuperScript_VRS", 133) elseif Value1 > 714 and Value1 < 765 then ipc.runlua("SuperScript_VRS", 134) elseif Value1 > 765 and Value1 < 816 then ipc.runlua("SuperScript_VRS", 135) elseif Value1 > 816 and Value1 < 867 then ipc.runlua("SuperScript_VRS", 136) elseif Value1 > 867 and Value1 < 918 then ipc.runlua("SuperScript_VRS", 137) elseif Value1 > 918 and Value1 < 969 then ipc.runlua("SuperScript_VRS", 138) elseif Value1 > 969 and Value1 < 1024 then ipc.runlua("SuperScript_VRS", 139) end[/CODE] why not just: [CODE] if value > 1019 then value = 1019 end ipc.runlua("SuperScript_VRS", 120 + (value /51)) [/CODE] making the entire program just [CODE] function brightness(value) if value > 1019 then value = 1019 end ipc.runlua("SuperScript_VRS", 120 + (value /51)) end event.param("brightness")[/CODE] Finally, using runlua like that is really destroying the beauty of the solution. It would be far more efficient to put whatever code "SuperScript_VRS" is doing directly into this plug-in. It's only using a bit of memory, then, but running it afresh every time is reading a file, compiling the Lua, as well as executing it. Regards Pete

Err, how did you miss the second one you should have found on the search, assuming you started at the beginning, 030C, which does that for you? You won't get good results doing the ones you looked at. Well apart from 3.28081 not quite being as accurate as the documented 3.28084, yes. That's what it says. Pete

Search on "vertical speed". You should find it soon after the current vertical speed -- I don't remember the offset offhand. Pete

Please do NOT use whatever is written in FSInterrogate as being main reference material. It is very old and unchecked and unmaintained. The references for offset usage are the documents, the Programmers Guide and the FSUIPC4 Offsets Status. don't you have any references for Visual Basic at all? How are you learning it if not? As far as I know the &H prefix just means "Hexadecimal". In C/C++ the prefix is 0x. I think you really need to refer to VB reference books or learning guides to learn VB. FSUIPC references cannot teach you VB. It is actually the OFFSET of the ADDRESS, in the section of COMPUTER MEMORY containing all the FSUIPC data, of the data item. The "OFFSET" is the number of bytes from the base address, which is unknown, except inside FSUIPC, and variable in any case. I'm sure the FSInterrogate documentation defines its type abbreviations. And I think they are the same or similar to those used in FSUIPC's Logging -- see the FSUIPC User Guide section on logging options, particularly the right-hand side window for Monitoring values. e.g S16 = Signed 16-bit integer, or word. But beware, not all of those in FSInterrogate are correct, and there are many offsets missing. Use the offset lists instead. Number of BYTES, not CHARACTERS. They are not always the same. Unicode and Wide Characters are 2 bytes each. I think VB uses 2 bytes per character by default. Why not read FSInterrogate's documentation? I think the expression is how the value provided in the offset is converted to regular units. It is derived from the Offset documentation I already referred you to. Please please please use the documentation, and refer to VB manuals about VB. Regards Pete

Aha! Then you need to change the video driver. This bug has now been confirmed by three other users of that facility. There's no other work-around found so far. Here's a quote from one who solved it: Regards Pete

Hmmm. So FSUIPC4 isn't getting loaded even. Are you using nVidia's "Surround" mode on three screens, by any chance? If so, that's a video driver problem. Maybe others like this are too, for all I know. There's no code I can change to fix this if none of my code is actually being loaded, and if it is the "trust" bug then this is the first time i've heard of it recurring after working -- at least till the next update is installed. The idea of the Loader was to save updating the part actually being loaded by SimConnect and so avoid the problem after initial success. My main problem with all this is that it has never occurred on any of my four FSX systems, and evidently doesn't occur on the vast majority of others either. So it is something to do with something else in the system which somehow wrecks what SimConnect is doing. Maybe other ideas might occur if we had more information, like, for instance, the Windows error log entry for this crash. To get this enter "event log" into the search programs edit space on the Start button, press return. When the Event Viewer appears, select Windows Logs -- Application, and find the error (marked red exclamation) in the list. Double click on it to get a separate details window, then clcik 'Copy'. you can paste the result into a message. Please also paste in your DLL.XML and EXE.XML files (the latter may not exist). Find those in the same folder as your FSX.CFG (<usr>\AppData\Roaming\Microsoft\FSX). Regards Pete

Well those sliders should be at max and min respectively in any case as I recommend in the documentation -- but they are surely only relevant if assigning through P3D, not via FSUIPC because it is FSUIPC then reading the values from Windows, not P3D. Regards Pete

Sorry, what error is that? Can you be more specific please? FSUIPC.DLL doesn't run on FSX only FS9 and before, You seem to refer to this as some well-known error ("the ...error"?), but I don't know what you actually mean. And there is no message "FSUIPC DLL: FS new universal IPC interface" in FSUIPC4 at all! In fact words similar to that do only appear in FSUIPC.DLL for FS9. Are you sure you haven't got the FS9 version placed in the FSX root folder? This is very likely to crash FSX. Perhaps you could say which FAQ you are talking about and exactly which error you are getting, please. The only one I am aware of is the SimConnect "Trust" error, and that isn't a re-occurring one, once it is overcome the once. I need the FSUIPC4.LOG file (paste it in a message) if one is produced, and the Windows error log details too, please. BTW something must have changed. Software doesn't change just because you shut it down and start it up again. Possibly you have a corrupted FSX.CFG file or logbook? The latter can also give crash symptoms during loading. Regards Pete

Good! Pete

And not Microsoft either, so -- specific just to those add-on aircraft, made by the aircraft makers? I logged events on FS9 whilst pressing buttons onthe 500 and, yes, nothing was logged. So it does its own thing, internally. No help there. L:Var writing isn't where to start. You need to LOG lvars when you operate the GPS to see if any change. Those may then be writable (via Macros, as described in the FSUIPC documentation). In the Lua package supplied with FSUIPC and installed in the FSUIPC Documents folder there is a Lua plug-in called "Log LVars". This logs current L:Vars and changes as they occur. But don't bother -- there are none associated with the default 500 gauge either. I just checked. Same for the G1000. All the functions are programmed internally in the PANELS.DLL module. I don't think you'll get anywhere with the MS gauges. Maybe you need to purchase the RXP ones? Regards Pete

Correct, as in fact it states on the screen. The only way to do which you want is to use a Lua plug in which converts the change in axis value to a Trim Inc or Dec. Here's an example: function checkvalue(val) if prev ~= nil then if val > prev then ipc.control(65615) elseif val < prev then ipc.control(65607) end end prev = val end event.param("checkvalue") [/CODE] Save this as, "trimwheel.lua", in the Modules folder and add this to your INI file: [Auto] 1=Lua trimwheel Run FS and assign your axis, in the normal FS controls assignment on the left, to "Luavalue trimwheel". Regards Pete

Mouse macros are completely dependent on the code in the Gauge modules being used. They are actually calls directly into code. If those aircraft have different gauge modules you'll need different mouse macros. Regards Pete

Please state the version number of the FSUIPC you are attempting to install, This was an earlier problem when P3D was first added. It doesn't occur here with any recent version, unless you used to have FSX and when you removed it you did not clear the Registry of its remnants. In the latter case the installer would still detect an fSX presence and want to install to it. And please paste in the Install log. The reason one is produced is to help resolve such problems. Hmm. Very strange. Ah ... just saw your later message: Ah, that would explain it, though the KEY file should have been written in any case. Normally with both an FSX and P3D installation it creates the Log and Key files in one installation and simply copies them to the other -- it's more efficient than writing two identical files separately. I obviousy need to deal especially with the case where one installation is cancelled before completion. No, I'll simply change the Installer as above instead. Thanks for the report. Regards Pete

Maybe a search and replace will work if you are careful with what you specify. Then at least you can do it batch-wise. I assume you feel that trying all USB ports would be more of a pain? I'm not sure myself which I'd prefer.. Why? The check box has always been there. Or do you mean because in old versions (over a year ago probably) mouse look wouldn't have worked? Now you can enable it in FSUIPC and assign its own mouslook on/off controls, or just use the middle button. It is certainly recommended to do this if you assign axes in FSUIPC, not in FSX, because otherwise FSX can mischievously re-assign things automatically if it sees them anew. Regards Pete

You presumably didn't bother to configure your FSUIPC to use joystick letters, as recommended in the User Guide? Really? I don't know how you read that. It is about joystick ID numbers (0-15), and they are assigned by Wndows in some way related to their USB connection. GUIDs are long numbers which can usually be relied on to uniquely identify a device, but FSUIPC only falls to them if the names are ambiguous, and it only uses the names if it is allowed to by you letting FSUIPC use Letters to ID devices instead of the usual numbers. Well, with those two to compare at least you can work out which ID number was which. You'll now need to edit all the [buttons] and [Axes] sections to provide the correct joystick numbers. Once you've done that and got it correct I suggest you change to using Joy Letters so you aren't faced with such a task again. For that refer to the User Guide section listed in the Contents list as Keeping track of multiple control devices ("Joy Letters") Well, you could try unplugging them and re-plugging them in a different order (ie different ports) until you find the right order. Take them all out and try one at a time in each USB orifice until it assigns as you wish, then go to the next, and so on. You can do all this with FSUIPC options still displayed. Just press the "Reload" button to make it rescan devices each time. When you do have it right, whichever order you do it in, have a read of the section in the User Guide you should really have read earlier. ;-) Regards Pete

By "Kiwi" speak do you mean Maori? Because I've been to NZ and everyone I met there speaks English quite well. No idiots guide to assigning buttons or calibrating axes is needed. The documentation is complete, but it is all intuitive in any case. Try it on a default aircraft, it is really easy. 99.99% of all users find it so. Maybe the difficulty lies with this WARTHOG thingie? Doesn't it come with any documentation? Pete

Not default aircraft I assume? Are they the RealityXP gauges? If they are default gauges, then enable event logging in FSUIPC and see what control is logged when you click the button. If none, see if the mouse macro technique will work, or maybe writing to a local panel variable (L:Var). If they are not default gauges, then also check the documentation from the supplier to see if any other method is provided. FSUIPC gets the list of FS controls from the Module called "CONTROLS.DLL", which lists many controls now either unsupported or defunct, and some which seem to have been good intentions never fulfilled. I am not in a position to test and document them all. FSUIPC merely provides access to them. If the gauges are third party add-ons then they are most unlikely to use default FS controls, unless the maker of those gauges had the foresight to use them. They are not default gauges -- I have neither of them, only the G1000. It certainly sounds as if they are indeed the RealityXP gauges, so it is their support forum you probably need to seek help within. If it isn't operated by a control, then only if it is susceptible to mouse macros, or L:Var writing (have you tried using the local variable logging to see what happens when you operate the button?), or has a keyboard shortcut you can assign. Regards Pete

The INI file is always read. Sounds like you moved your devices around. Windows re-assigns IDs if you do that. This is why FSUIPC provides a system of "joystick letters", described in its own chapter of the User Guide, which allows it to keep track of movements like that. Sounds like you ought to be using it. Meanwhile you'll need to determine which device is now which and edit the INI file accordingly. Or reprogram it all, but that might take longer. Once you've done, set it to use the joy letters. FSX and FS9 are not related at all. They use separate files. Regards Pete

The updates are in the Updated Modules subforum her, and are correct theree. I assume you are referring to the Schiratti site, which takes a little longer to update. It should be okay later, but please always check here. I have more control over this place, the Schiratti page is not mine. BTW you posted your report twice. I'm only answering once and have deleted the superfluouus posting. Regards Pete

There's nothing in FSUIPC which touches the mixture when you use that offset. I think you must have somethng else going on as well. Use FSUIPC logging to work it out. Show me the log if you don't understand it. BTW, you should always state the version of FS (FS9, FSX, P3D, FS2002, earlier?) and the version number of FSUIPC. There's no relationship between them in FSUIPC. Are you sure you are only writing 2 bytes (16-bit words) to the 0890 and 0892 offsets? Log IPC writes and FS events. A common error is using the wrong variable type or size. Pete

Strange, because the specific drivers mentioned fixed exactly the same problem for at least two others. And you did not post precise version numbers, only 301.. and 304.. Each major version has a sub-number too. Are you using the P3D v1.4 version of FSUIPC (4.852)? Have you tried using the FSUIPC4 Loader to see if it makes any difference? If none of that works I'm afraid I'm out of ideas. Sorry. Pete

It can only be because with FSUIPC loading there s a slight difference in timing elsewhere. There is nothing in FSUIPC in anyway related to video, graphics, or anything like that. I assume, then, that you've not bothered to try the version of the nVidia drivers which works for others and which therefore does not contain this bug? There's no way I can debug inside video drivers, which is where it is crashing, even if I had the right hardware to generate the problem. The way you must proceed is to install the non-buggy version of the drivers. As reported by others: Pete