Pete Dowson

Can you tell me what was wrong, please, because I've received your KEY file and still see no reason for it not to work correctly? Pete

Okay. This shows that there is either no KEY file in the FS modules folder, or one with incorrect or missing details: See? no name, no email! When you enter your information into the registration part of the Installer, it generates an FSUIPC.KEY file in the Modules folder, next to FSUIPC.DLL. It looks like you have either deleted this or edited it incorrectly. without that KEY file FSUIPC cannot read your details nor your Registration. There is no one else using FSUIPC who has ever had any problem generating the correct KEY file using the Installer. The Installer's own log shows it is making such a file -- that's what it means when it says "Registration for FSUIPC was successful! ". Please check your FS modules folder. What FSUIPC files do you see? If you see an FSUIPC.KEY file please Zip it up and send it to me at petedowson@btconnect.com. Pete

Actually, there are no screen coordinates involved at all. The reason they need regenerating for updated software or different models with different gauges is that the internal code in those gauges changes and so the address in memory of the routines being called changes. FSUIPC's mouse macros call gauge or DLL code directly. They are called "mouse macros" because the position in code being called is determined when a real mouse click is processed internally. Of course generally there is no need for a Lua plug-in to send FSX controls, only non-standard ones like those used in the PMDG 737NGX as you have found. But as far as I know that is the first and so far only aircraft add-on to implement things in such a fashion. If it became a common thing to do I'd probably look at adding ways of assigning them in the FSUIPC dialogue too, presumably then by number instead of name. Regards Pete

No, it is nothing to do with that -- because you NEVER want calibration values outside of those positions. Your minimum calibration should be set AWAY from the up detente and the maximum also AWAY. i.e. neither of them AT the detentes and not futilely outside of the movement, which is obviously silly. None of the calibration points should be at any detente -- the idea is to define the whole area around each detente as belonging to that detente so it is always properly selectable! That's only half the story. Where is the FlapEnds line? Look at the numbers you've set! -16384 is actually below the minimum of -16000 you calibrated to! There's a huge space from 4811 to 16253 then no space for any others! You don't seem to be following the instructions at all. This is evident by your idea that you are supposed to set minimum and maximum values outside the lever's range and outside the detentes, which is nonsense. The whole point of calibration is to define points which guarantee you can reach the desired psitions (i.e. the detentes). Please, once you understand what it is you are trying to do I am sure you will find it easy. I had hoped the "diagram" i tried to draw you would have made it obvious, but you seem to have completely misunderstood it still. Sorry, but i am running out of ways to explain it. It is really so easy -- just divide up the range into areas for each detente. How else could it work? Please think about it and understand it before doing anything. Delete the flaps lines in the INI and start again once you understand. Regards Pete

A red window? I don't know any way a Lua plug-in can make a red window! What is this Lua program supposed to do? How does it make a red Window? I think you must be mixing Lua up with something else. What are you trying to do? I don't have any software making red windows! I really cannot imagine what it is you are doing nor what is not working nor how you can tell whether it is working or not. Show me the Lua file please, and the FSUIPC INI file. Maybe i can tell you what it does, as you seem not to know. Pete

You did not need to rerun the Installer or re-enter any details. You merely had to copy in the updated Module, as I said. That is just the same Install log. I need to see the run-time log, the one called FSUIPC.LOG, not the Install log. Regards Pete

I didn't ask that. That is a very old LOG file! It dates back to 21st May 2010 and was with FSUIPC 4.60a, well out of date and not supported. Isn't there an FSUIPC log? If not then FSUIPC isn't running, which explains why it can't read Lua files! Note that lua files end with ".lua". Maybe you don't have any? You are still not answering all my questions! Look, I'll repeat the most important one again. This is the THIRD time! All you've told me so far is that FSUIPC is not reading your Lua file. Can you tell me how you know it isn't reading it? What ways are you using to test this? (Not "test the Lua" -- how are YOU determining that the Lua "isn't being read" as you keep saying. I still haven't got a clue as to what you are doing nor what you are seeing. You don't provide any information! I get a tiny little bit out of you, once per day. At this rate it will take weeks to get anywhere! :-( Pete

Unfortunately, if the subsystem you are trying to make fail is not fully simulated in FS, and it doesn't already provide such a failure simulation, the only way may be to take over the complete simulation of that subsystem and any related ones which may also be affected. There are some external subsystems implementations which may be able to do all this, and possibly some aircraft add-ons which are sophisticated enough. In FSX at present the most likely is the PMDG 737NGX which appears to have a very complete implementation of all of the subsystems. Of course such implementations do not use much of the FSX simulation and therefore you have to find other ways of changing the values and reading out the consequences. Among the external systems implementations you may want to investigate ProSim737 which I believe does implement all the interactions between systems and, as a bonus, can be interfaced via FSUIPC offsets. In which case there may be little choice but to check out some of the add-on or external systems implementations. Regards Pete

You don't appear to be reading my suggestions. Please read this part from my last message again: You may also want to install the latest update, currently 3.997p, from the Download Links subforum. It gets around some recent security additions to Windows which can make the registration checks in FSUIPC itself fail. This isn't an installation matter, just a run-time check. I cannot really help you if you don't bother to read and do what I suggest! :-( Pete

I don't even know if it does simulate changes in oil pressure, only that it simulates systems more than FS does. Maybe also sophisticated add-on aircraft like the PMDG range do. Perhaps if you tell me more about what you are trying to do I could advise better. For instance, in FSUIPC4 (for FSX) there is a facility to "spoof" values being read from FSUIPC (i.e. change them), using a Lua plug-in. Maybe this would meet you needs, whatever they are. Pete

The log is fine. The installer did not crash! If you didn't get the opportunity to enter your registration you must have accidentally clicked Cancel when the registration dialogue came up. Just run the Installer again and enter your details. It works fine for everyone else. It'll work fine for you. You may also want to install the latest update, currently 3.997p, from the Download Links subforum. It gets around some recent security additions to Windows which can make the registration checks in FSUIPC itself fail. This isn't an installation matter, just a run-time check. Regards Pete

I think the oil pressure is one of the values computed and maintained as a result of the simulation. I don't think you can change it really -- a new value will be computed on the next cycle. If you want to display a different value you'd probably need to use your own value, or a completely separate systems simulation like maybe Project Magenta, Sim-Avionics etc. Regards Pete

No need to apologise, and it isn't totally wrong advice. It is certainly possible to get an MCP Pro working over WideFS. But not with GoFlight drivers. All the buttons and switches are assignable, so you can program those in FSUIPC. The displays can be programmed for all default FS aircraft using either the now discontinued GFDisplay.exe (I actually supply a configuration for this in the package), or using a Lua plug-in -- and others have made suitable Lua plug-ins. For add-on aircraft the story varies. Folks are trying to sort it all out now for the PMDG 737NGX. There are others in the User Contributions subforum. But all the solutions involve some effort and searching and probably configuring. There isn't one simple solution. Regards Pete

No one can provide an example for your specific aircraft unless they have worked out how to get to whatever information it is you need. I do not know the Feelthere EJETS, ERJ 195 or ERJ-190. I checked in the User Contributions subforum, and no one else seems to have posted any solutions there either. Maybe there are really no problems and you are misunderstanding something? What is the information you need to extract and does it all work okay with default FS aircraft? The "Lua" suggestion was because a lot more can be done with Lua plug-ins than with simple assignment. However, it is not really the first step. For sophisticated add-on aircraft the answers sometimes lie in Mouse Macros or local gauge variables (L:Vars) -- usually not both, because Mouse Macros work with regular C/C++ programmed gauges whilst L:Vars tend to predominate with the newer style XML gauges. To see what others are doing with all sorts of add-on aircraft (sadly not yours though), do check out the User Contributions subforum. Regards Pete

I assume you mean GoFlight software versions? Not I, and I don't think GoFlight software is designed ot work across a network. What "module" are you talking about? The GoFlight MCP driver? Sorry, you've lost me. What exactly did you "try" which gave you no joy? Nothing i know of GoFlight's will drive an MCP over a Network. You can certainly program the buttons and switches in FSUIPC from a Networked GF device, but to handle the displays you'd either need to use the now unsupported GFDisplay program or a Lua plug-in for Wideclient. Since you mention nothing of any of this there is no way I can help further at present.. I'd really advise you to get it working on the main FS PC. If the software you were using before locks up on win 7 and didn't on an earlier system then there's something not installed correctly, or a hardware problem. There's certainly nothing in Win7 which should affect anything. You should try a different USB port in case the one you are using is faulty. BTW I can't really support GoFlight hardware and drivers. If you eventually arrive at any specific questions about FSUIPC or WwideFS facilities perhaps I can be more constructive. Regards Pete

Why don't you paste your Installer log file here as requested? The Log file disappeared? Don't you mean the display window closed? That is correct at the end. The log file is in the Modules folder, not simply on screen! When you confirm your registration, the installation closes instantly. Are you sure you are not mistaking a normal close with a crash? Why do you think it crashed? Why do you guess this? What is your evidence for this? Pete

No, that's only replacing FSUIPC4.DLL with FSUIPC4.DLL. What difference can that make? You've not answered my questions, so I still have no information. Did you miss this part altogether? There are 4 questions there. Do you think you can answer them? Then we might move forward! Pete

I think the USB connection may only usable for transferring waypoint type information. Just about all of the Garmin GPS's met so far which are capable of accepting NMEA or Aviation input do so via the special serial cable. I searched for your model in old threads and came up with this from bdschenk: (see thread Garmin 695 USB ) Regards Pete

There is no difference in ground speed readouts between any version of FS from FS98, and even CFS1 and CFS2. It sounds like the program you are using is reading an unsupported FSUIPC offset. Only the documented values are compatible across the whole range of Microsoft simulators The offset to be used is: You see that the format amounts to the integer METRES per second in the 16 bit word at 02B6, with the fractional part (in 1/65536ths of a M/Sec) in the 16bit part in 02B4. If you need feet/sec you can read it the 4 bytes into a 32-bit integer, copy to a floating point variable, then multiple by 3.28084 and divide by 65536. This certainly works in FSX the same as it does in FS9 and before as it is used by many programs without any problems. I've no idea how your application gets a different results in each and makes me suspect that it is even getting the wrong value in FS9. You can use FSUIPC Logging to see what the program is actually reading, and see the GS value in that offset in real time on screen by using the Monitor for offset 02B4 as a type U32 and checking the FS display or Adv Display option. Do this in both FS9 and FSX and compare. Regards Pete

That's fine. It just skips copying over an earlier version. I hate it when installers lose your up to date copy! It also won't overwrite your existing settings. Really? There's something else wrong, then, because it cannot be anything to do with the version. The installer cannot bypass the offer of registration, it's always the last part before it terminates. If it terminates earlier without a real error it is crashing and I've never heard of that happening. i need to see the Log from the Modules folder please. Pete

It theoretically should do -- it can with other USB devices, and can with GF devices when driven via the USB interface (the COM library in Lua with the HID facilities). You only need to go into the FSUIPC options again and it does a re-scan. I think currently the restart is needed to get GFDev.DLL unloaded and restarted. I'll look to see if there's another way to force that (maybe an uload library call or something) Yes, but I'm wondering if it's related, just that using the lower level GFDev calls gets over the 'complete hang' which is presumably the GFMCPPro driver not knowing how to recover. Pete

I seem to recall seeing reports of occasional display freezes with GF devices when folks use the GoFlight software too, so it might just be one of those little niggles with these devices. I can't find any at present though. I may be worth while telling your story in the GoFlight support forum to see what others say. Regards Pete

Sorry, I'm a bit confused. Where is the button you want to press. on a device on the client or on the FS PC? All the button scan interval in the Client INI file does is controls the rate at which WideClient polls joystick buttons connected locally, at the Client. If you then, in FSUIPC, assign it to send a keypress, that keypress is sent to FS. That's the whole point of the assignments in FSUIPC --- FS controls sent to FS, or keypresses, sent to FS. If you want a keypress sent to a client you have to assign in FSUIPC to a KeySend, then edit the Wideclient INI file to tell Wideclient to convert the numbered KeySend into a keystroke for a specific program. The program to receive the keystroke can be selected by a number of different methods. Please check the WideClient documentation for details about KeySends and sending keypresses. Some methods work better with some programs, but other methods with others. If you know for certain that the program concerned has the keyboard focus then it isn't so difficult of course. For PM's Glass cockpit "Ctrl + O" you would be better off not trying to use KeyStrokes in any case, but the facilities provided by PM to do it efficiently through FSUIPC offsets. Check the FSUIPC Advanced User's guide. Search for the list of PM Glass cockpit facilities, (`"Project Magenta GC Controls"). In the list you'll see 60 Show Overview Page in ND 61 Hide Overview Page in ND These do the same as Ctrl-O (O is for "Overview"). So, assign the button to the control named "PM GC controls" with a parameter of 60 to show and 61 to hide. Regards Pete

You are not reading properly, it was not commenting on his choice, just me being honest that I don't like Basic (I did also actually say Basic, not VB, though they are of a family).. That's where you are wrong. I actually wrote my own Basic interpreter long ago, in the early days of PCs. And although I also said it was my opinion it is a fact that it was designed to try to let non-programmers construct programs. Even the name reflects this, deliberately. It isn't a put-down or denigration. Many folks are experts in fields other than programming, they don't wish to be known primarily as a programmer (like me). Please do try to read what is written not your wild interpretations. Pete

I've moved your post from the User contributions subforum to here, the proper Support Forum. Yours iss not a contribution but a request for help. Do you think you could re-post it with a readable format please? I don't know how you are getting what you are posting, but whatever it is it is not normal plain text, and it is rather unreadable like that. And try to break it into paragraphs please. Regards Pete