Pete Dowson

I think that can be a problem, depending on how they are written. They need to be written in a cooperative way in terms of access via WideClient. If one monopolises the access the others will suffer. See if they include a polling rate or delay parameter and slow each one down to the FS frame rate, or 25 fps at most (40 mSecs per poll). If that works, try reducing the delay (or increasing the poll rate) as little at a time till you get the stuttering, then retreat a little. If you have no means of doing this then perhaps you'd need to contact the author to get him to change the way they operate. Are these gauges intended to be used in this way? Have they been tested this way by the author? If so then I suggest you talk to the author about what the problem might be. Possibly the PC they are using isn't adequate? Or they are using OpenGL or DirectX windows and only one of these is being hardware accelerated because of the inadequate operating system, video card or video drivers? If one of them is using the processor more than 50% then obviously the second will get less than it wants, and so on until they are locked out entirely. Video processing could do that as well as uncooperatively written programs. In that case, if these programs are meant to be used in this way, it is more than likely to be your hardware or the video drivers. It is not likely to be the Networking side of things if you get good data rates normally, with one application. However, do check the WideClient log file to see if any errors are being reported. Regards Pete

Does that feature NMEA or Aviation format position input? If not you are out of luck I'm afraid. Looking at it, it looks similar to a Garmin GPs i had once, which certainly did not have any way of inputting positional or other information to override its own readings. And the spec sheet doesn't look hopeful. I suspect the USB connection is merely for you to download maps and so on, and maybe upload tracks and memorised waypoints. You need to check the documentation for the device, but it looks unlikely it supports anything useful in this regard, just like both of my Garmin devices. Regards Pete

If it only worked when you did that then your two PCs were in different Workgroups -- the better way isd to always choose a name for your workgroup and remember to set it in each PC. It shouldn't have taken long. The part about workgroup names is early on in the User guide section entitled Configure your Network which also has the subtitle IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! to draw your attention to it. The part advising otherwise to set the ServerName and Protocol parameters follows, so why skip the earlier part, the easier part? Regards Pete

Sorry, I don't have time to follow links in order to understand. Is this ATR one with FSUIPC-connecting gauges? Sorry, I don't understand. You had problems with some ATR gauges and then you used someone elses software and have worse problems? I really cannot help unless you explain even just a little of what you are doing. nothing you said explains anything. Are you sure you are in the right place? I sounds to me as if you need the support of whoever's software components you are using. Regards Pete

See the Announcements -- there's one called "Updates and Other Goodies". Pete

This must be something related to the gauges themselves. You don't say what software they are using, but it seems they don't work well together. There's nothing you should tweak in WideFS. It has reached its current optimised settings over many years. I use 8 computers on my system with many programs on each one, and they all maintain the FS frame rate. You don't say anything about what these gauges are or how they are driven, but it sounds like each one is trying to keep control to the detriment of the next. Or they all try to use hardware accelerated windows and you don't have the right hardware or drivers for that. Do the gauge suppliers have any support? Regards Pete

Good! Lucky guess! ;-) Wow! I almost understand nowbut what a palavah! Okay, but they way I've done it, it should work for FS assignment or FSUIPC assignment to FS axis or old controls too. That should be checked by default, as it is otherwise a problem with several add-ons. Okay. Glad it is all sorted now .. Good flying! Pete

Can you show me that dialogue please, as it doesn't actually sound like anything i have implemented! If I do that here, i.e. cancel the registration option, it simply terminates cleanly. Well, I don't think I wrote that, but it no doubt means you don't have any FSUIPC user facilities whatsoever. Exactly as the documentation tells you. It's use is then really limited as to being an interface for applications. There are some logging facilities available to all, and a couple of options to do with FS windows used by apps such as Radar Contact. If you have not bought my product you do not get a licence for it. You bought another product which merely uses my product as an interface to FS. It has a licence to do that. Nothing if you do not wish to use the facilities, none of which are related to the particular product you purchased. If you want to know what is available, please peruse the User guide as I suggested in the first place. If you don't know whether it will be useful to you, it probably won't be. It is like a Swiss Army Knife, a toolkit. But if you don't need any tools, you don't need it. Pete

Why would I be concerned when they have paid for the access rights to the FSUIPC interface? This is why you don't need to register just to use their product! This applies to most add-ons using FSUIPC. Why don't you just believe what you are told in this instance? My "product" is FSUIPC, which in this context is used invisibly, as a window into FS, by another, licensed product, perfectly legitimately. If you want to know about FSC, see their documentation or website. I really fail to understand where you are coming from on this. I have enough support work to do without dealing with other folks' products. Please, if you are still so confused, go to the FSC support place, wherever it is. Thank you. Regards Pete

I'm assuming my guesses, above, were correct, as I cannot think of any other sensible interpretation. As time is getting short for me (I will be busy with house guests next week and over Christmas and New Year), I decided to implement an option for the way I understand it. Here's the note describing it: Assuming this is what you want, please download either or both of FSUIPC versions 3.952 and 4.558 (see the Updates Announcement), and try the facility. I'd be interested to know if this works for you. Regards Pete

The latest interim versions (not full documented releases, but just replacement DLLs etc) can always be obtained from the "Updates & Other Goodies" Announcement at the top of the Forum. Did you somehow miss it? Please do browse the Announcements from time to time -- that is what they are for, to Announce things! ;-) Regards Pete

Yes, because it is compiled on loading, not interpreted line-by-line, and the compiler stops on the first error. Best advice is -- always check the Log file, because that is where Lua error reports will be found. If you select Lua logging they will go to a separate Lua log file for each Lua program. Otherwise they'll be put into the FSUIPC log. For FSX you can run in Windowed mode with the FSUIPC4 log console visible and see the results immediately on screen. Regards Pete

Correct. It does tell you in the documentation that the name and email details must be the same for each. What did you uninstall and reinstall? Not FSX I hope? I'm pretty sure that's the cause of many folks' SimConnect problems. I don't know of any way that deleting files can help -- but if re-running the FSUIPC4 installer fixed things, you must have somehow got your DLL.XML file messed up. Many add-ons mess with that in order to get special modules loaded by SimConnect. Raising a problem ticket with SimMarket is invariably the fastest way to get it fixed. Simply explain the problem and provide all the details. They normally do this within 24 hours. Regards Pete

I've really no idea. You cannot adjust the polling rate for SimConnect, so I suppose that's a disadvantage. If all you want to do is read joystick buttons why not simply use the easy Windows "joy" API directly? That copes with up to 32 buttons per joystick -- it's what FSUIPC uses. Check "joyGetPosEx". It makes FSUIPC poll the joysticks more or less often. Whether you can read the flags as fast is another matter. You've got process switching and Windows message queues in the way of anything startlingly fast. There's not much point polling faster than you can read, so time that first. See how many FSUIPC Process calls you can do in a second before FS slows down noticeably because of the loading, or your program gets held up because of delays in the response. If all you want to do is read buttons on locally connected joysticks, I'd still recommend doing it directly, not via FS or FSUIPC. Regards Pete

Yes. That seems clear enough. FSC is a licensed FSUIPC application and it does not need a registered FSUIPC. Why do you find this so confusing? They seem to spell it out loud and clear!!! Is what limited function? What is confusing you? FSC says you don't need to register FSUIPC. Full Stop. End of story! If you want to use FSUIPC's User Facilities, pay for it. If you don't, don't pay for it. To find out what they are simply browse the FSUIPC User Guide. What is so hard about that? Wouldn't you do they same for any other product -- find out about it if you were interested, before buying it? Pete

I've reproduced your problem now on another Win7 64-bit system. I have the same problem. It looks like an update to my compiler has been applied between version 4.53 and one or other of the Increments since (e.g. such as the 4.552 update you started with) which renders the needs in MSVCR80.DLL from FSUIPC to be beyond those actually installed, even by these Redistributables from Microsoft. Maybe there are updates to those too, but I've not yet seen them. This still doesn't explain how FSUIPC4.DLL can be loaded by FSX (which dates back years now) but not by my own program. that's truly weird. Whilst I work out a solution, I think this work-around will be okay: 1. Delete FSUIPC4.DLL from the FSX modules folder. 2. Run the 4.53 instaler (from the Schiratti page) 3. do your registration. 4. Overwrite the FSUIPC4.DLL with the latest update above if you wish. Sorry about this. It has been and still is very puzzling. if it turns out to be due to some auto-updates from Microsoft I will be really annoyed and certainly will turn that feature off! Regards Pete

That is almost always due to assignment in more than one place. Check that you aren't assigning in FS as well as FSUIPC. Regards Pete

Both of thesesomehow intercept and override the normal FS throttle controls? Ouch. It does make things very difficult for any proper cockpit builds. All of the full instrumentation and external autopilot packages I know of expect normal responses to throttle controls. Of course not -- it it deliberately ignored THROTTLEn_SET controls, then it will ignore them no matter what FSUIPC options you set. But that makes no sense to me. From what you said, you need idle being sent to FS at -7500 or something like that, not -16383 which calibration there would set. You said -8000 to -16383 was reverse. Ah, so are you saying, contrary to what i previous understood, that this aircraft accepts NO reverse range on any throttle input? I was interpreting wehat you said to mean the aircraft had idle set at -7500 and reverse set at -8000 to -16383. If I understand you correctly now, my previous assertion, here: would solve your problem? you don't need a reverse zone? I did ask this here: Please do read these suggestions a little more carefully and tell me which are right which are wrong. We seem to be continually bypassing each other's suggestions & explanations! Regards Pete

After some further extensive investigation, I think a re-installation of the MSVCR80 package should fix the problem. Please remove the copy you placed in the FSX Modules folder, and download and run this package, which is the Microsoft re-distributable for Visual C: http://fsuipc.simflight.com/beta/vcredist_x86.exe Regards Pete

You didn't save your FSUIPC settings (the INI file)? Sorry, but it is followed by many thousands of other users. I can answer specific questions, but I cannot explain more clearly than I have in the documentation or I would have done so! Have you tried the other help documents supplied in this forum, mostly in the "sticky" threads above? If you did it before, you can do it again. I don't understand the problem at all. Where IS the problem? You do not describe it at all! :-( Regards Pete

All it is saying is that you exited the Dialogue options by pressing "cancel" rather than registering. That is quite normal if you don't wish to register -- if you want to register you have to purchase a key. Pete

So it is extraordinarily weird that it won't run when called from the Installer. It makes no sense at all. However, there's a little progress there I see -- we managed to change the behaviour somewhat! Which of those listed versions of MSVCR80.DLL did you use for that test? Hopefully one of the X86 versions -- none of the 64-bit versions would work, of course, because FSUIPC4 is a 32-bit module, as it must be to run in FSX. The error now reported back to the Installer (0x0000045A) is "a DLL initialisation routine failed", which seems to point to the possibility that you used a 64-bit one. If not, could you please tell me exactly which one you used and I'll try to force it here. (I don't have a 64-bit version of WinXP, only of Win7. I've tried putting a 64-bit MVCR80.DLL into the FSX Modules folder, and I get the same error as you FIRST got. So I tried putting a 32-bit version in, but that gives me the same. I'll have a think and get back to you. Pete

No, for the THROTTLEn_SET controls, 0 to 16383 is forward thrust and 0 to -4096 (or some other value, depending on the max reverse specified in the Aircraft.cfg file) is reverse thrust. For the AXIS_ controls the forward thrust does range from -16383 to +16383. They have no reverse section at all. That is why FSUIPC converts them to THROTTLEn_SET controls. It's the only way to get a variable reverse control on a lever. For instance, perhaps by using the AXIS_THROTTLEn_SET controls on page 3 if the "No reverse Zone" option is selected? Is that what you mean? The calibrations on that page already accept AXIS_THROTTLEn_SET controls, of course, as I presume you've found. Is it just that you don't want them converted to THROTTLEn_SET controls, and therefore to retain the full range, no reverse zone? Is this JUST for the Wilco A320? Seems odd that they've gone out of their way to make things so incompatible with the way FS works. Didn't I read some time back that it still used the -7500 to -16384 zone for reverse? Or not? If so, I assume you'd still need a "centre idle" calibration point, which using the "no reverse zone" option would defeat at present. Regards Pete

Sorry, I've no idea what is wrong with FSC to give you an error, so I cannot advise. I would certainly avoid reinstalling FSX unless you have to -- it seems to give more problems than it solves for many folks. Pete

Assuming the last part was the FSUIPC4 installer option to Register if you want to, then, yes, that's fine, for FSUIPC4. But you do need a registration key for WideFS if you want to use that. No idea what error 308 is -- it isn't FSUIPC. You need to ask FSC Support. Regards Pete