Pete Dowson

Please replace PFCHid.DLL version 1.34 with 1.35: PFChid135.zip. I just found a silly typo in the code which can, in certain circumstances, slow FS down, even possibly to a crawl! Hope you are making progress with the C2 Pro. If it responds now to the PFCTest GUI, please try now with this updated DLL. Regards Pete

Thanks for this. It's a puzzle then. Alessandro, if you have other add-ons or programs running, would it be possible for you to carry out a series of elimination tests? Try stopping all other add-ons and add-ins running to see if it then works correctly. If so, add them back one by one till you find the culprit. If nothing helps, it remains a puzzle. There are tools (Microsoft's own Spy++ for instance, which lets you trace all Windows messages) which might help get to the bottom of it, but they all tend to be aimed at programmers. That's why it would be best if I could reproduce the problem here, but even if I had an aircraft I could test it on, from what Chakko says, I might not see the problem in any case. Regards Pete

Okay. The small change I made to FSUIPC4 also applied easily enough to FSUIPC3, so: Download FSUIPC3999z7.zip and, yes, place it into the FS Modules folder (where else???). Again, let me know how you get on, please. If it doesn't help I'll need a way to reproduce the problem here in order to work out why. Pete

No! Sorry, I clean forgot you were using FS2004! I wasn't planning to make more changes to FSUIPC3, except for maybe serious errors. I tried to freeze it years ago, as the code is now so old (10 years!) that I hate to mess with it for fear of doing more damage than good. Also, when trying to test for your problem I was doing it with FSX, and perhaps that problem doesn't even exist in FSX. Duh! Can you tell me what aircraft I can use to test right-button dial increments? I don't think I've got much in the way of add-ons for fS2004 these days, not having used it for 8 years, but you never know. Regards Pete

I'm afraid you are misunderstanding what the TO and FROM relate to. It is nothing to do with the direction you are flying. It is the setting of the VOR radial (the CRS or OBS value). If you adjust that then the validity will change, from TO to OFF to FROM to OFF and back to TO as you turn the knob through the 360 degrees. It is this indicator which is used for the VOR TO/FROM/INACTIVE indications. Pete

For good Lua operation you'd be better off assigning the Axis to LuaValue <name of plug-in>, with the Lua pre-loaded by an [Auto] section in the FSUIPC INI. Then have an event.param calling a function which does the computation. If the axis is a standard one processed by Windows joystick drivers it should be giving you a range of something like -16380 to +16380. Whatever it is (measure it in Axis assignments), set the Delta value in the axis assignments page to something which will give you your 13 steps. Then, assuming these steps are equally spread out, the function merely needs to do one computation. eg: ADDN = ? -- Need to work this out DIVN = ? -- Need to work this out function setposition(x) pos = (x + ADDN) / DIVN if (pos > 13) then pos = 13 end if (pos < 1) then pos = 1 end ipc.writeLvar("dc9_ap_turn_knob", pos) end event.param("setposition") Once you have the full range then it's just a matter of arithmentic to work out how to adjust it (with ADDN) and divide it (with DIVN) to get a result of 1-13. For example, if the range rally is -16380 to +16380 then DIVN = 32760 / 13 ADDN = 16380 + DIVN would get you close, but would still probably need an adjustment. BTW, note that the name of the L:var is a string and needs those "". Regards Pete

Sorry, none, except that you'd probably need to calibrate the needle position to suit the numbers you get. Regards Pete

Good. Thanks for confirming. Glad you then solved the whole problem! Pete

I've made one small change, to make the control only do anything is it wasn't already operating. I don't know if it will help or not. Download FSUIPC4912.zip Let me know how you get on, please. I've not put 4.912 on general release yet. Pete

Okay. There was just enough room for two more functions, so I've added facilities to set bits and clear bits. No toggle I'm afraid, but set and clear should do just what you want. Download FSUIPC4912.zip The format for Setbits is L:name,Sbits,param, and Clearbits is L:name,Cbits,param. Note that if you use these on an L:Var which includes fractions, those will be lost -- the result is always a 32-bit integer. Let me know how you get on, please. I've not put 4.912 on general release yet. Pete

It's far easier to think in terms of one bit for each button. In your example bit 7 = autofeather, bit 2 = MTOP. Please see the FAQ subforum thread about Bits and Numbers if you don't understand bit representation. Bit use for buttons and switches pervades all of FS and FSUIPC. Forget adding and subtracting numbers, think in terms of setting and clearing bits. You can't really do it with the existing L:Var functions. You'd need "Setbits", "Clearbits" and "Togglebits" functions, with the parameter giving the mask to be logically Anded, Ord or Exclusive Or'd with the current value. This would be easy enough to implement, provided there's room in the L:Var macro encoding for me to include it. I'd need to look at the code. Currently, yes, it would be the only way. Read the L:Var, change the bits and write it back. But don't rush into anything. I'll have a look at the code first and let you know. Is this for FSUIPC4? Regards Pete

Very few user facilities are available in an unregistered install. In that state FSUIPC merely performs its original free function, as an interface for add-ons. Pete

There term "offset" is really historical. Originally the FS6IPC interface from which FSUIPC was a development provided access directly into an FS98 module called "GLOBALS.DLL" which conveniently collected all of the FS data you might want to access into one contiguous memory area. The interface allowed any of the bytes, words, etc, in this area to be read or written by reference to its offset, in bytes, from the start of the area. These days, with FS data encapsulated inside separate C++ objects and hardly ever directly accessible, the Offsets have really become just "tokens" for the data they purport to contain. It's complex code in FSUIPC which interprets these tokens and reads or writes the data in whatever way is appropriate and possible. This may, for instance, be by actually calling procedures within FS, or hooking some transactions, or even sending requests and waiting for answers. To continue giving the illusion of a fully synchronous interface, FSUIPC does actually automatically obtain all the information regularly and keeps it in its own "Offset" data area. This enables it to satisfy most read requests immediately (exceptions include weather requests for a specific WX station or location, as there are so many, and similarly specific lengthy data about AI traffic). But writes always invoke some code to do something. So, forget "memory addresses". Use offset values as tokens. No pointers. Your data in your memory. Just read the whole array(s) into your own C++ defined structure. For Ground traffic that's 3840 bytes at offset E080 (96 entries of 40 bytes) plus, if needed, the 1920 bytes at D040. Then separate arrays for the airborne traffic. Bear in mind that FSUIPC only supplies details for the nearest 96 airborne and 96 ground aircraft If you need all AI you'd have to resort to SimConnect (for FSX). You misunderstand. The Traffic Zapper added control in FSUIPC is simply an implementation of using the AI deletion facility in the SDK to delete aircraft by user request. The aircraft is deletes is chosen based on range, direction and so on. It is fully documented along with the parameters for it in the FSUIPC documentation (user & advanced guides), not the SDK. It is not something you'd use from a program to delete aircraft of your choice (unless you move the user aircraft to face the aircraft to be deleted and make sure it is in range!!) The deletion facility in the SDK is documented against offset 2900. Regards Pete

I think the problem may be simply because the MouseSwap function is simply not designed to work like that. Without doing some tests I'm not sure I can pinpoint exactly what is going on, but I'd guess the dual actions are interfering with each other, timewise. The flag telling the Mouse Button trapper what to do transitions according the the stage of button press/release and its reversal, but the "MouseButton Swap" control resets that flag, making it start again even if its in mid-sequence. Unfortunately I don't think I have any aircraft which use right-button for making values change. None of the defaults do this, do they? If I did I could experiment to find a solution. One is possibly to make the MouseButton Swap control only set the flag if it is currently off. I don't really know if that would solve the problem. Really you want a control which sets the swap 'on' and keeps it 'on' till used again -- maybe a pair, MouseSwap On and MouseSwap Off. If you have any suggestion as to how I can test things here, I'll try some things out. Otherwise I can only think is that I try some change for you to test. Regards Pete

All FSUIPC does with this option if, when it sees a Left Button message (Down or up) is uses the Windows API "mouse_event" to make Windsows simulate the right button down or up, and discards the current message instead of passing it on. This is the only correct way of doing it that I know of. The amount of code in FSUIPC doing this is just two statements -- the call to "mouse_event" and the "return 0" to exit with no message passed on. And here, on my system, the right-click action is immediate. But perhaps I'm not understanding you. When you say "between right clicks", you do realise, I hope, that the "mousebutton swap" control cancels the swap action btween each use. You have to have some button or key assigned to this and use it between each click. Maybe your delay is in pressing this control between clicks? You don't say how you are programming this. BTW the currently supported version of FSUIPC for FS2004 is 3.999z5, and a version 3.999z6 has just been uploaded. Pete

Crashes in G3D.DLL are quite frequently reported over in the FSX Forums on AVSIM. I suggest you look there. The most common one is caught and prevented by FSUIPC4 (recent releases), but there are a lot of others which can occur . As far as I can tell these are almost always due to scenery corruption, possibly only in memory caused by complex graphic needs. I very much doubt that it is anything to do with MyTraffic which I've used with no problems for year, and it most certainly isn't anything to do with FSUIPC. So, i'm sorry, but the CTD forum on AVSIM might be your only recourse for more information. You never know, someone may have had this very crash. Pete

Wow! That was virtually the first official version of FSUIPC for FSX! Even then, as you'll see if you read to the end, the problem was resolved. In an unregistered install FSUIPC4 does not intercept controls at all, it just logs them if they occur (as in FSUIPC3). An unregistered install (not "version") doesn't intercept any controls whatsever, and so can do nothing to help. The logging is a passive business based on seeing messages flowing through the FSX windows procedure. No, it's a default action. Please see the FSUIPC documents. It's controlled by the TimeForSelect parameter (described in the Advanced User's guide), and is a reasonably prominent feature on the Miscellaneous options tab in FSUIPC options (described in the User Guide), where it is described as "Time allowed for engine/door select (0 = option off, pushback turn select too) secs" where you'll see the default is 4 seconds. Pete

event.Lvar was added at version 4.85, a year ago now (August 2012)! That's FIVE major versions ago! You do need to keep up to date. Regards Pete

The reason for the option "SavePreviousFlight=Yes" was that, apparently, the act of saving a flight when things are closing down adversely affected some add-on or other. I don't recall what it was now. The option is there so that it can be turned off, but as far as I recall it is on by defalut. If not, just add the parameter. If the previous flight is not being saved even with the option allowed, then either the Sim isn't actually closing down properly -- use Task manager to check if FSX.EXE is still actually running even if it appears to have closed -- or for some reason the Sim is closing before the SimConnect notification is seen by FSUIPC. I have noticed this on a few occasions -- it is inconsistent, but I don't think there's any way around that aspect. An advanced notification was on the list of things a SimConnect update was supposed to attend to (there was a very long list of unfinished aspects of SimConnect which I had agreed with MS before Aces demise). If you have some other things going on, all waiting their turn to close properly, it usually works 100% of the time. WideFS is particularly good because that delays things whilst notifying all clients. Some other ad-ons will also be trying to close tidily. Regards Pete

Well the thing that Registration will do which an unregistered install won't is handle the situation where the add-on aircraft gauges are constantly sending FS controls. The mechanism whereby FS sees the SELECT 1-4 events after a relevant control like Toggle Pushback depends on the SELECT being the very next control it sees. If another control intervenes then the SELECTs do nothing. There are several add-on aircraft which do constantly send controls to FS at such a rate that one or more is almost bound to intervene. I think some of the PMDG ones are like that. I don't know about the CS727, but if it is doing that then, yes, registering FSUIPC wil help because then FSUIPC will hook the relevant controls, like Toggle Pushback, and re-associate them with any SELECTs thereafter as long as they occur within a certain time (adjustable I think, but the default is fine). There is one easy way to see if this is indeed the problem with the CS727. Just enable Event logging, in the Logging tab of FSUIPC. That's possible in an unregistered install as well. If the log is filling up quickly with control events occurring, then that's the reason. It will log the Toggle Pushback and the subsequent Select, and you can check whether there are intervening controls. [LATER] I just noticed that you already did the logging: That actually in itself makes Andy's original thoughts irrelevant. Sorry i didn'ty spot that in my earlier reply. But did that log show other controls intervening between the pushback and select? Pete

Same as everyone initially, but it is chosen as a simple scripting language for everyone. Have you even looked at the documentation and examples provided? There's a "HIDdemo.lua" example for reading HID devices which would be a useful start -- just plug in your device's Vendor and Product names or IDs, as instructed in the comments in that file, and try it. The names or IDs you need are easily seen in the Windows registry, or displayed in the list produced by the HidScanner utility I provide. For HidScanner refer to the Lua section of the Download Links subforum. Really no one else can program your device unless they have an identical one to do it with. I really don't think you need to simply give up so easily. Pete

I am not saying anything whatsoever about the CS727. Go and read my reply (to Andy, incidentally, not you). In all this FSUIPC is irrelevant in any case. You are really in the wrong forum. I was only giving solutions to the problem Andy mentioned. If that isn't your problem then I'm sorry, I was only trying to help! Pete

Yes of course. Why not look in the FSUIPC Lua library documentation? Did you not see the event.Lvar function? Pete

The default assignments in FS for the 1-4 main keyboard keys are "SELECT 1 ... SELECT 4", so with a registered FSUIPC he could get over it using multiple assignments to a button or other keypress, to "toggle pushback" and "select N", or even just assign 4 other keys, untrapped by the CS aircraft. Even direct assignment in FSUIPC to the same 1-4 keys might override CS's capture, depending on the order of the hooking chain. Actually, if he wants to save money and not register FSUIPC, there is a way in FS itself -- I've just checked the assignments list in FSX. Scroll down to "Select item 1 ... 4" in the Button/Keys assignments list and you'll see the assignment to 1-4. Just reassign them to 4 other keypresses not used by CS or other important functions. Regards Pete

Sorry, but with the error occurring in FSGRW, and with such an unintelligible string of data (well, unintelligible to me, anyway), I don't see how I can help at all. Is it related to FSUIPC at all? Seems to me to be an "OverflowException: Arithmetic operation resulted in an overflow.", which must surely be simple enough for them to track down? If there are no errors showing up in the FSUIPC4.LOG file then only the FSGRW folks can help. If they are simply saying "it is a problem related to Windows 8" I assume they've analysed the error report (at least they should understand it) and found a Windows 8 incompatibility? Have they decided not to support Windows 8? BTW FSUIPC 4.90 support ceased when 4.91 was released. You need to update FSUIPC at least. Regards Pete