Pete Dowson

Gear down and gear up in one process may not accomplish anything noticeable, excepting getting the gear up if it started as down, depends on the timing of those inside FS. The transponder most certainly only occupies 2 bytes -- it is 4 hex digits, so 7777 = 0x7777. Something is wrong somewhere if you are reading 4 bytes for it -- the two high bytes will receive the Extended part of the ADF frequency. This is all stuff which I'm afraid you will have to debug by yourself. Use FSInterrogate to see what you should be getting. It's a superb tool, I'm always amazed no one seems to even notice it. You can write to offsets with it too. Always compare what you get with what FSInterrogate shows. This absolutely proves you have it wrong. There are only 2 bytes for each frequency. 2 bytes contain only 16 bits -- a maximum decimal value of 65535 (unsigned). You cannot possibly get 135264 if you are using the correct lengths! That's something in your program too, then, and there is absolutely nothing in the FSUIPC interface which is in anyway dependent on any buttons. I think it is about now that you need to learn how to use the debugger in your compiler suite -- it does have a debugger, doesn't it? The one I use, part of Microsoft .NET 2003, is superb. Regards, Pete

The current supported version is 3.30. Are you using my PFC.DLL? You should mention the version of that too. Current is 1.90. I don't support old versions. Anyway, if you turn it too fast the firmware in the hardware cannot send the signals across quickly enough. Turn it more slowly. Regards Pete

FSUIPC always produces a Log file. There are facilities in FSUIPC for logging all sorts of things, and the controls for this are documented in the User Guide. Run FS, use ALT M F to go to FSUIPC's options (have you never been there yet?) and select the Logging page. Surely any course in programming deals with memory? This is a fundamental part of any computer. Memory is where the program is stored, and its data. It's what you need 512 Megabytes of in order to run Windows XP and FS2004. Accessing memory is accessing data. Oh dear. I do think you are going to have to give up on your ideas for FS programming then, because whatever you are doing you will need to be able to track things though when debugging. Absolutely wrong! You are not even reading his comments properly! I'll requote the relevant part yet again: Don't you see the words "series of"? Surely you must understand a "series of" is not just "one of"??? Step 3 is the "series of". Please refer to your own quotes!! This is going in circles! :roll: Yes, and where step 3 is the "series of" reads, writes, whatever. Please PLEASE read things more carefully! Regards, Pete

Oh, those FS controls -- I think they are the same as in the FS assignments dialogue. Apart from a few additions, FSUIPC only lists all of the controls FS provides (probably more than in the FS assignments, because they leave some out). According to my list of FS controls, for Flaps you can choose between: AXIS_FLAPS_SET FLAPS_1 FLAPS_2 FLAPS_3 FLAPS_DECR FLAPS_DOWN FLAPS_INCR FLAPS_SET FLAPS_UP I've never tried using the 1, 2 and 3 controls, so I've no idea what they do -- they may not even work (a few of the controls FS lists don't work). The normal flap switches folks implement use FLAPS DECR and INCR. If you need direct setting there are really two ways to do it: 1) Use an axis input -- a lever -- assign it to the Flaps Axis control, and calibrate it in FSUIPC, marking the positions for each flap detente on the lever's slot, or 2) If you have enough buttons, program one button for each flap setting, using the AXIS_FLAPS_SET or FLAPS_SET control, providing the appropriate value as the Parameter. In the latter case a parameter of 0 will give flaps up, and 16383 will give flaps full, but the intervening positions will have to be calculated. I think (but I'm not sure) that the positions are equally spread across the range 0-16383, so each increment will be 16383 / (no. of positions - 1). But you'll need to check this --- it is quite possible that the AXIS_ control is different in this respect to the FLAPS_SET control (the latter is a leftover from FS98 days). Of course it is possible to use method 1) with buttons (or rather a multi-way rotary switch) and resistors on the axis to get the appropriate axis readings -- in this case using trimpots should allow you to get good calibration. I hope this is what you wanted to know! Regards, Pete

Sorry, you need to explain rather more than this! Where are you "seeing" flaps 1 2 5 in FSUIPC? FSUIPC doesn't display any flap settings, it is an interface, not a display engine. In fact, it doesn't even know anything about nominal flap settings -- internally FS uses a continuous flap value as a proportion of the maximum, ranging from 0 to 16384. The nominal values are "detentes" along that range. Regards, Pete

Aren't you using a language you are familiar with then? The original SDK was merely a definition of the interface (no code) and the list of offsets. I eventually did the C code with both a library and a source of the library, and even a silly little example, just so C programmers could understand it and do their own thing. I actually never expected this to be a learning ground for new programmers, so it is very hard to know how to proceed in such cases. Many apologies for this, I would help here if I could. Yes, exactly. Only one "Process" call for any number of Reads and Writes, as I said. It is certainly as clear as mud to me. All that "Get" stuff is totally alien to me, it's that "managed code" business getting in the way! :wink: I hope you find your answers. Regards, Pete

Yes, that's one of the sorts of add-ons! :wink: Well done, and thanks for letting us know. Regards, Pete

Obviously, since FSUIPC runs as part of FS, amy memory it uses is part of FS. But the point is that viewing the variables as values planted in offsets in a contiguous are of memory is merely a fiction, an illusion created to maintain the same interface as originally invented for FS95, back when there was a "GLOBALS.DLL with all that sort of data in it. That's really the wrong way to look at it. Think of the offset as merely an identifying code for the data it addresses. How you then handle it is up to you and what fits in best with X-plane. No. You just implement the interface as defined. The version numbers and so on are simply more data items, just like the number of engines or the time of day. Don't treat them any differently. Your main concern is retrieving the data from X-plane and reacting to writes through your interface by correctly influencing X-plane. I wouldn't worry about the outside looks until you have that figured out. 99.9% of the work spent on FSUIPC is working out how to do this stuff in each new version of FS -- that takes many thousands of hours. The interface part is trivial, you shouldn't need to worry about that at all. Regards, Pete

Hmm. The term "latest version" is meaningless. Every version has a version number. I've had folks quiting "latest version" for a version six months or more out of date -- it's the 'latest' one they have seen! :roll: This really isn't likely to be an FSUIPC problem. Either something which uses FSUIPC is faulty and crashing, or, if this is at initial load, it is either a faulty FS installation or there is a hardware problem or some incompatibility with something else you have installed. The probable reason there's a difference between FSUIPC installed or not is either some add-on using ut, or, if you have none, the slightly different arrangement of FS memory when it is present. Regards, Pete

Okay. So, if that provides enough information to at least make a start on an IPC interface compatible with the one for FS. You'll need to go through each offset in the Programmer's Guide, in the FSUIPC SDK, to see if you can provide a compatible value in X-Plane. Naturally, all the "memory" is provided by the interface module, not X-Plane. Even in FS, although the memory area mapped was, in FS98 and before, part of FS proper, since then less and less is, and even the little that is currently mapped into FS memory isn't where it says it is! BTW you may want to contact the Project Magenta folks. They did make a start into dealing with X-Plane. This was last year. But I think, at that time, they found that the facilities for getting at data and exercising control in X-Plane were insufficient to support full cockpit simulation, so it was not pursued. Things may have changed with recent X-Plane releases. Regards, Pete

Not that I know of. Is there an SDK for X-plane? If you can get inside X-plane in the same way as you can with FS, and if it has compatible information and control methods, then I don't see why someone couldn't do this. There is no problem reproducing the interface, that is not restricted, it is freely published, so if someone wants to produce an X-Plane version of it they are at complete liberty to do so. But it is going to need knowledge of X-Plane internals, not FS. Regards, Pete

Ah, so he doesn't want a reverse prop pitch range on the Prop axis? As documented, FSUIPC defaults to selecting the Mixture axis as reverser. So if he has used FS Assignments to define his Mixture axis as a Spoiler Axis, he can now easily use FS assignments to assign his Prop Axis as the Mixture Axis. Then in FSUIPC simply calibrate the reverser. That is exactly what the Reverser axis facility in FSUIPC is designed to do. He may need to check the "reverse the reverser axis" option if it works back to front, that's all. As documented, it is clearly possible to assign any axis as the reverser axis. The Advanced User's guide even gives a list of the axis numbers for this. But as he is not using a Mixture axis it is far easier to use the default FSUIPC assignment of the mixture axis. My problem is that I don't understand why he doesn't understand. This facility has been included in FSUIPC now for three years and it seems to be generally well understood. Regards, Pete

What is it you are doing, or don't understand? I cannot explain it better here than in the documentation, and there's no point in me reproducing the docs here, so you need to be more specific. Regards, Pete

The separate prop axes work for the 4 separate prop axis controls. EITHER you need to reassign your prop axis to Prop 1 (assuming you only ever want to fly singles), or just use the facility in FSUIPC (in the main single prop axis page) to map the single axis to the 4 separate ones. ("Map to 4 props"). Crack? Isn't that a drug? The problems in all this are due to FS's design of the controls, not FSUIPC. There are no reverse parts on the main default controls, only on the separate ones for each engine. You can do all you want in FS assignments -- try FS's help instead of FSUIPC. If you want to use FSUIPC instead, that's fine, but you do need to look at the user guide, where I do try to explain it. I don't see how I can explain it better here are many years of it being embellished in the user guide. Regards, Pete

Sorry, I have no idea. This is really a question for the FSMetar author I think. Is it connecting to FS okay? Check the FSUIPC Log file (in the FS Modules folder). By the way, please always state version numbers when asking questions. Saying "latest FSUIPC" is rather meaningless I'm afraid. That should mean 3.30, but I've had folks refer to their 6 month old copy as "latest" simply because they had not actually seen a later one at the time. Regards, Pete

Okay, I'll see to that for the next update. Actually, that code is really redundant. It is in the C version so most folks have copied it. All it does is ensure that a Write error is logged in FSUIPC -- the data it tries to write (to a read-only location) was intended to give the library and language versions, for better diagnosis of errors from logs sent to me. But unfortunately I never enforced either the version number nor language ID system I had devised, so it is worthless. I see the line VersionGet = FSUIPC_Get(t_FSUIPC_Lib_Version, FSUIPC_Lib_Version) a little later. That is wrong -- it seems to be reading something which it should have (or could have) actually written. It is a nonsense line -- I'd remove that AND the redundant block above if I were you. I'll do that here. Please use FSUIPC's IPC read/write logging to check it -- you can see then exactly what it is trying to do and maybe why it is failing. Not to me, I'm afraid. I've no idea what it is doing. Please chack things from the FSUIPC end to see if you can figure it out. Use the logging. That is VERY inefficient. Do all the Reads/Writes you need, then one Process call. Each process call can pass a huge stack of read/write requests in one transaction. All the read/write calls do is build up the request in your own memory -- in other words all that is completely defined in the code you have. The ONLY connection to FSUIPC is the "SendMessageTimeout" in the Process call. Do only one of those per cycle. I suspect most of the trouble with VB.NET is that is is "managed" code (isn't it?), so you've probably got little control over what really happens. I've asked Bob if he can look at all this, but I don't know when he'll be able to respond. Regards, Pete

No need to be sorry. I'm not a cockpit builder myself, that is the reason I don't know the actual suppliers you may need. My equipment is a mixture of ready-built stuff, mostly from PFC (http://www.flypfc.com), but also GoFlight, and Aerosoft (Oz). For software I use Project Magenta (http://www.projectmagenta.com). I just did a quick search and came up with these sites which may be of use to you: http://www.aircraftsimulators.com/ http://www.simkits.com/ http://www.therealcockpit.com/ http://www.737ng.net/ http://www.cpflight.com/ http://www.commandfliteware.com/ http://www.hagstromelectronics.com/ http://www.flightdecksolutions.com/ http://www.simhardware.co.nz/ There are probably loads of others. Pete

Check the cockpit forum. I don't supply or support hardware. A search on the internet should find quite a few suppliers too. Regards, Pete

Well, you can do the Throttle and Spoiler assignments in FS, you don't need FSUIPC. The reverser can be done easily enough in FSUIPC. Er, that is only true if you are assigning the throttle as Throttle 1. Assign it as Throttle only -- the generic all-engine throttle supported in FS does not include a reverse part of the range. There is no reverse axis in FS as such. The one in FS cannot provide forward thrust, and will only engage reverse when the main throttle(s) are at idle. Regards, Pete

I'll try to contact him and see if he will come here. Pete

Hi Claudio, The operation was fine, and the eye sees well --- EXCEPT that the eyedrops (a steroid to speed recovery), which were different to the ones they gave me for the other eye, have caused an adverse reaction. Seems I am allergic to those. For three days the newly operated eye has been streaming continuously with tears and is puffy. Today I got a revised prescription and things are starting to improve. I am catching up with emails etc once per day but else resting my eyes. Hopefully things will improve over the coming days. Thanks & Best Regards, Pete

Er ...there's some misunderstanding here. ".Net" is not a language, it is a suite of language compilers and development aids sold by Microsoft. I myself use Microsoft .Net 2003, but I only use the C and ASM parts of it. There are also C++, C#, VB, Java and maybe other parts I don't have or hanen't looked at! Ah, you mean VB.Net! Thank you. [Duh! Only now do I see you said "VB.Net" in the subject -- problem is the subject isn't repeated in each message of the thread. Sorry] I am assured that it was working and tested before submission. I will ask around, but perhaps if you know what is wrong you could tell me? Or at least point me in the right direction. To start with, which file inside the ZIP contains the errors? Regards, Pete

Most add-on panels don't use any control numbers whatsoever, they are just sensitive to mouse clicks in certain gauge zones. Really, that's all the Microsoft gauges SDK allows the programmers to do. They can process keypresses and FS-type controls as well, but it is extra programming which many don't do. Only if they process FS controls -- all the ones that are allocated are already listed in FSUIPC (and in the FS Controls documents I publish). I suppose they might add their own extra ones, but I've not heard of anyone doing this. Regards, Pete

[quote="Oleg Today i lost my data files FS2004 (FSUIPC reg. key too) I pay to Simmarket for the FSUIPC please write me Peter !!!! my e-mail You need to re-register, but using the same original details. If you cannot find your Key (you should have kept a safe copy) you will be able to get it by going to your account at SimMarket. Regards, Pete

You just need to go into FSUIPC options and re-enter the exact same registration details as before -- your original email, not your new one. Best refer to the FSUIPC.KEY file (which is plain text) if you have lost your original email. Regards, Pete