Pete Dowson

It doesn't matter where you have FSUIPC4 nor on how many PCs. When you buy your Registration Key, that's what you get -- a Key. You enter it into the Installer along with your other details. Please do read the Installation and registration documentation which comes with the FSUIPC Zip! FSUIPC has NEVER required you to be on-line, and in fact it has no internet connection built into it at all! I think you ought to download the file and read something about it first without making such daft assumptions which i find rather offensive. In any case you should always check things out in any case BEFORE paying for anything. You can do that quite easily. Download the file, read the Installation guide, install it on whichever machines you wish. Read the documentation. Only then decide if you want to buy a Key. Don't waste your money if you don't need to buy it! :roll: Pete

Only if it is loss of operation of buttons or dials programmed in FSUIPC. That could be due to a possibly too short timeout on the Joystick response, one which was included in FSUIPC 3.96 for the first time. One solution was to extend the timeout in the INI file, but the better one now is to simply replace the 3.96 DLL with the update available here, in the Updates Announcement. If this potential problem does not explain what you are seeing then I'm afraid I don't know what could cause it. As far as I know the radios in the PMDG aircraft are still the default FS built-in radios, so test with a default aircraft. If the radio stack works on those, then you may need to contact PMDG support instead. Regards Pete

The numbers for each joystick are assigned by Windows, not by FSUIPC. The only way to get them changed is to plug them into different USB sockets. A much better alternative is to use the facilities to letter the joysticks instead. Then they will auto-reconfigure if you move them. FSUIPC matches the names to the letters and uses the numbers assigned by Windows, as it must. Regards Pete

Sorry, I don't understand. GFdisplay operates by offset values. If your macros affect offsets, the answer is yes. If not, then no. Does the LevelD use the default Battery Master switch? Monitor offset 3102. If that doesn't change, how can the offset? Test with a defalut aircraft (ALWAYS test with a default aircraft). Incidentally, instead of GFDisplay for GoFlight display control I've shifted emphasis to Lua plug-in control. Much more flexible and (I think) easier to understand. There's a complete library of functions "gfd" for programming GoFlight stuff. And you can certainly call Lua plug-ins from Macros (and vice versa). Regards Pete

After I wrote that it struck me that there's another alternative, which might still work well with your 10Hz poll rate. What if I allocated another 8-byte offset to a copy of the elapsed timer value at the time I received the lat Lat/Lon update from SimConnect? It isn't as good as a timestamp FROM SimConnect, but it's as close as you are likely to get. Let me know. It isn't difficult and I can add it tomorrow (Friday) if you want to try it. Regards Pete

What is it you don't understand? I can comment on code you've tried to write, but I don't write code for folks. it is much better if you try to do it from the information provided, and comment on what you don't understand, and show your code for additional assistance. Not that i would know enough about VB.Net, of course. Regards Pete

You select the text you want to quote then use the "Quote" button above, the one after B for Bold, I for Italic and U for Underline. Actually it was I who suggested you needed that. Unfortunately there's no way you can get that from FSX. Normally the best results would be a poll rate exactly the same as the frame rate. To get that you need to lock FS's frame rate to a value that it can always maintain. Probably less thna 20Hz, in other words. The time you read and the Lat/Lon you read would then always be correct SOMEWHERE in that frame period. you'd need to smooth the data for variationsd within it. Don't compute "instantaneous" GS, that is meaningless. I don't think even real aircraft systems would do that. You'd use a value smoothed over the last N readings, where N allows the time considered to be extended over a reasonably period, like 500 mSecs or even a second or so. That actually may be slower than you think, not because of the data parcel size but the way things have to be sought and put together internally. It is usually best just to ask for what you need, only reading interim unwanted stuff when it genuinely is trivial and small, and even then you might be surprised. The overhead is only in the Process calls, not the processing inside FSUIPC of the different read/write calls. True, as far as I've discovered. If you find out differently please do let me know. There may be a difference, but it would be one you could deal with via FSUIPC in any case. You say you are only reading at 10Hz. This means that the time difference between the Lat/Lon you get and the elapsed Timer could often be at its maximum. If you read a LOT LOT faster but only took notice when the LAT/LON changed, I think you might achieve much better results. SimConnect only sends FSUIPC the LAT/LON when it sees it changed. If you are reading fast enough you will get it "hot off the press", and therefore more likely to tie in with the time you read. For a local EXE program interfacing to FSUIPC you should easily be able to achieve 25 to 40 Hz without any noticeable deterioration in FSX performance. But another alternative it to write your program as a Lua plug-in, which runs as a thread in FSX's own process and could achieve much faster rates. Try, for instance, the "display Vars" Lua demo program. Play with its "sleep" constant. FSUIPC's Lua support provides luasocket and of course the full file and io libraries, or you can link, using Lua module facilities, to your own C/C++ DLLs, as you wish. Hmm. Not sure why that would be any better. And of course it doesn't take into account FS's variable elapsed time, pausing, and sim rates. That's basically the same as 3374, which is simply the last "GetTickCount" which FSUIPC executed. No different. Everything is almost exactly the same. Regards Pete

Well, I use RC4 too and have no problems. There is certainly no changes which affect anything RC needs. Are you using hardware to change to radio frequencies -- a joystick button or similar? If so, are you sure it changes? You may be one of the few users who get timeouts operating on some joystick devices. Try the interim update available in the Updates and Other Goodies Announcement. 255 is correct if everything is in order. That is hex FF (all bits set in a byte). Bits missing would indicate (to me) a possible problem. Traffic file listings are provided so that traffic file references in programs such as TrafficLook can point to the file containing the traffic. They were a very useful entry in the FSUIPC3 logs. Sadly I cannot do that in FSUIPC4 (FSX). The log you provide is for 3.93. why? What's the point? If you have a problem in 3.96, surely that would be the relevant log? Regards Pete

I'm afraid you cannot blame FSUIPC for "freezing radios". FSUIPC has nothing whatsoever to do with how FS processes the radios. If you are actually referring to inoperative hardware buttons or dials programmed through FSUIPC, then that is a totally different matter -- you are mis-reporting tyour problem. Please just download the current interim update from the Updates and Other Goodies Announcement in this forum and try again. Regards Pete

Okay. Thanks. No, it needs both parameters if there's no broadcast details. I forget now why I did it like that. I suspect it dates back to the days when IPX was the default. Regards Pete

Is this as an exercise? The Ground Speed is provided by FS and readable in an FSUIPC offset. What show is it stopping? Won't the provided GS do you as a substitute? It is the one FS computes after all. The problem in FSX is that FSUIPC4 gets these values from SimConnect, which sends them via a Pipe (or via TCP/IP in FSX base or base+SP1). They arrive asynchronously. The elapsed time is read by FSUIPC from a gauge token, so it is pretty near synchronous. Depending on your "sleep" interval you will get varying values, especially with a processor under any significant load, as things work through at different times. The longer your sampling interval the more the value will be smoothed of course. The shorter, the more variable. I'm assuming you request all the items of data in one FSUIPC_Process call. If you don't they will likely all be related to different frames, even, let alone slightly different times. For highest accuracy what you really need is a timestamp on the SENDING of the specific data from SimConnect to FSUIPC. I did request this, and it was on the list of things "to be done" in SimConnect, but the originally planned quarterly updates to it never came about (everyone moved onto FSXI), and of course then the team was disbanded. Regards Pete

Thank you very much. Some of these aren't necessary. For instance " FSUIPC4 Key is provided" isn't needed if you don't want to use FSUIPC's user menus at all. WideFS can be purchased and used without FSUIPC4 being purchased, though I admit it isn't usual. Whilst it is much easier if Client and Server are in the same workgroup, in some folks' implementations they don't want this for some logistical reason. If they aren't in the same workgroup they can still connect them by supplying ServerName and Protocol in the client INI file. The problem without the same workgroup being used is that the Server's broadcasts, telling client where it is, don't get through as they only broadcast withing the group. Naturally, with your item 4, any future version of FSUIPC4 would apply too. The current update version is 4.575 already, so it won't be that long till 4.57 is out of date. Maybe an "or later" would be a good idea? Perhaps, if would like to tidy it up a little, and put your details on it, you wouldn't mind if I turned it into a PDF and put links to it here, or even included it in the WideFS and/or WideClient downloads at some point? If you want to send me anything, use petedowson@btconnect.com. Thanks again & Best Regards Pete

Correction! I just updated my GoFlight software to version 1.93 build 12, a very recent pre-release from GoFlight, and it seems that the trims CAN after all be configured for FSX (and FS9), with one of the options being "no selection". I don't know when this changed, maybe I was out of date -- check your version and/or look out for an update on the GoFlight website. With such a facility you can certainly set the GF driver to "no selection" on the trim wheel and then program that in FSUIPC. Not that in FSUIPC you will find the wheel looks like 4 buttons -- slow and fast in each direction. So you could assign the slow ones to single ELEV TRIM UP/Down on "press" only, and the fast ones to the same controls on both "press" and "release". They will give you two speeds. And yuo wouldn't need to worry about programming the gear lights. But first see if adjusting GF's own "Trim control Gain" gives you what you want. Regards Pete

Right. I've found and fixed both "snags". These were both very long-standing bugs and I'm surprised no one's reported them before. They apply to FSUIPC3 too. I've uploaded the fixed versions (3.964 and 4.575) to the "Updates and other goodies" announcement above. These are the changes noted for your snags: Thank you very much for your clear and concise description of the problems. Regards Pete

Is that the LGT or LGT2? The one with one or three trim wheels? If it is an LGT, using the GoFlight driver, I think it simply sends ELEV TRIM UP and ELEV TRIM DN controls, depending which way you turn it. They should provide the same sort of operation as using the trim keypresses (NUMPAD 1 and 7) as they are the same controls. What is the actual problem? Too slow, too fast, or erratic response? No. Mouse macros are for programming buttons to operate some types of gauges on screen which otherwise can only be accessed with a mouse. That never applies to any normal FS control. Where do you note that from? Naturally, if you want the operation of a button, dial or lever to be acted upon only once, as you would, then only one program should be reading it and acting upon it. Unfortunately, I note that, in FSX at least, the "GFConfig" program GoFlight supplies for configuring their devices does not actually allow the trim wheel(s) on the LGT to be freed from GF control. So, the problem if you tried to program the device in FSUIPC would be that both FSUIPC and GFDevFSX would be responding. So, yes, you would probably need to stop GFDevFSX.exe from running and use only FSUIPC. But this means using FSUIPC for everything you have from GoFlight -- the GFDevFSX.EXE program provides the interface for pretty much everything GF as far as I can tell. This isn't so much a problem for all of the inputs (they will all look like buttons to FSUIPC, and can be programmed directly in FSUIPC's Buttons and Switches tab), but there is no associated default handling of GF displays and indicators in FSUIPC. Even if the LGT is the only GF unit you have, it still means programming the three Gear indicator lights correctly. GF display handling used to be done via an extra program I supplied, GFDisplay. It still can be -- by all means investigate that if you are interested. Nowadays, though, for GF units connected to the main FS PC, I'd recommend using Lua plug-ins. There's an extra function library available to Lua plug-ins calld "gfd" (for GoFlight display) which can handle everything GF offers. But it does involve a level of basic programming. I do see that GFConfig can adjust the "gain" on the trim wheel(s). Have you first attempted to adjust that to your satisfaction? "SDK" stands for "Software Development Kit", and it provides the resources that application programmers need to interface their programs to FSUIPC. The only part of it which may be of interest to users is the document detailing all of the FSUIPC offsets, as these can be manipulated directly by assigning "Offset" controls to buttons or keypresses. Regards Pete

Hmm. No, I didn't know UTX had its own scenery entry. Most AI programs put their traffic BGLs in the same folder as FSX, the Scenery\World one. I've always been a MyTrafficX user on FSX till recently. Now I use UT2 + MytrafficX, with the latter filling in the flights UT2 doesn't provide. UT2 injects the AI Traffic via SimConnect, it doesn't use BGLs so there's no Scenery layer for it at all. It seems very odd that a scenery area which FSX wasn't loading in any case (because it says it's missing) can cause a subsequent error in any part of FSX, let alone FSUIPC4. Hmmm. Regards Pete

Since at present we have no idea whether the problem is in your Network or in PM Instructor, the first thing to do is find and show the WideServer and WideClient log files. They will tell me if there's a Network problem. If there is not, you'd need to talk to PM support, not me. Of course, I am assuming your FS installation is okay too. Perhaps I would also need to see your FSUIPC log to check that too. Regards Pete

I don't think sowhen you attempt to write a file to a full disk the error is returned to the program. Because I log errors I cannot afford to log an error in the logging (infinite loop!), so logging errors are ignored. That's rather intriguing. How did you determine the "appropriate" area of scenery? Could you tell me more -- which scenery was it? Could it possibly have been one with "active scenery" operations in it, perhaps serviced by "Actigate.dll" or similar? Thank you for the information, and any more you can provide. Regards Pete

Please send me an email: petedowson@btconnect.com . Thanks, that's nice to know: it means my own SimConnect operations are very efficient! Very pleasing! ;-) Regards Pete

Yes, that is an efficient way for separate Lua threads to talk to each other. Well, that's possible, of course, but it isn't really as tidy as having them talk to each other via Global variables. It's done by the ipc.macro() function, so: ipc.macro("LuaKill failure") Regards Pete

Okay. There is most certainly a SimConnect problem: It appears you have FSX + SP1 installed, but the SimConnect part of SP1 is botched, somehow. Although it appears to be installed, only the Base version, 60905, is responding. And that cannot operate correctly with the SP1 code of FSX, hence the error C0000120, which is "request cancelled" -- FSX is not allowing the incorrect version of SimConnect to talk to it. I think you first need to uninstall SP1, re-boot, re-run FSX, close it, re-install SP1. Then try. If that doesn't fix it you may need to do a complete uninstall and re-install of FSX, though that sometimes introduces its own problems. Maybe a better course of action would be to install SP2 (or Acceleration) and bring FSX up to date. There are lots of FSX bugs fixed in SP2 and most things run more efficiently then in any case. Regards Pete

I know, but I asked to see the file which you had obviously referred to, yet it didn't appear. The log shows that your FSX installation is indeed on the D: drive, and that's where the installation was performed, and it shows, correctly, that the reference to the C: drive was in order to install the correct parameters into the DLL.XML so that simconnect would load FSUIPC4. There's no sign at all of any inability to find FSX.EXE nor FSX.CFG, so I really don't understand where you got this from: Additionally, it looks like this is an Install log for the first, or only, time you ran the Installer for version 4.57, as the previous version was clearly still there, namely 4.20, as shown here: Yet you said you tried to install again, at least once more. If so, then the Install log would show 4.57 installed. So, are you not showing me the latest Install log, but one you saved from days ago? Anyway, the crux of the matter now is this: I searched for the error 80092026 using Google and found that it means The cryptographic operation failed due to a local security option setting I suspect that if you did as my documentation beckons you to do under such circumstances, and checked the signature on the installed FSUIPC4.DLL manually via its Properties you'd find this out yourself quite quickly. Now I've never come across this error before and so I don't know what setting you have which could cause it. I know that if you stop some of the cryptographic Services running then you will get a failure similar to this, but I don't think it is this one. The report I found on Google did suggest one solution. Check http://blog.stealthpuppy.com/windows/wiion-failed In summary: I think something you or a program has done has made a Security change to your installation, including anything with a new Certificate (version 4.20 was using a Certificate in my name, which expired. Since version 4.50 the Certificate changed to SimFlight). Regards Pete

Hmm. Strange. I'll check into that. Really? That is really wacky! I'll look into it. Thanks. Regards Pete

Thank you. But why won't you show me the Install log? All the information needed to resolve an install problem is logged. This is why it is produced and why I asked for it. I don't understand your problem in showing it to me! It is self-defeating! Okay. This means that FSUIPC is installed, but that the copy which is installed fails the signature check which guarantees its validity. Additionally, without a valid signature FSX will refuse to load it, giving an error too. As described in the Installation guide you can check this yourself -- right-click on it, select Properties and Digital Signature. select the signature and click on Details. It should say whether the signature is okay or not. If not it won't work in FS, and this is why the Installer tells you about it. BTW you told me the error had not changed, yet your last report said this: Remember? What happened to that? You keep alternating between two completely different things. The install log, which you obviously found, would help immensely, but you continue to withhold it. :-( Tell me exactly where you looked please. And what name did you look for? FSUIPC's signature is in simFlight's name these days, not mine (the authorities won't issue certificates to individuals), exactly as documented if you'd care to look at any of the supplied documentation. That is utterly irrelevant. It isn't the browser aspects of IE that matters, it is only that it is the only way MS provided of easily managing lists of trusted and untrusted publishers. No, because you withhold the information requested. Actually, it sounds like it is installed, but cannot load because of the signature. And I don't understand how you'd expect things to magically change -- without fixing the problem, how would it? Pete

There's no FSX.CFG file in the correct place for the current user, the one named "Administrator". Do you run FSX under that user name? You need to install add-on programs when logged in as the user of the Flight Simulator installation. If you are doing so, it seems as if you've not yet run FSX. Else where is the FSX.CFG file? Regards Pete