Pete Dowson

These are the INput values? The OUTput should be from -16383 to + 16383. Are you not seeing that? Have you not calibrated, leaving a small "dead" zone at each extreme to ensure you can reach the minimum and maximum values? It will if that is what it sees. When you assigned the axes in FSUIPC's Axis assignments, did you assign "direct to FSUIPC" or to the normal FS axis controls? Try assigning them direct, THEN calibrate in FSUIPC. It sounds as if you've not done this. If you still have problems, please show me the [Axes] and [JoystickCalibration] sections from the FSUIPC4.INI file (in the FSX Modules folder). Regards Pete

No, don't do that. Make the assignment and calibration settings for the Citation aircraft-specific. Then FSUIPC will switch to them only when you load that aircraft, and you'll still automatically have your other settings for the other 20 or so. You might also investigate the Profile facilities I added for this in recent updates -- see the Updates announcement. There's a user guide for profiles in the downloadable Zip. Regards Pete

I hope some other Citation users will come to help you here, because I don't know. From the response you got from Eaglesoft it sounds like they actively intercept the generic single throttle and use that, which really prohibits having reverse on the same lever. Of course you can retain your existing throttle setup for other aircraft and have the Citation done differently by making the assignments and calibrations in FSUIPC aircraft or profile specific. But that doesn't help with the Citation. Regards Pete

Looks goodexcept you spelled FSUIPC as "FSCUIP" in the title. ;-) Pete

Not really, as I don't know vb.net at all. How is that type "SimConnect" defined? Is it supposed to be the handle (which is a pointer in Windows terms) to an open SimConnect connection? And what is "Nothing" defined as -- is that similar to the "NULL" of C/C++ ( which is defined as a zero void pointer I think)? If the location assigned for "SimConnect" is in your program, and it is something to which "Nothing" can be assigned, the obviously it should not be able to cause an error. But in any other case I would certainly expect there to be an error reported, and it may simply be that in the XP case it is in error but the memory wrongly addressed is read/write enabled, possibly by being within the range of a chunk so assigned. Isn't VB.Net a Managed (i.e. partly interpreted) language? If so, it must be quite difficult to debug these things easily, with so much of the memory access buried deep in the interpreter? Regards Pete

I might possibly be able to help if it said the connection to FSUIPC was not ok, but .dat files are nothing to do with FSUIPC or anything related to it. You need to ask Arrestor Cables 2.6 support for help. Pete

That is probably just because you are rounding to the nearest degree whilst the FS display is rounding down (truncating) to a degree. Sunch rounding differences occur all over the place. Strange that you have to do this, when all the GPS values are provided direct by SimConnect, no processing by FSUIPC, and they are probably all sent at the same time. Sounds like there's some sort of bug in FSX. Regards Pete

I think they are. And omitted numbers are handled too. but not in the [Profile...] sections -- no omissions, start at 1. Sorry, the rules are stiffer for Profiles because they need to be accessed more frequently. All the others are loaded once and converted to tables internally, only reloaded when explicitly requested. Only the Buttons section handles comments (well, probably Macros too) because it is only there that I expected things might get complex enough that folks would want to comment. The "handling" used to be easy, because the last filed was always numeric so any non-numeric stopped the conversion -- though I remember when commas in the comment would mess things up if a comma was missing in the parameter. However, these days I have to retain comments and their positions eve when re-writing the section (for ease of programming, including numbered lines with comments only as in "n = ;xxxx...."), so I have to scan for the ";" and store away the comment when i'm building the tables. Regards Pete

Oh dear, I'm afraid you still misunderstand! :-( I never suggested renaming any existing file. That's simply not right! If files are renamed they wouldn't work with the original flights!!! Where does it get the existing html file from? Autosave doesn't have it. It doesn't know anything about it. And why to a "temporary location"? What good does that do? How would FS find it -- it only looks in the same folder as the flight file, and then it only looks for the HTML file with the same name as the flight file. You yourself said that, and confirmed it! Erwho is this aimed at? I'm not reading any briefings or reloading any files. I've no software which does that. Are you aiming this at Microsoft, for a future version of FS, or what? Sorry, you are really confusing me here. I'm not Microsoft, but I would assume that there is no upper limit to the size of the file they want to be able to handle, and the speed at which it has to load would not justify such an allocation of memory. Far better, surely, to retain the name of the last Loaded flight and not assume a Saved flight changes the briefing, as i suggested they might have done. Too late for any changes to FS now, though, and forever by the looks of things. Regards Pete

Delphi shouldn't present any problems. FSInterrogate, supplied in the FSUIPC SDK, is all in Delphi. What values were you getting which made no sense to you? Is "longint" a 32-bit integer as it should be? You should compare what you are getting with what FSInterrogate2 gets. You should also be using the FSUIPC IPC read/write logging to see what your program is actually achieving. Surely the Delphi development system comes with a debugger, so you should be able to debug that yourself? With the AP altitude value, you seem to define "AP_Alt" as an "integer". Is that another 32-bit integer type like longint? Why the different types? With the AP heading value your conversion is completely wrong: Label7.Caption := floattostr(round(Ap_Crs/65536*3.281)); Headings are not in "metres" so why the 3.281? And in the case where you are trying to switch on the autopilot: FSUIPC_Write(offset, size, ptr(waarde), dwResult) (why not "FSUIPC_Write($7BC, 4, ptr(waarde), dwResult)"?) why have you used "ptr(...)" instead of "@..." as in the read examples? Considering the FSUIPC_Read and FSUIPC_Write functions are identical in their requirements for these parameters, why are you doing things so differently. Could the crash just possibly be because you've defined "waarde" as a single byte and then used it as a 32-bit (4 byte) value? Why are you suddenly switching to byte in any case? I don't know Delphi, but I suspect you've not been looking carefully enough at your own code? The FSUIPC interface is straight-forward enough (and you have the source code in any case). I think all your problems may be in understanding the Delphi stuff more than anything to do with the interface. If you think you have things right (and you may well have, as I don't know Delphi), then please tell me what the values you ARE getting look like. Compare them with FSInterrogate, and look to the FSUIPC logging facilities to help you do your debugging. For crashes in your own program ALWAYS use your debugger to determine what value or pointer you have wrong. Regards Pete

Version 4.426, in the Updates announcement now, fixes this little bug. I hope I found the cause of your troubles, Please let me know. Regards Pete

FS supports a number of payload "stations" -- i.e. places on the aircraft which carry the weight. The placing of payloads on aircraft is most important as it affects the balance, and badly loaded planes are difficult, dangerous or even impossible to fly. You can read the number of stations provided in the current aircraft from offset 13FC. You'd then use that as the count of how many payload stations to deal with. Regards Pete

I assume you are thinking of doing this from a separate program, not a Gauge or DLL running inside FS? Adding items to FS's menu (in the Modules main menu) is easy enough, you can do it via FSUIPC, but if you want to open a Window to show on top of FS, it is difficult. When FS is running in Windowed mode you could do it by taking he focus (so stopping sound in FS too) and making sure your Window is on top. But this doesn't work in FS full-screen mode, because the whole screen belongs to FS. The only way to have a Window in FS in full screen mode is to run within the FS process -- i.e. as a gauge or DLL. And even then it isn't easy to do it whilst FS is actually running (flying) without getting flicker. FSUIPC provides the facilities for you to add a menu item to the Modules menu. It also provides ways to display text on the FS screen, either in the FS text bar (along the top of the scenery window by default) or in a separate small (but sizeable) window. But both of those solutions are limited to simple text of up to 128 characters, no more. I don't know of any general way of having your own drawn window showing in FS full screen mode without running inside FS, and you will simply find that next to impossible in VB.NET. You'd have to look at writing a gauge or DLL in C or C++. And even then I couldn't tell you how to avoid flicker except in FS dialog mode (i.e. when FS isn't continually repainting the screen). Regards Pete

Yes. didn't I say that in the documentation? No, no, no! The "ShortAircraftnameOK=Substring" parameter is still as it was, a parameter in the [General] section which sets the mode where FSUIPC will match aircraft names by the longest substring it can find! The only change the Profile system provides is the listing of those aircraft names, whether full, short or substring, in a [Profile] section, instead of being used directly in the [buttons], [Axes], [Keys] and [JoystickCalibration] section names. You are assuming that EVERYTHING has changed, when it hasn't. Profiles are merely an indirect way of doing Aircraft Specific assignments, making it all more convenient. There's that 0= line again. Are you editing that in manually? I've double-checked my code now and still cannot see that being generated, nor working. I think the line will be ignored. Anyway, with "ShortAircraftNameOK=Sunstring" set (in General), that long list could be shortened to: [Profile.Twin Prop] 1 =Douglas DC-3 2 =Douglas C-47 3 =R4D NATS 4 =Douglas XC-47C 5 =Beech Baron 58 6 =Heinkel He219 Regards Pete

How did that "0 = " line get into the Profile? My code starts the list with 1. I don't think I read a "0 =" line. Also just a suggestion. If you set "ShortAircraftNameOK=Substring" in the [General] section, then you could simplify that Profile list to just: [Profile.B377 Stratocruiser] 1 =Stratocruiser I've removed the "0 =" line because I don't think it should work. Or does it? Let me know and I'll re-check my code. Regards Pete

You don't have to use them. Use of any FS controls is optional. What is it you want to "set"? You seem to be starting from the wrong end altogether. You surely don't look at a tool and think, "hmm, how can I use this?". You start with a problem, something you want to accomplish, THEN look for the tool to help you do it. You want to use the FS FLAPS SET or AXIS FLAPS SET controls? There are two -- the older FLAPS SET is still supported in FS for backward compatibility (it was introduced many many years ago). All of the AXIS xxxx SET controls were added later. Normally the SET type of controls are assigned to axes. There's no "syntax" involved (I don't know how you are getting to "syntax" in relation to your question in the first place). Axes are the levers like joysticks, sliders, yokes, throttles, etc. You can assign SET controls to buttons or keypresses if you wish, it is infrequently used, but then the parameter, the "axis value", is fixed. You'd work out what value you want to actually set, and provide that as the parameter. I think you need to state what it is you want to do. Then maybe I can help you more. No, it is not mandatory, and in fact you must never reveal your registration key in public. Regards Pete

What you get is direct from SimConnect, then. If it isn't supplied in some modes, it isn't available in those modes. 6050 is the SimConnect variable called "GPS WP BEARING", and it is in radians. Is this what you want for your "DTK"? Regards Pete

Found it! I think. That line above prompted me to pore through the paths in the code taken with specific [buttons] options changes. Look in your [buttons] section of the INI. Do you have a PollInterval= parameter there? If so, is it by any chance set to 50 or more? If so, try setting it to any number less than 50 (or just delete the line so it defaults to 25 as usual). Here, with 50 or more I get exactly the same results as you. Looking at the code, there's an "ancient" path through which differs for poll rates or 20/sec or less (as indeed an interval of 50 will achieve). I'll fix this. It looks like it was designed to avoid creating a thread for button presses when the poll rate was only about the same, or less, than the normal Windows "tick" rate in any case (18/sec or 55 mSecs). I think I must have thought it wasteful of resources. However, some few releases ago i made the key-sending sequence a separate thread too, to get a smoother result for key sequences, and consequently I had to arrange an interlock between the threads when accessing the same data -- that for keystrokes resulting from button presses. Oh, what a tangled web we weave;-) Anyway, if this is indeed what is causing your problem, you can fix it easily with that parameter, and I will fix it this end by making Button polling always threaded. Threading suits modern PCs in any case with their often under-utilised other cores! Regards Pete

Sorry, can you explain that a little more please? Are you trying to draw your own Window? What menu / shortcut are you thinking of here? Something in FSUIPC or in FSX, or in your programming system? There are facilities in FSUIPC4 for displaying text on screen -- these are detailed in the FSUIPC4 SDK, and there are facilities in SimConnect for test lines or menu windows (like the ATC one). The SimConnect facilities are, of course, described in the Microsoft SimConnect documentation in the FSX SDK. Regards Pete

Hmmm. There's something strange going on there. The actions after this part of the log: 474406 Button changed: bRef=0, Joy=0, Btn=8, Pressed // Saitek quadrant button press programmed via FSUIPC for F7 474406 [buttons] 2=P0,8,K118,8 474406 SendKeyToFS(00000076=[F7], KEYDOWN) ctr=0 haven't changed in FSUIPC3 or FSUIPC4 for many years -- it uses a facility in Windows called "SendInput" to recreate the same effect as pressing keys on the keyboard. I've just programmed a button here to send an F7. Here's excerpts from my log: ********* FSUIPC4, Version 4.425 by Pete Dowson ********* ... Running inside FSX (SimConnect Acc/SP2 Oct07) ... 163938 Button changed: bRef=0, Joy=174, Btn=7, Pressed 163938 [buttons] 12=P174,7,K118,8 163938 SendKeyToFS(00000076=[F7], KEYDOWN) ctr=0 163938 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000080} 163938 Sending WM_KEYDOWN, Key=118 (Scan code 65), Ctr=1 164000 KEYDOWN: VK=118, Waiting=0, Repeat=N, Shifts=0 164000 .. Key not programmed -- passed on to FS 164000 *** EVENT: Cntrl= 65758 (0x000100de), Param= 0 (0x00000000) FLAPS_INCR 164047 SendKeyToFS(00000076=[F7], KEYUP) ctr=0 164063 Sending WM_KEYUP, Key=118 (Scan code 65), Ctr=1 164110 KEYUP: VK=118, Waiting=0 164172 Button changed: bRef=0, Joy=174, Btn=7, Released 164172 [buttons] 12=P174,7,K118,8 164172 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000000} That's how it should look, with all the blue parts following the part where your system is hanging. I've got no other reports like this, so I'm worried that there's something corrupted or interfering with this on your system somehow. Looking at my code, the early parts of the sequence after the "SendKeyToFS" action, as logged in my log, are actually carried out in a different thread. I'm wondering if there's some glitvh here which is very time-sensitive. I'll look to see if I can add a little extra logging to narrow it down -- though if it is very timing sensitive that might not help isolate it, of course. Later Oh, could you post here the main [buttons] section from your FSUIPC4.INI file, please? I need to see whether there are any parameters which may influence this. Pete

In FSX or FS9? In FSX, FSUIPC4 just relays whatever SimConnect supplies. It does not test any "modes". In FS9 the whole of that area is merely a slab of FS's own memory that someone found and documented for me. I've never trusted it that much as it seemed inconsistent in any case. Regards Pete

The FSUIPC.INI, and the FSUIPC.LOG with Keys & Button logging and Event logging enabled, and you reproducing the problem and narrowing it down as far as possible in the log file. I'm not interested in any FS9 files! You should really look at the Log first in any case. I'm sure you will then work out what is going on. Where did you download it from? If your last one is as old as 3.75, then you skipped 20 or 30 updates! Please ALWAYS check the version number -- there's no point in guessing. The version number is shown in the FSUIPC options, in the log, in the documentation, and in the DLL properties-version. I ALWAYS need the version number. If it isn't 3.865 then it isn't the current increment. Check the Updates announcement in this Forum. If files are short you can past them here. If you enclose them as "Code" (see the button next to "Quote") they'll not take up too much space and have a scroll bar. If they are big and you just can't narrow them down, ZIP them, and send to petedowson@btconnect.com, with an explanation of exactly what you did and what occurred in the covering email. Regards Pete

The offset isn't any use, but the code indicates an access violation. Usually those are caused by bad pointers. Does it crash with all keystrokes, or just that one (which is F2)? There's no problem here sending keystrokes from button presses. Have you tried enabling Key logging in FSUIPC's logging page to see if it gets through FSUIPC? If so it is whatever is seeing that keystroke which is crashing. Maybe some other add-on? All keycodes, or just that one? If you come back with any more information, it would help, please, if you stated FS and FSUIPC version numbers. Also, it might be worth trying the latest Update (in the announcements) first. Pete

Why do you need to rebuild Profile sections anyway? Surely it is either only a metter of assigning the profile you need when you load the aircraft, or -- better if the re-paints all have a common part of the aircraft title (like "B737") -- using the ShortaircraftNameOk=Substring facility, and declaring the B737 short name in the Profile section, once only. Tell me what you don't understand about this, as I find your "pain" comment worrying. it should be dead easy now with the Profile facilities. That's why I spent so long sorting it out! :-( Regards Pete

Surely, all the rest of that is irrelevant. All that matters is the unit with the toe brakes -- the CH Pedals Pro. And all recent versions of FS support toe brake axes "out of the box" -- the time when you couldn't use them without FSUIPC is long gone. You are presumably using FS9 or FSX? Or not? Tell me what the problem is, then maybe I can advise. I can't really comment otherwise, can I? Regards Pete