Pete Dowson

Thanks for letting me know. It wouldn't be "the FSUIPC entry" as FSUIPC doesn't change the registry at all, but it does read the install details for P3D from the Registry. Regards Pete

All you need to do for writing METAR strings is write them to B000. If you set a WRITE command in the C800 area it will instigate a New Weather Interface weather write, as you can see from the log -- the weather data is then taken from the FS9-compatible areas of C800-CFFF, which because you've not set them up look like, er, rubbish. I notice that the Offsets documentation for B000-B7FF is a little misleading. Sorry about that -- I'll fix it. It says "For GLOB or ICAO ID, set in C8xx area", which isn't necessary as the station ID is included in the METAR string. There's certainly no need to write a command or check any timestamps. That's all totally related to the NWI part, except for READING a METAR string, which is of course the same action as reading in the NWI (there's no other way of saying which weather you want. FSUIPC gets the string from SimConnect, dumps it in the B800 area and decodes it for the main NWI binary areas. The other thing to notice is tthat the format for Writing METARs is not completely identical to that for Reading them. Blame Microsoft. I think they had different programmers doing the two parts who didn't talk to each other! The only way to suss this out fully is to look at examples. Use Weatherset2 or ActiveSky or similar, nd do a SimConnect log so you can see the formats being read and written. I think you are only the second person to want to use the FSUIPC4 METAR string method instead of the FS9/FSX compatible NWI methods. Regards Pete

if you have an FSX installation already, just copy your FSX Modules folder over to P3D and adapt your DLL.XML file to suit, in the same folder as Prepar3D.CFG. I'd still like to see the Install log, please, in case there's something FSUIPC's installer should handle better. Regards Pete

Looks like the P3D installation isn't registered in the Windows Registry. Have you restored Windows to a previous setting since installing P3D? Which version of P3D are you using? If you can paste in the FSUIPC Install Log it would be useful in working out what is wrong. I know for certain that the current version of the Installer works without there also being an FSX installation Pete

Sorry, I don't know what you are saying. Is Button B a normal joystick button, or is it something programmed in the Saitek driver? And why do you want to use Ctrl+Shift+Z instead of assigning directly to the FS control you name? The Key Presses tab is for programming actual keyboard presses, not buttons. Do you really mean it is active and you can use it. So why not? If you really meant the reverse, that it is "inactive" so you "cannot" use this option, then FSUIPC is not seing your joystick device at all, or you are not pressing any of its buttons. FSUIPC uses the same method as FS itself for reading the joysticks, so if FS cannot see it nor can FSUIPC. I'm thinking that you are using some Saitek software which takes these facilities away. Maybe you need to uninstall that, or maybe program what you want in that instead? Regards Pete

All your settings are stored in the FSUIPC4.INI file, in the Modules folder, and that is never touched or altered by any install or replacement DLL. You can even just copy it to another installation (for instance if you have FSX and P3D both installed). It is the file you should backup, along with your FSUIPC4.KEY file which contains your registration. Regards Pete

Nor do I. You'd at least need to describe what it does. Are you using the FSX default Baron? If so, then it simply adjusts the white subscale on the airspeed indicator, nothing else. It is local to that gauge and there is no other control for it at all. It isn't even susceptible to a mouse macro. If you are using an add-on aircraft with its own panel then it may have a different implementation which might work with a keyboard short-cut, mouse macro, or maybe even an L:Var (local panel variable). Regards Pete

What coding are you using for that? Is it in a Lua plug-in? Monitor those offsets (right-hand side of Logging tab) to see what is happening. The switch will stay as you set it via the offset unless you really are writing zero. If it is going off and on you must have more than one thing writing to it. The normal way of triggering them off is to watch for the combustion flags (092C and 0894) then set the OFF value. This is what the FSUIPC-added autostart controls do (as well as enabling fuel at the appropriate time). Pete

Actually it wasn't that bad -- only 7 years. FSUIPC3 wasn't affected as it involves specific SimConnect event trapping mechanisms. These controls were omitted from the list: ADF, DME and VOR_OBS (default keyboard shortcuts Ctrl-Shift-A, F and Shift-V). The main ones, for NAV and COM radios were already there. Fixed in 4.909d which you can get here: FSUIPC4909d.zip Or wait for a week for the next main release, 4.91. Thanks for reporting this. Regards Pete

Sorry, I've no idea what it is doing nor why. I've never heard of it. How did you do a "report on your PM setup"? Perhaps this is a matter for PM support? Regards Pete

Hmm. strange. I'll check. Normally those FS controls which select something based on the next keypress being a "select N" contorl (1, 2, 3, 4) have to be protected from those add-on panels which continuously send FS controls, so FSUIPC assists by "holding them over" when a selection is pending. All that happens with Shift+V is that it sends an "VOR OBS" control. When you use + (PLUS control) or - (MINUS control) afterwards, it is converted to a VORn OBI INC or VORn OBI DEC control according to the SELECT n key pressed, or VOR1 by default. I suspect what is happening is that the VOR OBS control isn't on FSUIPC's list of controls needing SELECT protection. [LATER] Yes. That was it. Neither the 1 nor 2 have any effect because FSUIPC doesn't know that "VOR OBS" is one of those controls which uses SELECT. I expect there are others in that case. Odd that it has bothered no one for over 14 years now! I expect most folks use the controls directly, via key or button assignments. I'll have a look. Regards Pete

All that does is select the "clear weather" theme, in order to clear the weather. The first click just resets any weather set by an external Weather application which set its weather through FSUIPC, the second click does the weather clearance to effectively select "no weather". It isn't "on" or "off" at all. It's an action. and it really isn't relevant unless you are setting the weather through an FSUIPC application. There are no user facilities in an unregistered install of FSUIPC except that one, which is related to weather setting FSUIPC applications, and the option to divert messages sent to fSUIPC for display on the FS screen. Oh, and the logging facilities. An unregistered install is only useful as an interface to FSUIPC-using add-ons. If they read the weather through FSUIPC it needs no action whatsoever on your part to enable this in FSUIPC. It is just one of the interfaces supported for any application or add-on. No, you do not need to register in order to enable the application / add-on interface. Just install it. That's all. Pete

I don't know where you get these stories about FSUIPC from. There has never been an update to FSUIPC related to start switches because FSUIPC has nothing to do with start switches unless you assign something to them for FSUIPC to obey. In that case it is your assignments which need investigating. Additionally software isn't in the habit of changing by itself. If something has started to go wrong with something you are using for start switches then it is that which is suspect. Maybe a button or switch sticking or something? For button and switch assignments you can enable button and key logging. For the events being sent to FS you can use Event logging. These are two of the selectable options on the Loggng tab. Regards Pete

Sorry, what "Weather button" on what "FSUIPC cfg panel"? I'm lost here I'm afraid. Also, I don't know the aircraft and didn't even know it used FSUIPC. I think you need their support to help with this. BTW, I suppose you do realise that you added this message to a 4 year old thread about a completely different subject? Isn't yours important enough to merit a fresh thread? Regards Pete

Well, there is a facility already to only do autosaving in the air. In fact that's the default option. Would that not be suitable for all profiles in any case, or do you have many accidents on the ground? Pete

Great! Forgotten it. All's well that ends well. ;-) Pete

The partial log obtained when you allowed FSUIPC4 to run is interesting. The only recent problems with a log which stopped exactly there were due to a bad device installation, one for a "Razer Nostromo Keypad". The problem, an erroneous Registry entry, caused FSUIPC's joystick scan (only performed for registered users) to go into a loop. This was corrected in version 4.902. Generally if you have a problem with FSUIPC (and it is actually running, as seen from a Log file), it is a good idea to see if there is an update. So, please go to the Download Links subforum and get the current interim update, 4.909, and see if that helps. It is only the DLL itself. Just place it into the Modules folder and try again. I think that will help. If not then at least you will have a version in which I can get more information by telling you how to enable more detailed logging. Regards Pete

No need for a video. You showed the same error message as shown in the FAQ thread I pointed you to. All you need to do is tell FSX to carry on and run FSUIPC4. Pete

So, what was all that about the menu? When you get that message, did you tell it to carry on and run? If so what then happened? Have you actually ever looked into the FSX Modules folder to see if there's an FSUIPC4 LOG file there, as I asked? Perhaps you would kindly read the thread in the FAQ subforum entitled fsx fails to run after fsuipc4 first installed , as this does deal with this sepcific problem (which is due to bugs in FSX, by the way). Everyone who has followed the advice there and persisted has eventually been able to get past it. If there is no FSUIPC4.LOG file produced, FSUIPC4 is not actually ever running, and so cannot possibily fail. It is the FSX SimConnect loading mechanism which has the bug. The SimConnect log will prove whether FSX ever got that far. Pete

Really? Please check again. I refer you first to my message of THREE WEEKS ago, as follows: Neither FS nor FSUIPC use .Net Frameworks in any case, so it sounds like you have something else going on there. Why is the title of tyour thread "FSUIPC not found"? What does that really mean, or is it irrelevant? What version of FS are you using? What version of FSUIPC? What exactly is the "error when starting", and when starting what -- FSUIPC or FS? I've edited it slightly by emphasising the first elementary questions which have not yet seen an answer. And then, in my message only 5 days ago, more requests for information still not supplied: You'll notice that, so you don't miss all the requests and unanswered questions again, I have emphasised those too. Based on the answers to those I might be able to help. I don't know yet because I have none of this information. Pete

Okay. Here's 4.909c with the auto-throttle sync cutout when you use a reverser. FSUIPC 4.909c only No need to retest with Lua plug-ins, unless you want to try with that parameter changed -- don't think it'll help much, though. Best Regards Pete

I've given up on this. There looked to be a way, and I part implemented it and tested it, but it is far too complicated and involves other changes all over the place, so I'm classifying it as "too risky" and "not worth it", especially considering there are other solutions. One thing you could try, to see if it's a little less jerky, is reduce the rerun delay. Here's the section of the FSUIPC advanced user's guide which describes this: I suspect though that since the execution time of those little Lua plug-ins will be much much less than 66 mSecs in any case, this will actually not have any affect. I'll upload 4.909c soon with the reverser fix. Pete

Okay. Verified the problem, that reverser axes operate like normal throttles instead when "throttlesync" is engaged. It turned out to be an almost impossible problem to resolve fully. The reverser axis implementation is really a sort of "front end" on the normal throttle actions, converting the calibrated value into a negative throttle value before using the normal throttle facilities. So it all becomes totally indistinguishable. Without a complete redesign of the whole axis assignment and calibration system -- which I am simply not going to risk at this stage -- the only safe way is to automatically disable "throttlesync" when a reverser axis is used. I think this will be okay. I'll document it so folks know. If you need to use throttle sync again after landing and using reverse you'll just need to enable it again. I'm looking now at ways of making the kill/restart sequence for Lua plug-ins smoother. I don't guarantee to resolve this -- but there again the better solution for such needs is to use the event system in any case. Still, I have some ideas which I'll try. I'll let you know when there's a version 4.909c to test for me. Regards Pete

Hmm. Strange. I'll check. Tomorrow, though. Pete

Hmm. So I hit the correct spot. But I don't like it being jerky. Of course, the best solution is to use the Event method instead, as already explained. But I'll have a think about how to alleviate the timing problems with the "kill/restart" method. Thanks for the testing. If I do thing of anything to improve it would you still test it for me, please? Pete