Pete Dowson

Well it tells me that you've assigned buttons to FS controls. But you also said, before: What are you expecting to happen on the axis assignments page when you are pressing buttons? There's no connection. The axis assignments page allows you to see and assign axis inputs. Pete

You posted your support question into the "FAQ" subforum, where it wonn't get answered. That's a repository for answers to "frequently Asked Questions". I moved it for you to the Support Forum. I'd need more information: Which version of FS? Which version of FSUIPC? If you are not using FSUIPC 3.999 or 4.827 (or later) then please update first and try again. Then, if you still have a problem I'd need to know exactly how you have set things up. There are a lot of options. Find your FSUIPC INI file (in the FS Modules folder) and paste its contents here. Regards Pete

Assigned where and to what, exactly? Switches and buttons are assigned in the Buttons & Switches tab. The axis assignments tab works with levers (and real hats in FSX but not FS9). You really need to explain where you assigning and to what. I can't guess these thngs. There are a number of ways of adjusting trims so you need to be specific. It would also help if you stated the version number of FSUIPC and the version of FS -- FSUIPC applies to all FS versions since FS98! Pete

That's 3.75 which is unsupported for a long long time. There must only ever be one FSUIPC.DLL in the Modules folder. If you've been renaming then and leaving them there it will cause no end of problems. You also should not have any in the main FS folder. Pete

No, not on the FS PC. Long ago when there was an access control for applications it was possibly, but the problem with that system was that every time any program requested access, FSUIPC had to get a list of every process currently running and match it up to the caller's process ID. This overhead was considered unwarranted and affected performance so I dropped the checking. I'm afraid your only method is to run only one of them at a time. Or try thm both on a Clinet PC instead. Regards, Pete

Good. and 75 is no age. I am 69 soon and hope to still be programming at 75. ;-) Pete

FSUIPC Version 4.53 pre-dates Prepar3D altogether, not just the current Prepar3D version 1.3! Didn't you read my previous reply? Pete

What version of P3D and what version of the FSUIPC installer? If you are on P3D version 1.3 you need to use the current FSUIPC4 installer, 4.827. See the Download Links subforum. All the details of the Installation process are logged in the Install log. If you still have a problem, show me that. Regards Pete

There are three weather interfaces in FSUIPC, dating from different versions and periods of FS itself, each with more sophistication than the previous one. The original FS98/FS2000 weather control interface is that listed in the Offsets lists in the area ranging from 0F1C onwards. This offers crude control and with global weather only. Then there's a "command based" weather control which was implemented in FS2002 days. This is documented separately in the FSUIPC SDK, and is called the "Advanced Weather Interface" (AWI). The best and easiest to use since FS2004 (FS9) days is the "New Weather Interface" (NWI), which is partially documented in the Offsets lists (see offsets C000 to CFFF), but mainly in the separate ZIP for it in the SDK. This latter interface is used by Active Sky on FS9. There are two demonstration programs provided: WeatherSet.exe which uses the AWI, and WeatherSet2.exe which uses the NWI. The former is really now resundant. With FS9 and before there really isn't any alternative to FSUIPC for program control over the weather, but in FSX and Prepar3D you can, of course, use SimConnect directly instead if you wish. Active Sky for FSX uses SimConnect directly, and so does REX. FSUIPC4's NWI interface is effectively a backwards-compatible interface for FSX's SimConnect weather facilities. Regards Pete

Have you tried reducing some of the aircraft realism sliders? If you are using a prop plane, as you increase power there are two forces at work which will make the plane veer: 1. the increasing torque of the propeller rotation, and 2. the "prop wash", the air moving down one side of the aircraft more than the other and hitting the tail fin Believe me, in a real light aircraft the effect is really quite strong and as you accelerate you need more and more rudder to offset the veering. FS simulates this, but if you don't use rudder pedals it is best to turn the effect down because it is otherwise difficult to deal with. And FS can overdo it with some aircraft (mainly I think because of a lack of grond friction). Go to the aircraft - realism menu in FS and look at the sliders there. Turn some of them down (move them to the left) until you feel the aircraft is manageable. If you think none of this is applicable to you, and you are calibrating your joystick in FSUIPC , please locate the FSUIPC "INI" file ("configuration settings", which will be in your main FS folder, inside the Modules folder, and paste its contents in a reply here, and I'll be able see what you've done. If it is merely a slighty wavering output from your joystick an increased neutral cental area should do the job of stabilising it. Regards Pete

I've no idea what a "real" or an "extended" is. If a "double" in the language you use is a 64-bit standard floating point vaslue, then that is the correct type to read values from offsets defined as doubles (i.e. 8 byte or 64-bit floating point numbers) in the offsets list. However, as i said, the groundspeed is a simple 32 bit integer, so the receiving value should be defined as such. An "Integer" most likely. Don't you have any references for your language. 32-bit integers are the most common numbers in current 32-bit programs of course. What does the "@" do? Take the address? If so, why don't you have one in front of "dwResult"? Why doesn't that fail? That should be the address of a 32-bit integer to receive the error number if the call should fail -- likewise the parameter before it receives the value you are reading. Why would one need an @ and not the other? Maybe you are still defining it as an array, so need to take its address? I don't know. If you don't know the language -- and I'm afraid I certainly don't -- you need to talk to someone who does or refer to a book on it. Why not at least paste the code here so that those who know can at least check what you've done? You need to post the declarations and well as the function calls. [LATER] Checking here: http://www.delphibasics.co.uk/Article.asp?Name=Numbers I see that "double" is certainly the right type for 8-byte 64-bit floating point numbers. I couldn't see a "real"..and it certainly isn't an "extended" with it an 80 bit (10 byte) floating point value. For 32-bit integers it shows "LongWord" or "Integer" or "LongInt". Pete

FSUIPC can assign to keypresses and FS controls. Keypresses which are recognised by FS are actually assigned inside FS to FS controls, and your "Ctrl+F2" is assigned, by default, to "prop pitch decr" which is the very control I would expect to be used to feather all props. This is why I supggested that you use the specific separate controls (which I named for you) instead. So far you've never said you'd tried assigning to any controls at all, and instead seemed to profess a complete misunderstanding about all this. The Saitek quadrant levers have buttons which activate when you pull them back. It was these I assumed you were assigning, of course. Yes, buttons are either "pressed" (on) or "released" (off), as you'd expect, so they are non-progressive, of course. I didn't realise you didn't understand what a button was. Sorry. You assign buttons in the "Buttons" tab, NOT in the Axes tab of FSUIPC. Of course. Who said anyhing about changing that? And CTRL+F2 is the same as the FS control "prop pitch decr". It is assigned to that by default in FS. Sorry, but I now don't believe you actually understand what "FS commands" or "FS controls" are. All your words lead me to this belief. I think I must give up. I have tried, I have explained it in several different ways, but you never ask specific questions about what I mean or tell me anything precisely about what you've done, only that you've apparently tried "all things possible". Obviously if you really have tried "all things possible" and "nothing worked", then what you want to do is actually not possible. I don't really believe this, but I have now given up trying. Sorry. Good bye. Pete

Why on Earth use Ctrl+F2 which is simply "prop pritch decr" as assigned in FS? Why not use the controls provided, whcih include spearate ones for each engine? Despite what you say you just don't seem to understand. Have you actually tried assigning to controls instead of keypresses, at all? I don't understand why you'd bother to come here and ask questions if you don't even try the answeres you get. You didn't need to read any manual, the answer has been in my replies each time, but you continue to ignore it. But please yourself, if that's how you want to be. I just don't understand why you'd refuse to accept the answers. :-( Pete

Okay, good. In that case all of the default assignments should be fine. If it is not also programmed in FSUIPC, and not somehow (in ways I wouldn't know) programmed in FSX itself, then the only possible answer is that there's a hardware problem whereby that "button" is effectively sending two signals for the same action. You can check this yourself in the "Test" tab in the PFC menu selection in the FSX Add-Ons menu. Select that and see what inputs it records. Not sure why you should think that reverting to older versions would help. I use PFCFSX.DLL everyday with my serial port connected PFC equipment and there is no known problems at all. Do the check I suggested then contact PFC support. Regards Pete

Okay. Sorry that I don't speak French. We can only talk in C then? <G> Hope so. Please do check against the Offsets document. That's the prime reference. Regards Pete

I already told you several times, and gave you references! Why don't you use the Offsets list in the SDK documentation? How did you manage to convert a double into two ints? What's the difference apart from the fact that a 64-bit integer can accommodate the whole value in one instead of splitting it? Just add 0.5 to round to the nearest integer and then simply assign it -- with a cast if you want to avoid compiler warnings about loss of precision. Questions about simple programming should really lead you to a programming book. I'm not very good at teaching people to program. You really need to learn it first. Sorry. Pete

You must surely notice that the offsets for position and attitude, "LLAPBH" (Latitude-Longitude-Altitude-Pitch-Bank-Heading) are in a contiguous block of 36 bytes starting at offset 0560, so that is the offset and that is the size. Your structure will contain the 3 64-bit doubles and 3 32-bit integers. Unless you are using a very old compiler, most versions of C support 64-bit integers. -- "long long" or "int64" or "_int64" usually. Look up the data types your compiler supports. Check http://en.wikipedia.org/wiki/C_data_types for some hints. I'm not checking your arithmetic for you, I'm just pointing out that messing with lower and upper halves of 64-bit integers is a bit daft when there will undoubtedly be provisions for 64-bit integer handling for you. You are just making it more complicated and messy, and therefore more prone to error. The main thing you need to do still is write them all together as one structure. How you prepare that structure is not really relevant to the optimum operation inside FS. Pete

Yes. You only ever buy a registration once -- different ones for FSUIPC3 and FSUIPC4 -- but they are valid for ALL such versions, and, in fact, you are expected to keep your copy updated because old versions cannot be supported. Also you will often find further updates in the Download Links subforum here. Version 4.827 is the latest complete install package, but there's a version 4.831 which can be installed manually afterwards. Regards Pete

I've really no idea. Is this a USB yoke, or one which connects to a serial control system? Are you using any of my software -- PFC.DLL or PFCFSX.DLL? FSUIPC3 or FSUIPC4? How are you assigning the switches? It sounds like you have the switch programmed twice, i.e. in two places. You'd need to unprogram the action you don't want. But with zero information provided I can't really help much. For the older serial port PFC system driven by my PFC/PFCFSX drivers, the default assignments are trim on left and views or panning on the right -- the other way round for the copilot part of a linkws pair, as in the 737NG cockpit. But they can be changed of course. If you are using one of these drivers, why not check the documentation? Regards Pete

Yes, those offsets I mentined should be working okay. I've not actually used them myself. The FSX ones are from SimConnect, the FS9 and before are from FS internals I think. To verify if they are working I'd have to load up both sims and use the logging or the Monitor facilities, and i don't have time at present. Why not just try them yourself? Regards Pete

FSX or FS9? In FSX you can only turn it on or off via the menu. I think you can detect whether it is on or off -- try offsets 0832 (own aircraft crash) or 0833 (crash with other aircraft). In FS9 and before you could try offset 0830, as documented. I'm afraid I don't recall whether it worked to switch it on and off, though -- it may also have only been a read-out. Pete

Sorry, i don't quite understand the question. You want to make the aircraft crash? Or you want to detect crashes? What do you mean by "crash is active"? Pete

Instead of all those separate FSUIPC_Writes (which will all be processed separately in FSUIPC!), make a structure for all 6 values, set up your structure, then write it all with one (1) FSUIPC_Write of 36 bytes. Otherwise each separate write is making a change in FSX. All the vlaues need to be written at once, in one structure. You don't understand what ppart? Structures? Or 64-bit types? Have you any documentation for your compiler or the language? Pete

Good gracious! How extraordinary! Why are you using arrays for single numerical values? Since the groundspeed is a simple 32 bit integer why not simply read it into a 32-bit integer and use it directly? i.e delete that first "after processing" line and simply change the read to: FSUIPC_Read($02B4, 4, A_GroundSpeed, dwResult); I don't understand why you are using byte arrays in the first place. What gave you such an idea? Why not just define the values you are reading into to a variable of the type they actually are? You are making life extremely complicated for yourself, and quite ineffiicent. You should ONLY be getting offsets and their definitions from the documentation which lists and defines them !!! Pete

Your code seems only concerned with latitude. What anout altitude and longitude? You should write all three together, as one 24-byte block. Inside FSX they are just one structure. You should do the same, make a 3-element structure. And in any case you should write this as one 8-byte integer. If your compiler doesn't support "long long" or 2_int64" types (64-bit integers), the make the one 64-bit value with a two DWORD array. How often are you sending the data (FSUIPC_Process seds it)? You should try to equal the frame rate of FS, otherwise it will certainly be jerky. Regards Pete