Pete Dowson

I use it in FSX. You can detect and set fires and put them out. I have them operating here. Only the APU isn't so amenable. 2^0 means 1, 2^ 1 = 2 x 1 =2, 2^2 = 2 x 2 x 1 = 4, 2^3 = 2 x 2 x 2 x 1 = 8, and so on. The ^N notation is just superscript, x^2 is "x squared". I don't know what you are writing there, but what is important is not just the offset and its size (1 byte) but the VALUE in that byte! Fior example: 01 = only pump 1 02 = only pump 2 03 = pump 1 and pump 2 04 = only pump 3 05 = pump 1 and pump 3 and so on. The bits inside the byte are the pump switches. A byte has 8 bits so can accommodate 8 switches. Only 4 are used here, as in the case of 3366 for engine fires. Isn't there any documentation to help you with whatever program it is you are trying to use? Pete

Phew! Thank YOU. I don't know what I could have tried next. I still don't understand what causes the problem, but the clue to this solution was that the Lua programs worked but FSUIPC's own VRI stuff didn't -- and the only difference was that FSUIPC was opening and closing the COM ports in the main FS thread whilst the Lua programs are all in their own threads. Good, very good! Beer it would bethanks! Pete

Can you try 4.609 please, with any of the settings which fail? http://fsuipc.simflight.com/beta/FSUIPC4609.zip This time I've re-vamped the whole operation, with each VRI device in its own thread, just the same as if they were being controlled by Lua programs (which doesn't have the same problems). If this doesn't fix the errors you are getting I'm out of ideas for now. I'll be able to test on my own cockpit by the end of the week, but it is out of commission for now. Regards Pete

Ah, well spotted Andy! Thanks. Pete

Yes, as you've already described. It is caused by dual assignments, wherever they may be. FSUIPC does nothing you don't tell it to do! Sorry, I don't understand this part. What SET button and what value? The centre SET has two values so needs two presses. None of the others do. The main SET/RESET button on the left controls whether the axis is calibrated or not. None of the buttons will allow impossible calibrations -- numbers have to increase left to right or they are not accepted. If you move things between USB ports, their joyistick ID numbers change. If you then make new assignments to the new IDs the old assignments still stand with the old IDs, so when something else is plugged in which gets those IDs you get dual assignments. Unplugging and moving things around is the biggest single cause of confusion and dual assignments. If you've been moving stuff, or don't leave things plugged in all the time, then you really either need to DELETE your entire Axes and Buttons assignments sections every time you move or unplug anything, OR, much easier, use the joystick lettering system provided in FSUIPC in order to allow it to keep track of named joysticks and change the assignments for you automatically. If you want me to analyse the reasons for the mess, please post the [Axes ...] sections from the FSUIPC INI file here and I'll point out where the problems are occurring. Please also include the [JoyNames] section (which is where you could assign devices letters). However, really your best bet now is to delete everything and start again, but before loading FS again, first enable Profiles to cut down on the huge number of "aircraft specific" sections you might generate (adding to your confusion), and enable joystick lettering so that FSUIPC has a chance of doing reassignments when you move things. Regards Pete

Version 4.53 is well out of date and not supported. The oldest supported version is 4.60 which has been available now for over 4 months. As it tells you in the documentation, not al methods used by gauge programmers are susceptible to the mouse macro facility. Almost none of the gauges used in default Microsoft aircraft use the standard C/C++ SDK methods. Did you try using Search for "fire"? Here it finds offset 3366 on the third or fourth match. As documented, there are 4 separate bits for 4 separate pumps in offset 3125. Regards Pete

FSUIPC 4.3 is very much out of date and is not supported. Furthermore, the FSUIPC4 installer has no message about "downloading". There is no Internet access in any of my programs. It is up to you to download FSUIPC4. Please update to a supported version (currently 4.60 or later) before asking for Support. If you haven't heard of it you aren't using it so that is not the problem. I suspect your problem with FSCommander is about file access, and probably nothing to do with FSUIPC or any of my software. I can only advise that you contact FSCommander support. After all it is their message we are trying to understand. Regards Pete

I'm afraid that isn't anything to do with any of my software. You'll have to consult the LWThrottle documentation or contact their support to see how to configure it. I can only support my own programs. which shows you are using version 3.96 which I cannot support. Please update to a supported version before coming back for more help (with MY programs! ;-) ). Regard Pete

That's part of the log, with bits missing at the beginning and the end. The first few and last few lines tell me things too. Please don't remove useful information. It also appears to have been tampered with too, because I know there's no mistake in the message: Anyway, as it happens the answer looks clear nevertheless. However, here's the big clue: So, it appears that you still didn't read my original reply nor the repeated copy. :-( I'll repeat it yet again with the very relevant part highlighted: I can't tell for sure without a complete FSUIPC log, but the usual reason is either an invalid registration key, or an incorrect system date which makes the key look invalid because it was purchased AFTER "today's" date. See? You could have checked this very easily and corrected it in a flash! ;-) Regards Pete

I don't know. It isn't one of my messages. Have you any documentation for FS Commander 8.6? Perhaps they have some support? One thought: maybe you haven't installed FSUIPC? Or maybe it isn't running for some reason? Have you checked? Also, if you run either FSX or FSC "as administrator" you have to run both "as administrator" -- or neither. Windows stops programs of different levels talking to each other. Pete

Okay. It is corrupted. Looks like the installation of "FeelThere PIC737X Helper" went wrong. Edit this part, near the end, deleting the two lines I've coloured red: FeelThere PIC737X Helper False< FSUIPC 4 False Modules\FSUIPC4.dll If that "Helper" is important to you (it couldn't have been loaded in any case) you might need to re-install it. I can't fix that with the information here. If reinstalling it again corrupts the file you'll need to complain to FeelThere, but at least you'll know what to do. Regards Pete

Okay, then you most certainly have double assignments. There are no assignments there -- that's the joystick calibration section. The values you see moving are only reflecting assignments made elsewhere, either in FS or in FSUIPC, or possible both. Really? Why? Doesn't documentation help or don't you use that? Assignments of Axes are in the Axes tab, assignments of buttons are in the Buttons tab. Assignment of Keys are in the Keys tab. Why isn't that clear? So, then, you have dual assignments in FSUIPC. All FSUIPC files are in the FS Modules folder. That's where you find FSUIPC.DLL, FSUIPC.INI, FSUIPC.LOG and FSUIPC.KEY. You'll also find all of the FSUIPC documentation (which, if you are up to date with FSUIPC should be in their own folder inside Modules), which I suggest you peruse, or at least look up the sections you seem to want to use but don't know how. If there's no good reason to assign things in FSUIPC I suggest you simply delete the FSUIPC.INI files and leave it all to FS. What's this "delete assignments" you are talking about? Where do you see that? To start from scratch just delete the INI file before running FS. Then none of your settings in FSUIPC will be there any more. Why? You are making things much more complicated. Please only use facilities you understand, or at least have read about beforehand. Regards Pete

The usual reason for this is that you have a corrupted DLL.XML file. There are a few other add-ons which sometimes mess it up during their own installation. The FSUIPC4 installer does its best to correct blatant errors in that, but it is not a full XML parser and can't fix everything. You definitely seem to have other entries in there. Find the file (DLL.XML) in this folder: C:\Users\Dave\AppData\Roaming\Microsoft\FSX\ and paste it into a message here. Use notepad or some other ordinary text editor to cut and paste it. I'll look at it and tell you how to fix it. Regards Pete

As well as, or instead of, the elevator and aileron? Did you check all controllers in the drop down, or do you only have the one? There is no display of throttle values in any Assignments tabs in FSUIPC. There's an axis assignments tab which shows axes and allows assignments, and a separate Joystick Calibration tab which reads incoming FS controls from either FS or FSUIPC assignments ("IN") and shows the effect on the assigned controls ("OUT"). So please differentiate between ASSIGNING and CALIBRATING. Where are you seeing what? And in any case, if you are assigning in FS what are you doing in FSUIPC assignments, if indeed that is where you are? If it is assigned in FS you remove that assignment in FS. If it is in FSUIPC you remove it in FSUIPC. If you really cannot figure FSUIPC out just delete the [Axes] sections in the FSUIPC INI file. Then FSUIPC won't be assigning any axes. I can't help with FS assignments -- FS help should be okay there. For FSUIPC if you are in a total mess and don't understand what you've done, simply delete the INI file (or the [Axes sections only) and start again. It will probably be easier for you if you stick to FS assignments. FSUIPC's are probably over the top (too powerful) for your needs. You can still calibrate in FSUIPC, just don't use the Axes tab if it confuses you. It is really intended for more advanced uses such as assigning different controls to different aircraft. Regards Pete

It just occurred to me: I fly FSX exclusively. When you say ASE and FSUIPC do you mean FSUIPC4, or are you using ASE with FS9? If so Ithere's no point in me showing you anything because I don't have FS9 on the system I fly, only on me development test PC (along with FS2002 and FS2000). If you do mean FSX, then the settings are pretty much default I think, but I'll try to remember when my system is back up. The cockpit is in pieces at present whilst a PFC engineer is make changes (new overhead with indicators and gauges! ;-) ) and assorted repairs. The only annoying thing I notice on occasion is silly fluctuations in the barometric pressure when descending, or on early approach. That was mostly with ASX though. So far not noticed it so much with ASE and I'm hoping the SP! update will have eradicated it entirely. I haven't noticed the wild fluctuations (180 degree swings) in wind directions recently, but those are certainly a typical symptom of the bug in FSX which even my FSUIPC4 hacks can't entirely eradicate as they did in FS9. Can you ask me again towards the end of this week when I should be back up with a working cockpit? Regards Pete

There's no direct setting per aircraft, but you can assign a button or keypress to increase or decrease the speed, or toggle it between 1x and 4x. These are listed in the Buttons/Keys assignments as Wheel trim fast Wheel trim slow Wheel trim speed toggle It should be easy enough to use these to adjust after you've loaded the exception, but if you wanted it automatically changing when you loaded an aircraft you'd need to create a pair of control macros to do the speed toggle and list the appropriate one in an [Auto.] section of the INI file for each aircraft. The [Auto] option was added early last year and is described in the Advanced User's guide. Let me know if these facilities are not sufficient . I could consider having a copy of the "MouseWheelTrimSpeed" parameter local to an Aircraft's setting -- but which? Button or Keys? I don't want a new section just for Mice! ;-) Regards Pete

Strange. rarely find that, though it is possible -- it results from an interpolation bug in FS. It should be okay at the airports themselves however. DWC uses global weather. Basically it overrides the local weather station facilities in FS and makes the weather the same all over the world. This stops the interpolation bug because all the values are the same, so interpolation does nothing. It really puts the weather control back to the only method which could be used in FS2000 and FS2002 days. The problem then is that you have to use ASE's own ATIS reports -- FS's and other programs weather read-outs for weather stations will only give the same weather as that at the aircraft's position, because that's all their is. Things like weather radar become rather useless too. Sorry, I don't know what they are a result of. I would have thought having the same stable weather everywhere would make it easy for such delicate aircraft to fly correctly. I use pretty much default settings in ASE, and smoothing in FSUIPC, without particular problems. I've recently installed the ASE SP1 update but not been able to fly since, but maybe that's better? The ActiveSky folks are really the experts on FS weather control and you should try following their advice generally. Regards Pete

Good! Thanks for letting me know! Regards Pete

The reason I changed to using an installer was to get over folder protections when FS is installed in its default "Program Files" place. The installer also checks that the GlobalSign signature will be accepted and runs a program to update that in Windows if it isn't already available. These are steps which are not easy for most users. The installer also creates a subfolder for the documentation, and installs that and other goodies for you information and pleasure. Not that it's relevant to you, but for FSX the installer is also necessary to get FSUIPC running in the first place, as it needs to edit system files installed by FSX to tell it to load the module, and for both FS9 and FSX using an installer automatically provides privileges sufficient for FSUIPC registration. No, only to use its user facilities. I would strongly advise against just copying in any old FSUIPC.DLL without first running the Installer. If you do this please do NOT come back here for help with any problems you create! Regards Pete

Ok, glad you got it sorted out! Regards Pete

Okay -- that makes a difference. I'll try to work out what's different at the END of the session instead of at the BEGINNING! ;-) Pete

No, i said I cannot reproduce that here because the only system I can use ASE on is dismantled at present. A PFC engineer is here making changes to my cockpit. I should be able to test correctly next week. But I believe you, and I don't think I'll find anything on my system in any case. That's the problem -- trying to track down a problem which seems so absolutely unrelated to its apparent cause! Until you asked about this i've never had ASE running between FS restarts. I always close all ancillary programs. Project Magenta has never been terribly friendly on FS restarts and many programs close in any case, automatically. ASE is running on a Networked PC, not on the FSX PC, but I doubt that this would make a difference. I suspect most other users of the VRI facilities in FSUIPC are running FS9. But, then, I would always EXPECT a SimConnect failure when a program connected to FSX via SimConnect is still running when FSX closes. It is usual with programs which do not process the "SimConnect Quit" message which occurs when SimConnect detects that FSX is closing. That shouldn't be any problem. I always thought you were saying that the error occurred when ASE or whatever should be reconnecting when you next load FSX! Soit sounds like it isn't a START-UP problem as I thought you were describing, but a CLOSE DOWN problem. I'll looks at that instead now you've explained more. ;-) Regard Pete

Is that, "no (good), (still) HRESULT error", or "no HRESULT ERROR (whoopee)"? If the former, then it is getting really really badnow the ONLY activity different from using the Lua connection only is occurring before SimConnect is involved in FSUIPC at all. I've only one more thing to try -- the separate thread. It's getting towards the point where I'm going to have to consider withdrawing the facility. :-( Pete

Can you try 4.608b please, with any of the settings which fail? All I've done is move the COM port opening to just BEFORE the SimConnect initialisation. http://fsuipc.simflight.com/beta/FSUIPC4608b.zip No TestOptions line for this. Regards Pete

Well, it's a challenge. But I do prefer to have some better clues as to what is happening. I still really haven't a clue -- although it seemed as if we were narrowing it down, it is narrowed down to nearly nothing -- i.e. no code! So it must be something different. I am now thinking it might be timing. FSUIPC is opening the COMport(s) at the same time as something esle is going on, not sure what, and something is thereby being messed up. If so, it's a bug elsewhere, maybe in SimConnect, so one I'd need to find a work--around for. As you can see in the Logs, the ports are opened as soon as FSUIPC thinks FS is "ready to fly": 53602 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N 53664 VRI port 1 "COM3" opened 53664 VRI COM3 <--- CMDRST [from FSUIPC init] 53836 System time = 07/05/2010 16:13:22, Simulator time = 16:12:34 (14:12Z) 55053 Aircraft="Beech Baron 58 Paint1" 55053 VRI COM3 <--- CMDCON [from FSUIPC init] 55240 Advanced Weather Interface Enabled Originally i was opening them very early, even before connecting to SimConnect. I moved them as an experiment to get over the problems you were having with the VRI device not initialising very often. We never actually solved that issue, just messed trying different things till we got an improvement. So, maybe I should try earliermaybe before initialising SimConnect. Or else, maybe later -- I could possibly delay them till that "Advanced Weather Interface Enabled" action has completed. However, if I do that I'd also have to delay the Program loading actions, which might annoy some folks if their application starts later. Hmmm. Thinking ... Regards Pete