Pete Dowson

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

Yes it does that. The same happens if you explicitly save a flight. They are not renamed files they are brand new files. Try it yourself, save a flight with a new name, then use "reset flight". What gets reloaded? (Answer: the one you just saved). Yes, I saw the HTM type files in those folders. I thought I said that? No need. And I think the "learning centre" uses Missions in FSX, which explains why they moved. It isn't complex! However, it is a small design shortcoming in FS9 I think. I thought I explained that? What wasn't clear? Let me try again: There are TWO things you can do with a flight -- SAVE it (i.e. create a file with all the details on disk), and LOAD it (i.e. read it into FS and use it in place of the one you were using before). When you LOAD a flight, you evidently get access to any "HTML" file which has the same name, saved in the same place. It sounds like, in FS9, these come up automatically if they exist -- the Missions in FSX certainly do that. When you SAVE a flight, FS creates the new FLT file (and a WX weather file) with the new name, but apparently does not also save the HTML file with the new name. That's fine -- or it would be if FS continued to associate the HTML file with the name of the previously LOADED flight file. If it did so, then merely saving a file (as AutoSave does) would not lose you access to that HTML. Of course, if you restarted a flight, that would restart from the last save, so you'd lose access to the HTML then in any case. But you wouldn't lose it unknowingly. However, it seems that FS9 (at least) associates the HTML file with the same name as the last referenced FLT file, whether loaded or saved. Hence the only solution being the one I suggested, which may well be easily feasible but, as I said, a possible cause of more noticeable stutters. If I implemented it it would therefore probably have to be optional. And maybe I'd only do it for FSX, I don't know yet. Who said you would have to do so? Regards Pete

That must be a mode of FS9 I've never set, as when I select a flight, I just get the flight, in the state I saved it whenever. Oh, rightnot in any parts I've read, evidently! ;-) Yes, I did, but it doesn't change the name of any file at all, it merely tells FS to save a flight with a NEW name, based on the time. Oh, it also deletes older files it saved, according to the the number requested for your cycle of autosaves. The saving action is 100% identical to what happens when you press ";" to get FS to save a file, then enter a name and press ENTER. The only differences with AutoSave is that it does it on a timed basis, and generates the name itself rather than prompt you for it. In that case it really is a design defect in FS, as it should base the HTML filename it reads on the last flight you LOADED, not SAVED, surely? I had a quick look in my FS9 folders. There are ".htm" files in some subfolders in the "Flights" folder. But there are none at all in the "My Documents\Flight Simulator Files" folder. The latter folder is where saved flights have to go. AutoSave cannot save files in the "Flights" folders. If HTM files are copied into the saved flights folders and renamed, do they still work? If so, the only way around this would be for AutoSave to find the name of the currently-loaded or last-saved flight (whichever is more recent, then copy any html file with the same name, giving it the new name. So, with a cycle of, say 30 AutoSaved files you'd get 30 identical HTML files. Right? And then it would also need to delete those when it deleted the corresponding AutoSaved file. All this could cause a stutter in the flight, so it may have to be an option. The deletion is easy enough, the rest is messy for the AutoSave DLL as it doesn't currently have the requisite information. It would be much easier to do for FSX, in FSUIPC4, because AutoSave is part of FSUIPC4. I assume the same problem was carried forward by MS into FSX? Or don't you know? Is all this new in FS9? Even if so, FS9 is now, what, over 5 years old. No one mentioned this before. If it is applicable to FSX I may add the solution I mention to FSUIPC4. Whether I can backtrack to the freeware Autosave.DLL for FS9 I'm not sure -- if the code is not too dissimilar I probably could. [LATER] I just looked at the FSX folders, and the only .htm files associated with flights which I see there are only for Missions, in the Missions folder. Maybe MS fixed the problem in FSX? I'd have to try loading a mission and saving a flight with ";" to see if it saved a new .htm, or if not, whether the same original .htm is remembered and re-used (which would obviously be a far better solution). Regards Pete

Yes, I understood that. I used to be annoyed by it too, but it happens so often that it bothers me no more! ;-) There's another case from seven weeks ago just come to the fore again this very minute, also replied again. We'll see .. Thanks & Regards Pete

So, then obviously I need the same information as I asked before, over seven weeks ago, with never a reply. Please read my message above. When I don't receive any follow up, and it is only a single report, I have to assume that the user concerned solved the problem by himself, or found that a later update fixed it already. I always hope that such users "complete" the thread with a reply, but obviously I cannot force this to occur. There is really nothing in FSUIPC which can be doing this on its own, it is related to some setting or other, or possibly some add-on, but I cannot help you in a vacuum. There's no way for me to proceed. I have to work with actual information, as I asked the previous user, but to no avail. Anyway, in the seven weeks since the last user was complaining about 3.853, there have been many other updates. You should please first try the latest interim version, 3.865, from the updates announcement above. If you still get problem, that is when the log and INI information is needed. Version 3.865 is currently the "release candidate" for the next big release (maybe even 3.90) -- I still have a lot of documentation to work on, as there are several important new facilities which deserve expanded attention. Regards Pete

Thanks! I think this must have been the critical part, missing on the earlier attempts. It's a bit astonishing that rolling back doesn't undo permission changes. We'll have to watch that! Regards Pete

Good! Can you tell us what did the trick? Regards Pete