Pete Dowson

Posted twice? See reply to other post.

The names are those used internally (and in the saved assignments file) and obtained automatically from FS at run time. I don't know them all by heart, I have to look them up -- there's a lit provided in your FSUIPC Documents folder. You can also find out what they are called by enabling Event logging in FSUIPC and using the controls (by keypress or mouse) and seeing what is logged. However, for the ones you ask they are pretty easy to remember. I think "cycle view" might be "Next view". But try it. There's also a "Next sub view". You could find these in the published List document by searching on "view". Doors are called Exits in FS, so just search for Exit. I think it is "Toggle aircraft exit" and you can give the exit number as the parameter -- 1, 2, 3, or 4. I think it defaults to 1. FS has never provided separate controls for Gear Up and Gear Down. The only way you can do that is to assign to the FSUIPC Offset word set control with the correct offset for the Gear state and the appropriate value as parameter. All the offsets are listed in the Offsets list ("FSUIPC4 Offsets Status"), again in your FSUIPC Documents subfolder. Pete

I moved your post in "User Contributions" to this, the Support Forum, because 1) it is obviously NOT a "user contribution", but a Support request 2) It would have not been answered otherwise. Answering your questions, I think you are confused because you followed a wrong path, going to a Support location for files instead of the ones designed for you. If you purchased a WideFS key from SimMarket, then to download it you would have followed a link to the correct download area. There you would have seen that the active part of "WideFS7" is actually included in FSUIPC4. Your registration key unlocks it -- in FSUIPC4. The Network-connected client PCs run a component of WideFS called WideClient, and that same website you would have gone to tells you to download he WideFS package (whatever version) to get that client. WideClient.EXE is compatible with all versions of the WideFS server ("WideServer") from #1 to #7. You can download he package here, in Download Links, where you will see The complete package (the first one above) includes WideServer.DLL, which for FSX and later you discard. The main reason you need that package is for the documentation. Sunbsequently you only ever need updates for FSUIPC and WideClient, because it is very very unlikely that the main WideFS documentation will ever change. Hope this clears up your confusion? Pete

First of all you do always really need to state the version number of FSUIPC. Regarding your point 1, you need to be clearer. There are 4 set buttons. Please describe what you are doing. There is no way FSUIPC "ignores" a value if you are doing the correct sequence -- follow the numbered steps in the User Guide for correct calibration. Point 2 is also meaningless. Of course all boxes have default initial values. The top left SET button is the one which enables calibration, after which it changes to RESET enabling you to cancel calibration. Only the SET buttons above each calibration value transfer the current IN value to the box(es) beneath. That's part of the process of calibration. A slope of +15 gives the flattest initial response (virtually no change at all for initial movement) but extreme response the other end -- it has to to cover the range needed. It is -15 which will give you a "hair trigger". What does that mean? Pete

First see the FAQ subforum thread entitled "Fixing joystick connections not seen by FSUIPC". If that doesn't help, perhaps more information would (as you don't really supply any). -- for example * Which flight simulator program? Maybe FS2004, FSX or P3D? P3D1,2 or 3? * Which version of FSUIPC? If not a currently supported version, please update first. Current is 3.999z9 or 4.949 * LOG and INI files from the FS Modules folder are relevant. You can paste their contents into a message here. Pete

Hmm. I don't anything about "symbolic links", but if they are supposed to be handled invisibly by the operating system they shouldn't make MakeRunways fail. I'll need to have a look at that -- but first I'll have to find out how to make such links. Pete

I need to see the lines preceding this error to get the context -- from the place which identifies the file being processed at the time, Also, I need you to b using the current version, 4.694, so it relates to my code as it stands now and I can use the details being logged. I might also need the specific BGL file which causes it. I would strongly suspect a corruption in the file, but whether it is or not I need to safeguard against it. If you wouldn't mind ZIPping that and sending it to me, do it as an attachment to an email to petedowson@btconnect.com. Meanwhile, see if it works okay with that particular BGL file renamed or removed (you can just rename it as say .BGX in stead of .BGL). Pete

Try the upper slope that is flat (horizontal) on the left, but steep on the right to compensate (so you still get the whole range). The flattest part is very slow indeed. Pete

That message does sometimes crop up when FS/P3D is reloaded whilst the previous process is still running. Normally FS / P3D won't start -- saying there's another copy already running -- but it seems sometimes the SimConnect DLL loading precedes that check and it is FSUIPC which detects that it is already running somewhere. The only solution to a hung FS / P3D is to terminate it via the Task Manager before loading it again. I'm strongly suspecting a problem still in P3D3.1, probably related to SimConnect. For P3D version 3 I had to stop FSUIPC executing a "SimConnect Close" as part of it's tidying up dring close down. I never had to do that for P3D 1 or 2 nor in any version of FSX. The fact that you are only getting it when WideFS is enabled might point to the hang occurring in the Windows TCP/IP driver levels, as both WideFS and SimConnect use these internet protocols. I'm afraid I've no solution and I cannot make it fail with WideFS enabled here at all. But it does fail to close properly about 50% of the time if I let FSUIPC execute a SimConnect Close. I've reported this to L-M but so far they've not been able to reproduce it or fix it. Perhaps you need to supply your evidence too? Incidentally, there's absolutely no difference in the FSUIPC WideServer code on any of the platforms FSUIPC4 runs on. In fact the code is identical to that in the WideServer.DLL when it was separate, in FSUIPC1/2/3 days. Once I got it working properly I never dared to make any real low level changes as I knew (and still know) precious little about Networks! The code for the Networking was copied in bulk from Microsoft SDK examples! The log file from FSUIPC won't tell you anything if P3D is simply hanging when WideFS tries to shut down. There's nothing it can log. The thread shutdown is just a simply call to Windows. If it doesn't return then that's it. Pete

Aaaarrrggghhh indeed! I should have spotted that for sure! But us programmers, we always assume it's something complicated, never so simple! Pete

I think you misunderstand. The graphic slope depiction shows the complete output from -16384 to +16384. When a reverse zone is used the slope is kept linear for the reverse portion (the left half of the graphic) and the slope applies only to the part of the throttle movement used for forward thrust. With "no reverse zone" the left half of the graphic is completely unused because you are not allowing any part of the throttle movement to give you -ve outputs. The whole of the throttle movement is handled by the upper part of the slope, the right-hand side. This is what I meant by "you would find the slope occupied the whole range." Try it. Try completely flat at top and then bottom (or the right hand half) and see how the output numbers remain fixed or slow for much longer at that end and how fast they change at the other. Of course I'm assuming assume that by saying "mine isn't working" you only misunderstand the graphic, and not that don't like the actual result of what you've set? Or did you really have some problem you meant to report? Pete

I see you posted a similar request in the FAQ subforum, which is not a Forum for support or requests, but a repository for answers to frequently asked questions, as are most places headed "FAQ"! The list of offsets directly set by FSUIPC, rather than other programs, is provided for you as I pointed out. I really do not have time to make one in CSV form. You'd have to do that yourself. However, if you look at the FSInterrogate package in the SDK you will see that Pelle Liljendal did a lot of work in that direction, creating an "FSI" file with the data displayed in his program. You could probably use that as a basis, maybe even export it from the program in a different form, but if you do please note that it is very much out of date now and still contains many errors, so you'd need to check against the official list quite thoroughly. Pete

FSUIPC is not a "task" nor does it spawn one. where do you see such a message? FSUIPC runs inside P3D, as part of its process, not separately. It cannot run separately! So, it is something to do with the Networking component of your system. Whatever you are using WideFS with, does it all work correctly? Does it do the same when no clients have connected? Have you tried closing the Clients first? I assign a keypress (CTRL+SHFT+E) to terminate the Sim and all clients via the shutdown shortcurt setting in the WideServer parameters. That's the best way with WideFS networks. With additional logging options I see. LogExtras set to 4 or 5. Why? The "stopping other threads" log entry occurs before it stops the threads for: Button scanning Axis scanning and, of course, with WideFS enabled: WideServer's broadcasting and its reception/transmission. so I can only assume something in the Network is hanging when FSUIPC tries to close down one of those two threads. Because if they are there, FSUIPC loads them. The message is only there to help folks who want to use those facilities but have not installed correctly. I've had cases where folks have installed the wrong versions (the ones for FS9). The messages are optional and you have enabled them. They are not for you to worry about! Pete

It seems the Arduino device is set to see certain conditions true on the connection -- the simulated (because it is USB?) DSR/DTR, and CTS/RTS lines. Or maybe it needs something like Xon/Xoff, some sort of throttle control? Does your serial monitor show you any difference in the initialisation between what the Arduino control program does and the Lua com.open is doing? You could try changing the handshake parameter in the com.open. Or else sending an XON byte. Might be useful to check the Arduino documentation as well. Pete

It was there within 20 minutes or so of the separate one! Didn't you see it? If you've previously installed 3.999z8 or z9 then you have everything in any case. You don't need to re-run the full installer. Pete

Yes. Once your code enters third party options, in this case the DLL you are connecting to via luacom, I'm afraid it's outside my knowledge and capabilities to help. Maybe the provider of that DLL can help you diagnose whatever is going wrong with the connection? Pete

You have if datastring == "A45" but the string you are receiving is never == A45!! In the event.com you set the terminator to 10 (=0a). That is included in the returned data, and of course so is the preceding 13 (0d). Try this: if datastring == "A45\r\n" Similarly for the other. (\r = return, or 0d == 13. \n = newline, or 0a == 10. Alternatively you can use \013 and \010). If the A45 message and A46 message are arriving with no gap, as you seem to imply, then you may need to keep reading in the function too -- I'm not sure whether the the event would trigger again until more (separate) data is received. Try first, but if necessary, rather than process the datastring/length supplied, loop doing the com.read(ArdComPrt, 10, 1, 10) call whilst it still returns data. Pete

Why do you think the code has 'stopped' rather than the connection to the hardware device(s)? If you restart the Lua plug in, does it work again? You can assign a key press or button ot start it -- the existing one will be terminated and the plug-in loaded and started again). You can use the Lua trace/debug checkbox on the Logging page to get a line-by-line and variable-by-variable log of what the plug-in is doing. So your code is reading stuff over a Network connection? Or is there a separate driver doing the Network bit? Pete

Okay. Yes, it is correct that flight controls in larger aircraft need hydraulic pressure -- except possibly when they are "fly by wire" like the Airbuses where I expect it may b all electric. I am surprised the add-on aircraft needs FSUIPC to work the systems correctly. Maybe it's a converted FS2004 add-on? Pete

You posted a similar question 4 times in a short period! You MUST allow time for your post to be seen and answered. Sometimes I am not at my computer, but sleeping or having a meal. Not often, but you need to be more patient. Anyway, sorry, but this is certainly not a question about FSUIPC, but about ProSim and Opencockpits, neither of which are my products. FSUIPC may or may not be involved at all. I don't know. With my Prosim setup and cockpit all of the overhead is driven by my own programs, not by Prosim, and I do not have any Opencockpits hardware. Prosim interfaces to all my indicators via my own special FSUIPC offsets. This certainly won't apply to your setup. Try the Prosim support Forums. I'm sure you'll get a lot of help there. Pete

I don't know of any other reason why a window would not appear on screen, only that the saved coordinates are off-screen. You could try manually adding a section to a FLT file then loading that flight. Here's a typical [LUA Display] section for a .FLT file: [LUA display] Undocked=False ScreenUniCoords=500, 500, 1000, 600 UndocCoords=0, 0, 0, 0 and P3D (for a .fxml file) <Section Name="LUA display"> <Property Name="Undocked" Value="False" /> <Property Name="ScreenUniCoords" Value="500, 500, 1000, 600" /> <Property Name="UndocCoords" Value="0, 0, 0, 0" /> </Section> The coordinate numbers are in pixels, x, y, cx, cy where x, y = top left corner position in FS screen or window, x from left to right, y from top to bottom cx, cy = size of window. It would be invisible if the x, y position is negative or greater than the FS window size. One other thing occurs to be and that is transparency. I've never used any transparency setting, but maybe this type of window is subject to some other parameter somewhere which has been set to 100% transparent? You could ask over in the FSX Forum on AVSIM about that, or maybe look through the FSX.CFG file. Yet another thing to check. Do you see the Flying Tips window at all? Maybe you have those disabled. Try enabling them. There should already be a [Flying Tip Window] section in your FLT files. Pete

You need really to state what Flight Sim you are using. The position of the Window will be stored in a section in whatever saved Flight File you are using. The section will normally be [Lua display] for FSX, or <Section Name="LUA display"> for a P3D fxml flight file. They are equivalent. Same goes for other types of overlaid windows, maybe with other names. The section will have an undocked "true" or "false" value and two sets of screen coordinates, one for docked one for undocked. You can change those, or just delete the entire section to make the position revert to its normal default. Pete

Okay. Please now download the 3.999z9b version from the Updated Modules thread in Download Links. I'll update the full Install package tomorrow. Pete

I asked for the Order number, not your own secret key. If thet's now been distributed all over the place I will have to make it null and void! NEVER publish keys to any software anywhere in public. I see that it was purchased this month, in 2016. I'm wonering if the current version of FSUIPC3 actually expired at the end of 2015. I'm checking and will let you know. [LATER] Yes! Looks like I never expected FSUIPC3 to still be purchased a full 12 years after it was first released! Amazing! I'm building an update with the expiry year moved to 2025 ... should be enough, I hope? Look out for version 3.999z9b. The DLL only will be released first, in the Download Links subforum above. You only need to place it into your FS Modules folder. No need to re-register. I'll let you know when its up. It'll take me a few minutes ... Pete

Well, not according to P3D it isn't -- the Simconnect variable reporting the sim rate is still 1. These are the only entries and the variable never changed: 30094 Monitor IPC:0C1A (U16) = 256 39000 Monitor IPC:0C1A (U16) = 1 39000 SimRead: 0C1A="SIMULATION RATE" FLT64: 1 39016 Monitor IPC:0C1A (U16) = 256 and 128000 Monitor IPC:0C1A (U16) = 1 128000 SimRead: 0C1A="SIMULATION RATE" FLT64: 1 128016 Monitor IPC:0C1A (U16) = 256 For the offset 0C1A FSUIPC converts value 1 to 256 for compatibility with previous versions of FS when the sim rate value was 256 x the actual rate, thus allowing 1/2, 1/4 etc rates in a simple integer. Does the clock speed up 2x or 2.5x as well? Why haven't you updated to P3D3.1? It may well be some bug in 3.0 only. L-M wouldn't be able to reprodcue it if it doesn't occur anyway now. Of course not. I never thought it was. I only suggested using logging to try to help you nail it down. FSUIPC doesn't do anything when unregistered except obey application programs which interface to it. And there are no Events being sent which ask P3D to change the sim rate. BTW, your frame rate is extremely variable, with a very high average: Minimum frame rate was 13.9 fps, Maximum was 835.0 fps Minimum available memory recorded was 2170Mb Average frame rate for running time of 554 secs = 50.9 fps Are you sure you are not observing stuttering frames followed by fast catch ups with buffered frames in the video system? You should aim for a smooth frame rate. Try limiting it to 30. See if that helps. Maybe more, but 30 is a good start. Also, this part is of some concern: 127844 **** SimConnect Data Stalled! Re-connecting now ... **** 127938 SimConnect_Open succeeded: waiting to check version okay 127938 Running in "Lockheed Martin® Prepar3D® v3", Version: 3.0.3.0 (SimConnect: 3.0.0.0) 127938 Initialising SimConnect data requests now 127938 FSUIPC Menu entry added There's something odd there because FSUIPC is starved of data from SimConnect for longer than it's timeout of 1 second (default). It expects data on every frame, or certainly several times a second. Not sure what you have going on there. Pete