Pete Dowson

It won't help anyone here, you need to tell_fs@microsoft.com. I think they are working on all this stuff now. At least, i darn well hope so! Pete

We never had any "offsets" for this. There are plenty of FS controls related to eyepoint, though I've no idea what they all do. Please see the list of FS controls. If you want to "send controls" via offsets, check offset 3110. Regards Pete

Yes, that's why the 32F9 offset was added. Yes, as documented. It also isn't held on if the brakes are decreasing. Well, it is held for a whole second (enough for at least 30 normal WideFS transfers and at least that number of Logic loops in pmSystems), so it shouldn't be a problem even if you simply "blip" the brakes. That was the whole reason for the 1 second hold. Have you got a very slow (i.e. high) pmSystems cycle time set? Regards Pete

These are control inputs (not read-outs) for the application of brakes with a pressure-decay release, as opposed to proportional brake inputs directly (eg from analogue toe brakes on pedals). The function dates back to FS95/FS98 and has been retained in FSUIPC all this time because it is used by some drivers for toe brakes, such as those for the Aerosoft GA28R cockpit. Sorry, I don't know anything about "strange values" getting into these locations -- show me some logs with the values Monitored (see FSUIPC Logging facilities) if you want me to check, but I think you are monitoring entirely the wrong thing to determine brake usage. It may only work because of the way your toe brakes are connected and driving FS. The braking indicator at 0BCA is more reliable, but the offset especially added for your precise need is the one at offset 32F9. Regards Pete

Ersorry, I'm lost. You want more than 8 (eight) programs started by FSUIPC3 or FSUIPC4, or you are just not clear on what to do? The facilities for FSUIPC3 or FSUIPC4 to run programs for you when you start FS are set by parameters in the appropriate FSUIPC INI file. The one for FS2004 is called FSUIPC.INI and is in the FS2004 Modules folder. The one for FSX is called FSUIPC4.INI and is in the FSX Modules folder. They are simply text files and can be edited in Notepad or any other text editor. The instructions for creating the [Programs] section in those files and putting the parameters in for each program you want to run should be clear enough -- there's only one line for each program to be run, after all. How complicated can it be? Please check the section in the Advanced User's guide entitled Programs: facilities to load and run additional programs I'm sure you shouldn't find anything difficult. It's only relegated to the "Advanced Users" documentation as it isn't a commonly used requirement and unnecessaary in the general Users Guide. Regards Pete

Well, obviously you can reduce it. For example, 0.9 is less than 1.0, so if you set 0.9 you would have reduced it! I've no idea what value you should use. On my PMDG 737 the value is 1.0 and everything works as it should. Evidently the model aircraft you have behaves differently. Why not simply do a binary chop (halve it, then halve the difference etc) till you arrive at a value you like? Pete

Yes, you need FSUIPC3 installed in FS9. It's available from the Schiratti download site. Doesn't the ActiveSky install do that, or at least explain anything? Yes, but not at the same time, and yes, and the FSUIPC version for FS9 (3.71 at present). They won't be running at the same time in any case as you surely cannot run both FSX and FS9 at the same time on the same PC. Even if you could, how would ActiveSky know who to talk to? Pete

Looking at the end of that file: This shows that the last amendment was, in fact, the addition of the MyTraffic version of the traffictoolbox -- FSUIPC4 currently always adds itself to the very end, just before the " terminator. The question therefore arises -- how was the MyTraffic part added. When I bought and installed MyTrafficX I had to edit the DLL.XML myself -- does it now come with an installer which does this? If so, then please send a report to the MyStraffic support for Mr. Renk to attend to, as that needs fixing. If on the other hand, you had to edit yourself, then possibly you made a small error? I have changed the FSUIPC4 Installer to do this: 1. Create a completely new DLL.XML, placing its own entry first. 2. Copy any other entries (except its own) from the original DLL.XML, keeping the same order. This will, I hope automatically correct the sort of problem you found when re-installing FSUIPC4. Regards Pete

No version of the FSUIPC4 Installer has ever omitted any part of the complete section needed. I don't know how your file got corrupted like that, but if you think you can reproduce it, would you mind kindly sending me the original DLL.XML file which you start with, before installing FSUIPC4, so I can see what is happening? Did you install anything AFTER FSUIPC4 which may have changed the file? The Installer, if it finds no DLL.XML file at all, writes the whole thing. If it finds a DLL.XML file but no mention of FSUIPC4, it adds its complete section -- and ALWAYS includes all the lines necessary. What it doesn't do is check all the lines are correct from a previous installation, so that's probably something I can improve upon. I may do that for the next release. Thanks, Pete

Sounds like either an aircraft sensitivity scalar setting (in the specific Aircraft.CFG file), or possibly you have the Yaw Damper engaged and that is being rather over-effective? Regards Pete

Unless you use the "RAW" option in FSUIPC the Windows calibration is always applied. The Raw option tells Windows to supply the raw uncalibrated inputs from the device. I have no idea where it is in XP, though certainly it was always in the Registry for Win95/98. I haven't delved underneath the Windows interfaces for a long time (no need), but there are details of Win95/98 in my EPIC95 package still. Here, for example, are some Win98 registry entries (from the REG files in EPIC95.zip): [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\MediaProperties\PrivateProperties\Joystick\OEM\EPIC] "OEMName"="EPIC programmable system" "OEMCallout"="epic.vxd" "OEMCalWinCap"="EPIC programmable analog calibration" "OEMTestwinCap"="EPIC programmable system test" "OEMData"=hex:03,00,08,00,20,00,00,00 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\MediaResources\joystick\] "JoystickUserValues"=hex:00,10,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,ff,ff,00,00,ff,ff,00,00,ff,ff,00,00,ff,ff,00,\ 00,ff,ff,00,00,ff,ff,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\MediaResources\joystick\\CurrentJoystickSettings] "Joystick1Configuration"=hex:07,00,88,01,20,00,00,00,07,00,00,00,01,00,00,00,\ 01,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,ff,00,00,00,ff,\ 00,00,00,ff,00,00,00,ff,00,00,00,ff,00,00,00,ff,00,00,00,80,00,00,00,80,00,\ 00,00,00,00,00,00,80,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,1f,00,00,00,0f,00,00,00,00,00,00,00 "Joystick1OEMName"="EPIC" "Joystick1OEMCallout"="epic.vxd" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\MediaResources\joystick\\JoystickSettings\EPIC] "Joystick1Configuration"=hex:07,00,88,01,20,00,00,00,07,00,00,00,01,00,00,00,\ 01,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,ff,00,00,00,ff,\ 00,00,00,ff,00,00,00,ff,00,00,00,ff,00,00,00,ff,00,00,00,80,00,00,00,80,00,\ 00,00,00,00,00,00,80,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,3f,00,00,00,0f,00,00,00,00,00,00,00 FSUIPC doesn't access any of this stuff directly. It simply asks Windows for readings from Joystick N via "joyGetPosEx" calls. A flag tells Windows whether RAW or CALIBRATED values are required. Regards Pete

It's because FSX's SimConnect closes me down so quickly, without any prior notification. It's why I couldn't implement an automatic save of "Previous Flight" on close down too -- the facility I need which they omitted in FSX! I always used that to make sure my aircraft is found next time where I parked it last time. :-( The PFC driver does actually send out the correct code sequence to clear down all the avionics displays, but they get purged from the serial port driver by the threads and processes disappearing. I have found a way around that, using a more persistent thread and delaying tactics, and have it working here, in a new version of PFCFSX.DLL, but I had a couple of other things to do before releasing it. It will be version 4.00 and should be available tomorrow, or soon after. Meanwhile, I suggest that when you finish your flight you cut the engine(s) and turn off the master battery and avionics before closing FSX. They displays will go off then in any case. Seems a sensible and realistic thing to do at the end of a flight? Regards Pete

You don't mean you never even calibrated them in Windows first? :shock: FSUIPC and FS both just read what Windows provides, so if you use uncalibrated joysticks I'm surprised you got anywhere close! Even so, if they remain perfectly alighed they it sounds like they must be digital rather than analogue pots. Pete

No, sorry. SimMarket do all the work leaving me to develop and support, and they are very effective. I asked the management and they said you "paid by check via paypal, and paypal just like anyone else waits for the check to clear before sending any payment". This is why they cannot do anything about it. I maintain a small PayPal balance for immediate purchases, which makes the difference. Regards Pete

Actually, now that the system has been fully automated most of the time they are supplied within minutes, not even hours. This only doesn't apply for uncleared monies, such as through unvalidated PayPal or cheques through the post. The PayPal method was only added recently of course. A validated PayPal account should be pretty much instantaneous -- it has been for me through SimMarket for other purchases. I'm very sorry -- I don't know who you spoke too, but I've found the management to be very helpful, friendly and first class. I have no intention of moving as they have always been excellent. I shall of course forward your complaints, but I'm sure you must be misinterpreting something here. Regards Pete

These are not the "factored" values, which would be in degrees. For where? 40.62 degrees North and 0.378 degrees West? How can I tell where you are? Is "Result" a floating point value? I don't see it defined anywhere. If it is an integer value it cannot retain any good value. Yes, as does the documentation. And what is the result in FSInterrogate? You don't say. How can I compare your result? Pete

Why is there any problem? I don't know Delphi, but the conversion is only arithmetic, involving multiplications and divisions only, as documented. I'm certain Delphi can do such things -- have a look at FSInterrogate, which is written in Delphi. Regards Pete

Okay. Feeling a lot better today! ;-) It's working fine with the Boeing suite (CDU + PFD/ND) -- the CDU displays the legs and the ND shows the magenta route line as well as the waypoints. The problem must be specific to the pmRJ package. Sorry I can't help with that. Regards Pete

I did add that -- check the FSUIPC4 log, it will say if it recovered. Regards Pete

I've been down with 'flu' or something these last few days, and only attending the PC to answer questions and emails. Sorry. I hope to get to it soon. Pete

Hmmm. A bit of a waste of axes when fuel cutoff/idle is really only a toggle lever/switch? How have you done it for the Gear on an axis, then? If you've been assigning controls in the right-hand side of the FSUIPC axis assignments tab, then it is identical for FSUIPC offsets. You just need to use the "Offset" controls for that instead of the "Gear" controls. For SETTING a bit, you'd use Offset Byte Setbits, for Clearing a bit you'd use Offset Byte Clrbits. In the above cases the offset is x561A for both left and right, but the bit value is 1 (=2^0) for Left and 2 (=2^1) for Right. The offset values go into the Offset field (which will magically appear when you select an Offset control), and the bit values go into the Parameter field. Regards Pete

Yes, it does. Yes, all versions of FS are like that. They do not make good use of multiple processors. Yes, FSX is very demanding and quite fragile, especially if you run it in full screen mode. If you want to do other things I would recommend you only ever run it in Windowed mode (ALT + ENTER). It also seems less likely to crash or hang in Windowed mode. It sounds very much like a typical Simconnect problem with two Simconnect clients running. Please gather all the information you have on this, including what you've told me here and send it to tell_fs@microsoft.com. It might be a good idea to try FS with one one of the Simconnect clients at a time, just to prove that it is okay then. Okay. I'll have a look ... ... Hmmm. Odd. No useful information in the SimConnect Log, because just after Active Camera has started, two other starts must occur but all the information has been replaced by ".... info removed"! How did that happen? Here: Active Camera is client #63somewhere in the intervening 302 seconds (which you've removed?) FSUIPC starts, and presumably restarts? Or something else? The following line is about Client #61, so a whole client #62 has come and gone already! Why is this a secret? If you are going to send any stuff to MS I would advise not to delete all the possibly important parts! ;-) Anyway, try a complete flight with Active Sky but without Active Camera. Regards Pete

To get a SimConnect LOG Create a file containing these lines: [SimConnect] level=Verbose console=No file=path to logfile\SimConnect%01u.Log file_max_index=9 file_next_index=1 where you need to replace the "path to logfile" by your particular path where you want to store the log file, and save this file as Simconnect.ini in your - for FSX: My Documents\Flight Simulator X files folder (or, for a non-English Windows or non-English FSX, the folder where FSX stores and loads your saved Flights and Plans). - for P3D: <USER>\Documents\Prepar3D v? Files folder (replacing '?' with the P3D version number - for MSFS Steam installed versions : <USER>\AppData\Roaming\Microsoft Flight Simulator folder - for MSFS MS Store and boxed versions: this will be in one of two places, either <USER>\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState or <USER>\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache depending on where your UserCfg.opt file is located and your FLT files are saved. (where <USER> indicates your top level windows home folder) The Log will be found, after or even during your sin session, in the specified location. With the options as shown you will get a file "SimConnect1.Log" first, then on the next session "SimConnect2.Log" and so on, with it cycling to 0 after 9, overwriting previous copies. If you run the sim in Windowed mode you can, if you wish, set "console=yes" to see a real-time display of what is going on. Regards Pete

That seems to happen quite a lot with FSX. It's normal to see the Traffic reloading if the time has been changed by more than a minute or so, and it might even be reloading if the weather is changed significantly. I see you are running ActiveSky -- is that the 6.5 update? Do these events coincide with a weather update? Well, this doesn't look good: Seems that something is preventing Simconnect operations here. Do you have any other SimConnect client programs or DLLs running? Simconnect seems to stumble quite easily at present when more than one program is using it. Then: seems to be ActiveSky repeating its initialisation attempts again, over and over, every 6-7 seconds. I'm not sure what would make it do that. Possibly the new (third) connection to Simconnect isn't functioning properly either? IIn a P.S> below you'll find directions for getting a Simconnect Log, which may help work out what it is doing. At least it may provide more detailed evidence to send to Microsoft. I hope and expect that they are working furiously on fixing all these things right now, but to what timescales I really have no idea I'm afraid. Regards Pete To get a Simconnect LOG: Create a file containing these lines: [simConnect] level=Verbose console=No file=C:\SimConnect%01u.Log file_max_index=9 and save it as Simconnect.ini in your "My Documents\Flight Simulator X files" folder. The Log will be found, after or even during your FSX session, in the C:\ root folder. You can of course set the path to somewhere more convenient. With the options as shown you will get s file "SimConnect1.Log" first, then on the next FSX session "SimConnect2.Log" and so on, with it cycling back to 1 after 9, overwriting previous copies.

That's because the two throttles use separate pots or optical devices which, no matter how similarly you calibrate them, will ever give identical results for identical positions. This is especially true of analogue poentiometers, whether wirewound or carbon or similar types. The best you can do is merely ensure that the idle and max thrust areas match so you can always 'park' them there without looking. This is not unrealistic. You don't really think that the separate throttle levers on a real aircraft are giving exactly the same N1 or N2 when at exactly the same position do you? In all my cockpit rides (before 9/11 of course) and in all the cockpit videos I've seen the throttles are rarely in a dead alignment. Surely one of the extra realistic parts of your sim now is that you have to adjust them separately (slightly anyway) to give a balanced thrust? Regards Pete