Pete Dowson

Moderators
  • Content count

    31,640
  • Joined

  • Last visited

  • Days Won

    61

Pete Dowson last won the day on March 7

Pete Dowson had the most liked content!

Community Reputation

108 Excellent

4 Followers

About Pete Dowson

  • Rank
    Advanced Member
  • Birthday 08/27/1943

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male
  • Location
    Near Stoke-on-Trent, UK
  • Interests
    Flight Simming, Steam Railways, Table Tennis

Recent Profile Visitors

17,109 profile views
  1. It means that, although there are known AI aircraft in the air, no updates have been received for their positions for too long a time, indicating possibly that, due to overloading, SimConnect has stopped supplying them. It is a better, more efficient way, than re-initialising the entire SimConnect connection which can cause slight pausing due to the sheer number of Sim Variables being re-requested. From what you say it seems that even restarting the traffic scan doesn't help get it going again. Are you perhaps using a PMDG or FSL aircraft? They are known to be very substantial SimConnect users. RC4 uses FSUIPC to get AI traffic data, so it is going to suffer if FSUIPC does. I think PF3 probably does too. To see if SimConnect itself is failing to provide it altogether you'd need some other, non-FSUIPC program which reads AI, like Super Traffic Board, FS-FlightControl, or ProATC/X. Oh, or maybe just the free AI Traffic Limiter utility (AirTrafficManager? Or AirTrafficControl?). Pete
  2. I should think that this would be a possibility. It might be better to monitor the vertical speed or acceleration if you need such information. You might need to experiment. Pete
  3. That cannot happen. Whilst the thread created for your plug-in is running, no events will be checked for your plug-in. The event, when it occurs, is simply flagged in an event list for your plug-in, and those flags are checked in-line, within your plug-in's thread, when it exits the function. Also events are not queued, you only get one call no matter how many times the offset changes whilst your plug-in is executing the function. Pete
  4. The first one will be called and when that exits, the second may or may not also be called, depending on the state of the offset by then. You never get more than one thread per plug-in (unless you use so rather esoteric external Lua libraries, not supplied with FSUIPC). Really it is not logical to have two for the same event. However, taking your question literally, the swecond function doesn't need to terminate the first because the second one cannot run whilst the first is still running, so when it does run the first is already terminated. But taking the question the way you might have meant, you stop an event function being called by using the event.cancel function. But best, and more logical, you should declare only one function for the event, and then, when you want to change which function to call for the next such event, before exiting, use event.cancel then event.offset within the code in the first function. It won't be called until the next time the event is signalled. Pete
  5. Yes, that's the certain symptom of a video driver problem.. Pete
  6. Well, that sounds strange. If PF3 uses FSUIPC how could it not be compatible with it? That's rather self-contradictory. Make sure there is no FSUIPC.DLL also in the main FS folder, or FS may load it there. It must only be in the Modules folder. Otherwise this normally only ever occurs if you have FS still running, as a process, from a previous session -- i.e. it has hung, after closing its Windows etc. Use Task Manager to find it and end it so you can start another session. Something you are running is causing FS to hang on closing instead of closing properly. FSUIPC3 is no longer being changed and has been the same, stable and working program now for many years. Your problems are somewhere else I'm afraid. Pete
  7. That's a video driver problem. Try running FS9 in Windowed mode and you'll see. See if you can update your video drivers. Usually what happens is that the dialogue gets drawn BEHIND the full screen FS9 window, so you don't see it. That sounds like a VERY serious driver problem, then. You should be able to just press escape to exit the dialogue. All FSUIPC does when you select it is open a standard Windows dialogue -- using all standard Windows functions. There is no fancy code, it is very basic Windows calls only. If PF3 is supposed to work with FS9, then, yes, of course. Does PF3 use FSUIPC at all? If it does and if it is okay with FS9 then it is certainly okay. If it doesn't use FSUIPC then the question isn't relevant. Pete
  8. As you can see from the .h document and others in the PMDG SDK folder, the data is mapped in SimConnect as "Client Data". FSUIPC simply asks SimConnect to be told of any changes to the data for the three PMDG aircraft. Client Data is identified by a uniquely registered name. Once registered to receive such notifications, the whole data area is accessible. FSUIPC just copies whatever has changed into the FSUIPC assigned offsets. Data isn't polled or requested separately. It just arrives when it is there because FSUIPC asked for it, once, during initialisation.. I don't have any PMDG aircraft so I've never used it. The facilities and mapping for all three aircraft have been checked for me by users. Pete
  9. As I already said, the PMDG controls are all listed in the PMDG documents for your aircraft. I don't use PMDG so I can't tell you what custom controls do what, you have to work it out yourself from the information PMDG provides. Haven't you yet even looked in the SDK folder in your PMDG aircraft installation? There'll be a file there of type ".h", and the controls are all listed at the end of that. I cannot support PMDG products -- that's their job. What I've done is provided a way to use what they provide. You work out the correct control number and parameter, and use them in the <custom control> assignment facility in FSUIPC. Pete
  10. The one called "AP Master" is the AP toggle switch control for most aircraft. Some add-ons may use different methods. For FS controls like this one you can find the correct name (as used by FS internally) by enabling Event logging in FSUIPC, operating the control by mouse or FS short-cut, and looking in the FSUIPC Log to see which control name (and number) is logged. Custom controls are mainly used by PMDG aircraft, and the values have to be derived from the documentation in the aircraft-specific SDK installed for those aircraft. Pete
  11. Test with a default aircraft. Maybe PMDG have programmed in some realism -- maybe uneven wear and tear on the engines and controls. Always test things with default aircraft. No idea. But you should also realise that analogue inputs are rarely exactly the same every time no matter how precisely you position them. I don't understand why you insist on them being aligned perfectly, it isn't a realistic proposition. If you really want exactly the same inputs to FS for every throttle position then use the Throttle Sync hot key method. Then, when that's engaged, FSUIPC copies throttle 1 to all engines and it won't matter where the others are. Pete
  12. What indicates "hot brakes"? There's certainly nothing in FS which will do so, and since FSUIPC only handles FS values, it is impossible for FSUIPC to have anything to do with it. If PMDG have programmed in code for simulating hot brakes then they are the only people who will know why and how to fix it. FSUIPC itself doesn't do anything. It certainly doesn't do any braking. it does no throttle changing, no yoke moving, no rudder, no nothing. It only obeys what you tell it to do. If you have assigned brakes in FSUIPC or in FS and then calibrated them wrongly, whether in FSUIPC or in Windows Game Controllers, then they may well be applied even when you aren't pressing them. It is up to you to calibrate them correctly so there is no braking with your feet off the pedals. Other add-on companies seem to always blame FSUIPC because it's an easier get out for them rather than applying themselves. Pete
  13. You'd be better off posting in Paul's own subforum (above: the one for the .NET DLL). I'm not sure how you (or the .NET DLL) are handling the requests, but provided the 40 requests are all sent by one Process call, that that's a pretty negligible load, especially at such a low rate as 10 per second. There are plenty of FSUIPC clients doing a much larger batch of requests much more often, even up to 50 times per second. Maybe he's running your application on the same PC as FS and that is either short of memory or the extra processing on the same processor is affecting performance. There's no free lunch in computers. There's just so much power and memory available and when overloaded you are going to notice a degradation somewhere. Pete
  14. Yes, this is the problem with analogue inputs, especially generated by cheaper potentiometer devices. No two are ever identical. If the positions aren't too dissimilar you are actually getting something which is quite realistic as the types of control in the real aircraft are rarely the same after a while -- especially those like the older Boeings using mechanical and hydraulic links. Yes. There are facilities to calibrate them at more points than just minimum and maximum thrust. Please look in your FSUIPC User Guide, refer to the section called CALIBRATING MULTIPLE THROTTLE, PROP & MIXTURE AXES TO "LINE UP", on about page 50. Pete
  15. Thanks. The log shows why the previous versions didn't get the MFDs: 312 Checking: \\?\hid#vid_044f&pid_b351#8&31a00d26&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} 312 Usage=5, UsagePage=1, =Game Controller 312 Product= F16 MFD 1 Up till now all the joystick type devices I've seen the Usage number for have been 4, not 5. I extended to allow 5 as well as a result of researching these on the Internet. I think the numbers were extended quite recently. Anyway, I've released FSUIPC 4.964f as a general interim release now. Thanks for your help! Good. Thanks for the confirmation! Pete