Pete Dowson

It isn't hanging, it finished successfully, as it clearly says. BTW, if this was a "clean install", how come there was a very old version of FSUIPC4 already installed? Pete

There are no such conditionals on axes, only buttons. If you assign both the steering tiller axis and your rudder pedals in FSUIPC, setting both "direct to FSUIPC calibration", then FSUIPC will take care of it all in any case. In fact, for realism it also gradually switches from tiller to rudder as your groundspeed increases, with the crossover at 30 knots and full rudder control at 60 (this is adjustable). BTW you posted the same thing twice for some reason. I've deleted the duplicate. Regards Pete

Yes, that's fine. Glad you could sort it all out! Pete

The GFD (Go Flight Display) library is built in, it isn't external. Lua can call external DLL's as Modules provided they have functions written with a Lua interface in mind. I really can't tell you more that what I can read in the Lua reference manual. There are a number of ready-written external DLLs which will work -- the Lua gd Graphics library, for instance, which i know is already being used for Saitek gauge display modules. If the DLL you want to use isn't written with Lua access in mind you'd probably need to write your own DLL which acts as a wrapper for it, exposing its functions as Lua functions. Regards Pete

What are the details of this "fatal error"? Are you certain it isn't the infamous SimConnect trust bug (see fsx fails to run after fsuipc4 first installed)? Ah, if it is getting as far as producing a run-time log, it is not the "trust" bug. However both run-time logs show what the problem is: That is indicative of a Simconnect installation problem. Looking back to the Install log: it appears that you have updated FSX to only SP1 level (61355), but you have the SP2/Accel version of SimConnect installed. FSUIPC always wants to use the most up to date one you have, but the two are not compatible and it is that which is causing the fatal error. The proper solution is to install either the FSX SP2 update, or Acceleration if you have it. I would recommend this is any case as it fixes many FSX bugs. For information, FSX.EXE version numbers are: 10.0.60905 = RTM 10.0.61355 = SP1 (10.0.61357 for Russian version) 10.0.61472 = SP2 10.0.61637 = Acceleration. The SimConnect version is the same for SP2 and Acceleration. [LATER] This has prompted me to change FSUIPC4 so that it checked the FSX.EXE version and refuses to use a later version of SimConnect. This will probably get around your problem -- though the recommended solution remains the same, get your FSX installation up to date. If you want to try the updated version download 4.728 from the Download Links subforum. Regards Pete

Nice, but I feel sorry for your copilot! ;-) Can you say who makes the hardware you are using, or is it all home made? Regards Pete

Did you find Shlwapi.dll? I think that must either be missing or corrupted, or a very very old version, in your windows installation. Just to get FSUIPC4 loading you can try saving the text below into the same folder as FSX.CFG file as DLL.XML. <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>dll.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>FSUIPC 4</Name> <Disabled>False</Disabled> <Path>Modules\FSUIPC4.dll</Path> </Launch.Addon> </SimBase.Document> However, the problem needs resolving really. The Installer isn't continuing because it believes it cannot get FSUIPC4 to run without editing the DLL.XML file. So you aren't getting any FSUIPC documentation installed, nor will you ever be able to register it even if you wanted to. I remain puzzled and want to resolve the real problem. I am going to make a new Installer which logs some extra information for me. Will you try that for me, please, even if you go get FSUIPC4 running with the above file? [LATER] Please download the new Installer for version 4.728, I've now provided in the Download Links subforum. Let me know if that works on your system. Either way I'd like to see the Install log file, please, as I still don't understand what is going wrong. Regards Pete

I think you must have posted this to the wrong Forum? Nothing of what you mention relates to any software of mine, supported here. Regards Pete

So, what is the folder path you found to the FSX.CFG file? It should be For Vista or Win7: C:\Users\yourusername\AppData\Roaming\Microsoft\FSX For XP: C:\Documents and Settings\yourusername\Application Data\Microsoft\FSX The FSUIPC installer finds it by using the system-wide generic name for the folder, %appdata%. I've never heard of this not working. If that doesn't give the correct folder then it seems likely that there is something wrong with your Windows installation. Have you, by any chance, stopped any Windows services thinking they were unnecessary? What version of Windows is it? It looks like it must be XP. Is it updated? SP1, SP2? Or what? Tell you what, try once more running the Installer, but this time right-click on it and select "Run as administrator". If that doesn't work I may have to ask you to run some experiments to find out what is wrong on your system. [LATER] After some more research I find that the %appdata% path (also known as CSIDL_APPDATA) was supported in Windows by Shlwapi.dll version 4.71 and later. Maybe somehow your Windows installation has somehow had that replaced by an older version? I just searched for that DLL on an XP system here and it was found in the C:\Windows\System32 folder. Mine is version 6.0.2900.5912 -- my XP system is fully updated including SP3, but I'm pretty sure all XP versions should be okay. Regards Pete

It certainly looks as if you succeeded in downloading FSUIPC4, else you wouldn't have been able to extract and run its installer. That isn't the complete Install log -- it starts earlier and finishes later. Please laways post complete files as else I cannot tell you what to check and do. Additionally it shows that FSUIPC4 was already installed: The problem with the DLL.XML is because the path to your FSX.CFG file location isn't available: Did you install FSX for a single user, other than the one you are installing FSUIPC for? The FSX .CFG path, which is where the DLL.XML file would be placed or created, is in a folder like: C:\Users\<user name>\AppData\Roaming\Microsoft\FSX where the FSX user name goes in where it says <user name>. Regards Pete

Like other PMDG aircraft, it saves its settings in additoinal files which it should reload. No idea why it doesn't, but FSUIPC's Autosave simply calls the FS routines to save the flights -- exactly the same as you doing it from the FS menu or using the ; shortcut. The only difference is the automatic naming. Sorry, it can't do anything cleverer than that. You might also want to see this thread: tip autosave and the pmdg ngx. Pete

As I said, In the [buttons] section, or the specific [buttons ...] section if you are using aircraft or profile specific settings. Why on Earth are you doing that? The 2 seconds is probably reasonable for all the file actions needed if your disk is cluttered or needs de-fragmenting, but you should make all of your macros for one aircraft in one file, in one go. You only visit the Options to start the process off, NOT for every macro! That's crazy! You only go back when you've finished, just to tell it to end macro making!!! No one else seems to be misinterpreting the documentation in such weird ways as yourself. How did you work out such a weird thing, thinking you have to start and end macro making for every single macro? I can't see how you derive that. You start a whole FILE not a single MACRO! If I were you I'd delete your INI file, to remove all of your erroneous settings and start again, doing things properly. Or at least delete all of your macro files and the [Macros] section in the INI. Pete

So, it will be loaded, compiled and executed on every change in the rudder axis. Okay. But you've programmed it as a loop? Why? Every time the axis moves you want it to run a loop with 2 second delays? Makes no sense. If you want it executed on every axis input you want it as short as possible and exiting directly it has done what you want it to o. You seem to have completely missed my last reply? All axis or "SET" controls need a parameter, the value they are supposed to set. How can FS do anything with the control with no parameter? What do you think it will set for the value? (FSUIPC will simply give it zero for lack of anything different!). You've obviously looked up the "ipc.control" function. Please notice the second parameter it can take. Also check "ipcPARAM" which will provide your Axis value. Please do read more of what is provided, and maybe look at some of the examples. Regards Pete

No, never. Macros go into Macro files. The conditionals you tried are for buttons only. Of course.! All "SET" controls require a value, the parameter to send for that action. How else will FS know what to do? Those controls mean nothing at all without a value to work with! It's called, in FSUIPC, the 'parameter'. No, that's nothing whatsoever to do with Lua or anything else in FSUIPC. It is simply the Trust bug in Simconnect. When that occurs FSUIPC itself hasn't even started, it's being loaded by SimConnect and checked -- see the thread about this in the FAQ subforum. Pete

Okay. Rather than edit the existing ReadMe I'm adding your examples and supporting text as a separate TXT file entitled as per this thread. Thanks! Pete

Oh, yes it does. It cannot write the FSUIPC file itself, the Install log, and the complete "FSUIPC documents" folder with the documentation, if it cannot also write the KEY file. They all go to the same place, using the same path and permissions! Where on Earth did you find the KEY file you sent to me, which did check out here okay, if not from your FS modules folder? No one else has had this problem! I don't understand what happened on your system. :-( Pete

What IS that? It's no syntax I've ever invented! <G>. The W part is an offset conditional, but there must be a space after that, then a normal button assignment type. What section is this in? A Macro file with a suitable [...] heading? I can answer specific questions but I cannot enter into a tutorial here. Please use the resources supplied already -- the Lua package with documentation of the FSUIPC Lua libraries and lots of examples (all installed with FSUIPC), the Lua website, and the ample examples in the User Contributions subforum. Regards Pete

You won't find it searching because it is such an obscure requirement. You could do it pretty easily using a Lua plug-in. They are separate controls. FS uses the slew set in slew mode, the flight set in flight mode. The FSUIPC combi axis controls are there so you can do all assignments in FSUIPC without losing the ability to slew with them that you have in FS. Regards Pete

It's not documented I'm afraid. It's a bit messy because it's grown since FSW95 days (a 16 year continuous update period) with so many fiddles to add new things without wrecking compatibility of the client with both Apps and the Server/FSUIPC parts that I wouldn't know quite where to begin now. Certainly others have had a stab, for interfacing to Apple Mac or Unix type PCs, but i don't know if they succeeded. They hacked it using Ethernet monitoring. I should ask the question, though: what would be the use of an FSUIPC interface on an iPad or iPhone? Because that's what WideClient does -- presents the FSUIPC interface remotely. You'd obviously need to revise the FSUIPC interface it presents, but then ... who is going to write the Apps to use it? It seems to me that it would be easier to go the way you have already, using your own Ethernet interface. If you'd care to explain what your ideas might be, perhaps I can release some of the source code for you to look at -- I assume you know C? But I'd pre-warn you, it is NOT a pretty sight, and some of it is so old even I probably couldn't explain it to you. If you want to discuss this privately, write to me at petedowson@btconnect.com. Regards Pete

Here, less than 2 seconds into the session, the Gear was shown to be UP, so it must have been set UP in the Flight you are loading (i.e. \\MARKUS-PC\Flight Simulator X Files\eddf.FLT) 1844 Monitor IPC:0BE8 (S16) = 0 21 seconds later it is put down, no idea by whom or what. 29438 Monitor IPC:0BE8 (S16) = 16383 29438 SimRead: 0BE8="GEAR HANDLE POSITION" It looks to me as if you have saved your default flight with the gear already up, so that as soon as you lift off it goes up. This is likely nothing to do with any add-ons whatsoever. Operate the Gear lever, put it in the Down position (or Up and Down if needed), then save your flight! "eddf" again! Regards Pete

Which screen is this, and what is the symptom of the "freeze"? Do you mean the joystick and button numbers don't appear when you press buttons, or only one button appears and won't change when you try another? If you don't mean that screen what screen do you mean? No, there's no known problem like that. If it is hanging it is doing so in a Windows joystick driver --- it sounds like the USB/Game Port joystick scanner is hanging. Do you perhaps have drivers installed for devices not connected? I've heard of this occurring when someone still had an old game port driver running but no game port device (or even a game port socket -- though many motherboards still have the pins for these). You could try adding PollEpicButtons=No to each of your [buttons] sections in the INI file. That bypasses one type of check FSUIPC makes. Regards Pete

I think all the strings it uses internally relate to CFG files which I suspect are not localised. Some others in FSUIPC are folder paths -- I think they have to be workable in 8-bit characters otherwise 90% of software designed to access files won't work. Is that old VB file relevant to today's versions? Anyway, it isn't actually my file -- all of the SDK parts other than C and ASM are from others. I can certainly have a look, but it might be better if someone who knows what he is doing does it. Regards Pete

Sorry, I don't know any of those products. Go to FSUIPC4's Logging tab, and add the Gear operating offset (0BE8) as an offset to monitor (right-hand side of dialogue). Set the type to U16. Check "Normal Log" below. Then reproduce the problem. Look in the FSUIPC4.LOG file. You'll see when the Gear was operated, and if this is from a Client PC on WideFs, it will also tell you which PC it was from, and the Process ID of the program responsible. You can then identify the program by its Process ID in the WideClient log file on that PC (assuming you are using a reasonably recent version of WideClient). Regards Pete

Thanks for your contribution. Just a clarification here. It is FS which uses strings in this format. Remember that FSUIPC is simply acting as an interface to FS. Regards Pete

You have your opinions and I have mine. I'm sorry about my phraseology, but the underlying meaning expresses my opinion. It cannot be a slap in the face as there is nothing insulting in it -- unless you care to deliberately treat it that way. How can believing that the intention of VB was to make it easy for non-programmers to construct programs be a slap in anyone's face? Just because some expert programmers choose it for some purposes doesn't make that untrue! I suggest this thread is terminated as it is totally unproductive and really a waste of both our times. Pete