Pete Dowson

Hmmm. Oddthere's no different treatment for any of the axes, it is all the same code. I'll double check here. Can you first check with the interim release version of FSUIPC available in this Forum, and also show me the complete section from your INI file, please? Pete

Hmmm. Oddthere's no different treatment for any of the axes, it is all the same code. I'll double check here. Can you show me the complete section from your INI file, please? Pete

Any or all of the Shift keys (Shift, Ctrl, Tab, Windows and Menu, also ALT, but not recommended due to its effect on the menu) or none of those, plus any "ordinary" key (graphic/function/arrow/numpad keys). Without ALT that adds up to something over 6000 combinations I think (rough estimate). However, that far exceeds the number of individual assignments currently allowed -- the limit is 1024 entries (though that can be a different 1024 for each aircraft, if you want aircraft-specific allocations). No. No. In both examples you have multiple "active" keys. FSUIPC detects the 5 or 6 keys it treats as "shifts" or "modifiers", which you hold down first, then as soon as you press one of the others the action/allocation is registered. Please see the Advanced Users documentation in the FSUIPC Zip package. It gives you more detailed information Regards, Pete

Ah, so you are forced to switch to IVAP. From what I have seen, that is a good program too, so you should be okay! Good flying Pete

I'm afraid you wil need to contact SB support. This is not related to FSUIPC or WideFS. Regards, Pete

Does SB3 work with FS2002 as well as FS2004? Regards, Pete

But many messages ago you said: Anyway, I don't understand at all. As I said, the only version which is "too old" as far as Error 7 is concerned is one which is older than 1.998e, which would date it to about 5 or 6 years ago I think! Regards, Pete

Actually it says here "Incorrect version of FSUIPC, or not FSUIPC". Looking at the code it gives error 7 on Open (only!) if the version number is older than 1.998e or if the validity check word at offset 330A is not equal to hex "FADE". It means that the Open has sent a message. There will be entries later in the log saying more, expecially if you enabled IPC read/write logging as I asked. Please just run the program, then close down FS show show me the complete log, not just your chosen snippets. I have no VB program sources other that the one in the SDK, which works as far as I know (at least with a user registered FSUIPC -- but it certainly will not fail error 7 even without). To check your installation of FSUIPC simply try FSInterrogate, or any of the free little programs I supply in the FSUIPC ZIP, such as TrafficLook and WeatherSet2. Regards, Pete

This is most certainly a question only Enrico can answer. Possibly he is using his own invented location for ADF2, in lieu of the one not supported by FS until FS2004. You can use FSUIPC Monitoring (right-hand side of the Logging page) to keep an eye on the FSUIPC ADF2 offsets and see when they change and so on. Maybe you can use FSInterrogate to find PM's offsets for the same. [LATER] Bingo! A search on "ADF" in Enrico's PM offsets list shows: Try monitoring that too. Possibly Enrico hasn't yet gotten around to updating it for the new provisions in FSUIPC for FS2004? (I have no idea what he would do in FS2002 though). Regards, Pete

Not necessarily. Really unless you show me the log and start using the tools provided to help you, I don't see how I can give any further advice at all. Please, to start with, simply look in the FS Modules folder, find the FSUIPC.LOG file, and see what it says. That's the first thing to do always. Second, assuming that part's okay, is to use the IPC logging and possibly verify your installation with FSInterrogate. These tools are provided to HELP YOU and to save everyone a lot of time. Regards, Pete

How can you tell if you aren't checking the error on the Open? According to the code snippets you show you never check the return or the result of the Open call! NO!!! FSUIPC runs in FS, in the Modules folder. It is not used directly by your program at all. Have you used FSUIPC Logging -- there are options to log all IPC calls, both reads and writes? It will also log the identity of any program connecting to it. Additionally FSInterrogate is supplied in the FSUIPC SDK. Please use that to check the things you are trying to read. All these tools are provided for a purpose -- to help you develop and debug your programs. I'm afraid I know nothing about VB and the VB parts are not my work (though derived from it) -- but you are in excellent hands with JD's help. Regards, Pete

Two questions. First, you are not checking the result of the Open. It is only on the Open call that an FSUIPC_ERR_VERSION error can be returned -- unless someone has messed up the VB version of my code compared to the C version I wrote. There is nowhere in the FSUIPC_Read code nor the FSUIPC_Process code that sets this error. Second, how is it that you need "VarPtr" for one variable value being returned, but not for the other (dwResult)? In C terms there's no difference in these, both a pointers to memory and both get written to by the code. Incidentally, you also fail to mention wether you are getting this error on the Read or on the Process. But you should check the result of the Open, not simply "Call" it. Regards, Pete

Is it searching for the multiplayer connection? If so then I'm afraid I can't help at all. Neither WideFS nor FSUIPC are at all involved in the Multiplayer side of things. It sounds quite likely that you have a firewall setting blocking things. On the other hand, it just occurred to me: isn't 127.0.0.1 always the current PC, i.e. the one you are running in? I should think you would need to give SB the IP address of your FS PC -- don't you think so? Regards, Pete

There are two threads going on here about this -- please check the other. The answer appears to be that the Panel does NOT use the normal Spoiler on/arm/off controls (the ones allocated to the / key), but the axis control -- very odd considering that they only set full on or off and don't provide continuous settings. They should simply use the on/arm/off controls which then wouldn't interfere with your axis settings. FSUIPC's spoiler calibration will change the values they are sending, and that is why you have the problem. Your suggestion to them is actually irrelevant and impossible since it is their code originating the spoiler axis controls and FSUIPC which is manipulating them. They don't see that. There's no "logic" as such in FSUIPC for spoilers in any case. Calibration is merely that -- matching of values according to the extremes of your external axis to match the extremes used in the Sim engine. All you need to do is disable FSUIPC's spoiler calibration for that aircraft. Use the latest version and make that change aircraft-specific to the ERJ145 -- this way you will still have a properly calibrated spoiler axis for other aircraft. Seems very odd, then, that no one mentioned it here till yesterday? Regards, Pete

It certainly will -- KEY_SPOILERS _SET is the Axis control which you are asking FSUIPC to calibrate. It is odd that, considering they only set full or no speedbrake they use the continuous axis control instead of the on/arm/off controls (the ones associated with the / key). You will have to reset FSUIPC's calibration of spoilers and use no axis for speedbrakes with that aircraft. Luckily, with recent versions of FSUIPC you can make joystick settings aircraft-specific, so just do this for that particular aircraft. Regards, Pete

One thing you can try to glean additional information is to enable both Axis logging and Control logging -- see FSUIPC's Logging page. The two types of controls are individually selectable there. FSUIPC will log each and every event, so the log may get quite large, but it should then be easy enough to search for spoiler events to see what sort of interaction is going on. You could monitor the spoiler value at the same time -- the right-hand part of the Logging page is used for this. Offsets 0BCC (Arm flag) and 0BD0 (spoiler setting), both type U32. Check the option to have these go to the FSUIPC log, in the check boxes below. Regards, Pete

Once you click "Reset", so that the button reads "Set", FSUIPC no longer does anything at all with the spoiler axis. The same principle applies to all of the Joystick 2Set/Reset" buttons -- they merely set or clear a flag which tells FS whether to bypass such controls or not. Reloading should most certainly not be needed. With recent versions of FSUIPC you can make joystick settings, including which are set and reset, aircraft-specific. It sounds like you have multiple sections in the INI file dealing with general and specific aircraft, and this is confusing the issue. Please take a look at your INI file. Regards Pete

There's no wounds that I know of (???)and there's really there cannot be any "conflict" with anything in FSUIPC if you aren't trying to use any conflicting options therein. And to answer your question, no, no one has mentioned any such thing. Sorry. FSUIPC does not touch the spoiler unless you tell it to, so quite honestly it cannot be anything to do with FSUIPC as such. If removing FSUIPC "fixes" it it can only be because either something else you've set FSUIPC to do is doing it, or another add-in or add-on is operating this through FSUIPC's facilities. FSUIPC is not an "active" component, it only does what it is asked to do. Delete your FSUIPC.INI file so only default options are applied (none of which are related to throttles, axes or spoilers), and check the FSUIPC Log to see what other programs or modules are using it. Eliminate those one by one to find the culprit. You seem to imply that you only get this with registration of FSUIPC -- and since all user-registration really does is allow you to use more options, it is I would have thought pretty obvious that it is most likely to be related to something you have set. FSUIPC does NOT allow you to make any axis assignments. FSUIPC's joystick facilities operate on FS controls, there are no (repeat NO) axis assignments within FSUIPC and never have been. You must be making your spoiler axis assignment in FS, and that is where you have to delete it -- there's no way to make nor delete any such thing in FSUIPC. Regards, Pete

Yes, I noticed the highlighting had disappeared -- but the shortcut keys certainly still work the same, in all programs. Regards, Pete

Why Window mode? You should be able to access any of the FS menu entries, including those in Modules, by pressing ALT then either using the mouse or typing the shortcut key. e.g. ALT M F gets you to the FSUIPC dialogue. All these things work in full screen as well as Windowed mode. Doesn't this add-on provide a shortcut or hotkey specifically to show/hide its window? If not you should write to the author/suppliers and request it. It is surely a fundamental requirement for such windows? Regards, Pete

Did you simply try defining (typedef'ing) DWORD and an unsigned long? Seems odd that MS provide facilities so self-inconsistent. I'm afraid I don't know "Windows Forms" at all (in fact I've never heard of them), and I've avoided MFC altogether. I like my code to be completely under my control and as compact and efficient as possible, and I can only ensure that by using plain C, which ASM in places where I need even greater control. Maybe some one else here uses and understands "Windows Forms" and can help. Sorry I cannot. Regards, Pete

The current aircraft name is only shown on page 6 of the Joysticks tab, in the bottom right section where it also tells you the number of flap detentes and the increment used between them. There's no need (and no room) to show the aircraft name elsewhere. Pete

Two things here: 1. I use VC .NET 2003 and have been doing now since it became available. Everything compiles fine. I suspect your trouble may be to do with the fact that everything I provide is C, not C++ -- maybe you need to use C or put some parentheses around the H file to tell the C++ compiler that it is C not C++? 2. There are no classes defined in FSUIPC.H because C does not support Classes. ;-) DWORD is still a standard Windows data type -- it sounds like your Windows headers are corrupted? Very very many of the Windows API calls are defined with DWORD parameters or results -- even basic things like GetLastError, for example. DWORD is simply defined as an unsigned long or unsigned int. Of course, when we eventually get to 64-bit compilation all this will beed a good overhaul. Regards Pete

Only in FS98 or possibly FS2000, as since FS2002 nothing is available in the "global" offsets areas which you can find. 90% of the offsets provided in FSUIPC are now explicitly mapped after I've located the data by hacking the code. It takes me roughly a week or so of long hours to delve deep enough to even start finding things, and that's for areas I know. I wouldn't know where to start for doors -- if you have the tools and know C/C++ and ASM well you could try tracing things through and examining disassemblies, but I couldn't even point to the correct FS module for you to start with I'm afraid. Regards, Pete

Actually, for BUTTONs (only) you are correct, though you omitted to mention those. If button actions are defined in both FS and FSUIPC then both have effect -- FSUIPC has no way to stop FS seeing them. For Axes you are not correct because FSUIPC does not handle axes at all -- all the "joystick" facilities in FSUIPC act on FS axis controls, which are the results of axis inputs via FS assignments -- therefore it is imperative that any axes you want are assigned in FS else they cannot result in the controls which FSUIPC processes. For keypresses you are incorrect also, because FSUIPC actually intercepts all the keyboard messages before FS sees them, and if they are programmed in FSUIPC then FS never gets them. I hope this is clear now. Windows also provides a "Hot Key" facility (not used by FSUIPC), and this takes precedence over any programs awaiting keyboard input -- so other programs, like PowerStrip for example, can steal their allocated keypress combos before FSUIPC or FS sees them. Regards, Pete