Pete Dowson

Perhaps you can show me the INI file which doesn't work and the new one that does, to see what the differences are. The only thing I can think is that the positions of the joysticks changes, so the joystick numbers were different. If you aren't using the joy lettering facility that would certainly mess things up. Did you copy the original INI file over to P3D, or generate a new one there? If you didn't copy it, why not? Pete PS if you do paste the files into a message here, please use the <> button in the button bar above to wrap them (separately) so that they will be easily extractable into my comparison program.

Installing new versions of FSUIPC doesn't touch any of your settings or assignments. They are stored in your FSUIPC4.INI file which isn't touched at all by any updates, ever. So it cannot be your updating which made the change. You've done something else. Perhaps you mistakenly deleted the files before installing the new version? You NEVER need to delete anything. Just run the update. If you've lost your INI file and didn't think previously to make a backup then, yes, you will need to make your assignments again. They were all stored in that one file. Just back it up next time, and don't delete things unless you really want to get rid of them! ;-) Regards Pete

Ok, good. I'll change the main download packages and put 4.924a up separately for those who've already downloaded 4.924. Thanks! Pete

Okay. Please, all those getting this crash, please try 4.924a: FSUIPC4924a.zip Let me know, please. If okay I'll amend the main 4.924 packages. Thank you! Pete

Same solution as above, then. I'll post a version 4.924a for folks to try shortly. It undoes the hook into API.DLL before FSUIPC closes. Pete

Sorry, no, there is no definitive answer. I don't know if it would help or not. All you can go by is the experience and reports of others. I wouldn't want you to waste your money on something you otherwise have no use for (though it does surprise me that you'd feel FSUIPC wasn't worthwhile for a multitude of other reasons). Regards Pete

Okay. So at least I know it is related to my SimConnect_Text hook into API.DLL. I can only think that one of the add-ons you are using sends a text message for display when FSX is closing and somehow it happens after FSUIPC4 has closed, or at least got past the point when it is handling the messages. I use the hook all the time for display of GSX messages and menus, and ASN weather data, on a screen inside my cockpit, and there's no problem closing FSX here, but then probably nothing I'm using sends a "goodbye" message. For now leave the parameter set to 'No' whilst I look for a solution. I did think having it defaulted enabled would be safe, like my other hooks, but it seems not. :-( Regards Pete

But if you are using the aileron controls for steering (which, incidentally, is the same as the default action in FS for folks with no rudder -- or at least it used to be. I don't know if it still is an option these days), when the aileron controls are disconnected you won't be able to steer that Dash 8. Offset 310A can be used to disconnect Ailerons (it is bit 1). You'd need a small Lua plug-in which loops reading the "on ground" flag and writing to 310A. I think you'd need to make it stop disabling ailerons when the ground speed exceeds about 30 knots, though, because otherwise you'll have trouble in cross-wind takeoffs where aileron use is important. By that speed you should be mostly using rudder for steering in any case. Pete Pete

Can you try changing the FSUIPC4.INI file [General] parameter "InterceptTextMenu=Yes" to No, please, and let me know if that fixes it? Pete

Have you any information on the crash: error type, module name, offset, etc? See the Windows event viewer. Such information is always needed. However, there's no more reason for 4.924 to cause FSX to crash on exit than any other version. All that will be different as far as termination is concerned is the layout of memory because of the different sizes of things. If such minor changes appears to cause problems it is almost always because there was a problem in the first place but it was inconsequential with a different memory content. On top of that, FSUIPC is a tool used by many other add-ons and add-ins, any of which could also account for a difference with and without fSUIPC installed. I suggest that you conduct a series of eliminations to see which other add-on will be contributing to the problem. For add-in modules you can edit the DLL.XML file to disable loading of each in turn. You may also find that re-ordering some of the entries in the DLL.XML file will help. Regards Pete

As Andy says, please update to a supported version. Then work out what you are doing using the Logging features of FSUIPC -- see its Logging tab. You can monitor the Axis Events and the ipc Writes you are doing. Pete

I fear you still misunderstand, but please correct me if you are simply using words differently to me: If they are merely controls, not values or switch settings that can be read from SmConnect, then they are simply NOT suitable for reserved offsets -- because FSUIPC cannot possibly maintain them in their correct values! ALL controls, as opposed to values are better assigned and sent as controls. This is not "less powerful" than offsets. If you want to send controls via offsets just use the facility for that, offset 3110. Please do NOT provide a list of FS controls you want in offsets. Only SIM VARs -- which you can find listed in the Simulation Variables section of the FSX and P3D SimConnect SDK. Regards Pete

If you are referring to the 64 bytes of free use offset addresses from 66C0 to 66FF, no. It would only be 64 separate values if each was 8 bits in size (i.e. 8 indicators or a values between 0 and 255 or -128 and +127). At one extreme it could accommodate 512 one bit values, and, at the other, 8 x 64-bit values or double floating point numbers. What do you mean by "only" in any case? Are you planning to construct some add-on which uses thousands of L:Vars ar the same time? Other offsets could be used, at the risk of clashing with other applications you may or may not want to run. If you do such a thing, please do not distribute it for others to use because it would inevitably result in problems which would come my way. If you plan on producing something for general use you need to apply for a range of dedicated offsets just as all other freeware and commercal users of FSUIPC have done. Pete

Not a ready-made one. It's only a few lines in any case -- just a function called by event.Lvar (thereby supplying it the value), where the given value is written to a user offset (in the range 0x66C0-0x66FF). Choose to write it as UB (8 bits), uW (16 bits), or UD (32 bits), as needed for your value content -- the functions for that are ipc.writeUB, ipc.writeUW and ipc.write.UD respectively. Look them up. Pete

The only possibe explanation, apart from dual assignments for that axis, is that you've got the button which is depressed on the Saitek lever when you pull it all the way back assigned to the gear. It seems you have not assigned the range of movement to the controls, then. Please see the example in the FSUIPC user guide for assigning the gear lever to an axis. It would be similar. Using axis assignment for such as parking brake is most unusual -- there are only two values use out of the 32,768 you are sending. You need to assign in two ranges instead. Pete

No, thanks, it isn't necessary. As I said earlier, I found and fixed the problem. I have no website. All my stuff is located in the Simflight servers and accessible in the Download Links subforum here. If you mean Mr. Schiratti's "Dowson" page, then I have no control over that. I do occasionally ask him if he will update the wording there, but it can take a while, perhaps days or weeks, because he is travelling and working elswhere a lot of the time. In any case, the links on his page point to the same downloads from SimFlight, so it is of no real consequence. Only the descriptions there are out of date most of the time. Regards Pete

I don't see a "launchbar" simvar listed. What is its name in Simconnect? I'm always glad to add specific values, by request, but you do need to be specific. Can you tell me the actual SimVars you need, by name as known in SimConnect, please? I am not doing blanket additions of all possible SimVars to fSUIPC. FSUIPC's interface to FSX is mainly for compatibility with FS9 and before. I would expect any new application for FSX to be using SimConnect directly. I do understand some extras may be needed for, for example, Lua plugins and the like, but I'd like these to be specifically needed and therefore requested. Regards Pete

Sorry, I think you may misunderstand what the FSUIPC maintained offsets are really for. The provide data read out from FS. I can't read the state of the "Launch Bar" switch, as we already discussed. What are "all the new Acceleration controls" anyway? Regards Pete

You mean you've logged the LVars, using the Lua LVar logging plug-in, and not seen any change when you toggle the setting of the Launch switch? When it needs changing. What aspects of it do you think need updating? Pete

Sorry, but that is rather confused. What 'ok' are you clicking? The one in the option after selecting the macro starting button? Or the one after entering the macro filename? Which window are you 'not getting'? If you mean the window which allows you to name the macro when you click the mouse on a mouse-macro-capable mouse spot on the cockpit? If this is what you really mean (thjough it's a long way from "Ok" clicking), then you should know that mouse macros are not possible on most cockpits because nearly all modern ones aren't written using the FS2004 C/C++ gauge SDK. You say you are "not getting the macro in the pulldown list", but how can you expect to if you've not actually created and named one? The filename is not the macro name, just the name of the file in which all your created macros are stored. Its name is just the prefix for what you would see in the drop-down selection list. The names are in the form: <macrofile>:<macroname> Generally you'd have all the macros for one aircraft type in the one file. BTW version 4.924 is now available. [LATER] Checking among the aircraft in P3Dv2, so far the only one I can find where mouse macros can be used in some areas is the Mooney Bravo. In the main panel view, for instance, you can make macros for the bitd on the VS/ALT gauge, the NAV/GPS switch, the Speed Brake and WARN indicators, the red BAT and ALT switches, even the Magneto switch. Maybe others. Of course most of these have adequate FS controls in any case. Regards Pete

Ah, my List of FSX controls is incomplete! No one's pointed that out before! I shall rectify that today. Alas, though, there seems to be no SimConnect variable with that name, so it looks like its status is not readable. All you can do really is keep your own status for it and reverse it each time you change it with the control. There are many such values simply not made visible. As I said, you could see if there's an L:Var for this. Regards Pete

Ah, HiFi beat me to the release! I'm at the final stages of preparing version 4.924 for release today. This suppresses those error messages when it detects as_btstrp.dll running. ASN uses the same hooks into the weather system as FSUIPC does for wind, temperature and pressure smoothing. There is no need and no point in FSUIPC also trying to do the same thing in any case, so the FSUIPC hooks aren't needed. Please do not worry about them -- update to 4.924 when available. There's also a new facility in 4.924 which can provide a display of ASN's plan weather weather data on WideFS clients. Andy -- you beat me to it, too! ;-) Regards Pete

Well, that was a daft thing for me to suggest. I'm copying an already created log file and expect to log things into it about it being copied? Duh! Anyway, I found the bug whch caused those two files not to be copied over. It only happens when you have both P3D1.4 and P3Dv2 installed, but not FSX at all. Just a scenario which I'd not tested till now, in the rush to get P3Dv2 supported properly. So it will be fixed in the next full install update. Thanks for your report, which allowed me to find this! Regards Pete

No objection. Of course. I'd need them to say what they'd need in Lua. I'm afraid OI'm not familiar with LINDA at all. It would need to be cooperative. They's need to change LINDA, I'd need to change the Lua library. Regards Pete

The FSUIPC4.LOG file is called FSUIPC4.LOG, not FSUIPC.LOG, but might just look like a text file if you have Windows set to hide the full filenames from you. I can see one problem which will make your FSX system pretty terrible and will certainly stop FSUIPC4 running properly and also many other SimConnect add-ons. Here: Checking version of the FSX EXE: ... Version 10.0.60905.0 (Need at least 10.0.60905.0) Checking compatibility with installed SimConnect: Found SimConnect build 60905 (Original) Found SimConnect build 61242 (SP1 May07) Found SimConnect build 61259 (Acc/SP2 Oct07) You have the original, buggy, version of FSX -- neither of the updates SP1 or SP2 have been applied. Yet you have all three versions of SimConnect installed, the original and the SP1 and SP2! How did that happen? If you insist on sticking with the original FSX version you will need to explicitly tell FSUIPC4 to use the RTM version of SimConnect -- it's a parameter documented in the Advanced User's guide. However, I'd strongly advise you to get your FSX fully updated. Regards Pete