Pete Dowson

If you re-install Windows, or use a dual boot system, you need to register it afresh for the new system. And under Vista you need to take special precautions when registering because of the way Vista protects your folders and Registry. Please read the early sections in the User Guide which explain what to do on Vista. Pete

Ugh. I'vw never had that on -- very heavy on frame rates for some reason. If you know how it can be done without going into the menu I'll be glad to add it, but like many of the menu items I don't think it is possible, or at least not without someone who understands the innards of the graphics sections of FS code working out what to call or change. I'm afraid graphics has never been an area I've delved into nor understood much about. Regards Pete

Okay, I found it by trying all combinations of assignment/calibration on all 5 throttles. It's actually the same bug as reported in this thread: viewtopic.php?f=54&t=72340 which I'd thought i fixed, but evidently hadn't for all possibilities. I have found out why (a codition check in the wrong place!) and fixed it now in versions 3.829 and 4.315. Regards Pete

So the MCP must be using keystrokes for that, surely? Or it is some problem related to a proprietary software interface PMDG license to some hardware developers, which seems unlikely. I know some of the hardware developers around have paid PMDG for this, but have OpenCockpits? Or is it all in the "script supplied by someone"? I've no idea what sort of "script" can do such things, so please tell me more about that. Yhe statement its author made "I am also thinking whether RC is somehow trying to read these offsets" shows he may not know so much about what he is doing, as reading offsets cannot change them or block them, even if it was occurring. Reading is non-destructive. Do you know what offsets he is using? If so we could log those. Maybe I need to see this "script"? In FSUIPC's logging tab enable logging on Keys and also on Buttons. Do a short test just to illustrate the point -- reduce the heading and increase the heading, or rather, try. Tell me what you see happen. Keep it short please. Close FS, show me the log. Also tell me what RC keys are assigned. Regards Pete

Private offsets are completely up to the designer. No. In hex "C" or "c" stands for 12 (A=10, B=11, C=12, D=13, E=14, F=15), because hexadecimal is to base 16 instead of 10 like decimal. In FSUIPC you enter hexadecimal values with an "x" in front (either case), so x50c0 will do. Er, "A2" is just two characters "A" then "2". It means nothing more to me without column headings explaining what it means. That's why I asked. Well the crucial part in that is where it tells you offset 50C0 is 2 bytes! 2 bytes is a WORD (1 byte = BYTE, 2 bytes = WORD, 4 bytes = DWORD). So you'd use the FSUIPC control "Offset Word Set" with offset 50C0 and the parameter the number he tells you, the "last one". Pete

Good. Let's hope it stays good for you. Regards Pete

How odd. There's nothing changed as far as throttles are concerned. The change in 4.312 was for reversers only. I need more information -- specifically exactly how you have assigned and calibrated your throttles, please. Maybe the Axes and JoystickCalibration sections from the INI file if you cannot explain. Regards Pete

Okay. i too use RC4 on FSX, and previously on FS9. Strange. That could only be because there's a clash of keypress assignments. RC doesn't exert any control over FS whatsoever, it merely uses the FSUIPC "hot key" facility to drive its selections/responses. I can't imagine that something like a hardware MCP would have driving software which relies on keypresses. I use a PFC MCP wth Project Magenta's MCP software. But I know RC works with others, like the Aerosoft, CPflight and GoFlight MCPs for instance. No, but something is obviously conflicting. No, RC doesn't touch anything like that. it doesn't actually write much at all in FSUIPC, only menus and the hotkey stuff, and certainly cannot block anything. No, nor probably will I if it is a "script" for some proprietary driver. First, lets get some clarification. Is this occurring ONLY with the PMDG 737? Can you test with the default aircraft please? Let me know. Depending on that we can enable some logging which should help tell us what is happening. Regards Pete

Thanks for the feedback. Good flying! Pete

Why are yuo looking for it as an axis in any case? FSUIPC doesn't handle any Go-Flight axes anyway, or at least not as such -- only DirectInput or joystick axes. I've never seen one, but the GF-ATC device should have most if not all of its switches and things come up as Buttons in the Buttons and Switches tab. At least it certainly should do if an adequate version of GFdev.dll is installed (i.e. from the GoFlight install package). According to my code there's one dial and 4 buttons or switches catered for. I can't swear that it all works as it should since I've never seen one and I don't remember having feedback on it. The code's been in there a good while though. Regards Pete

Good. Thanks for the feedback! Pete

Well you can send any of the FS (or FSUIPC-added) controls via offset 3110, as documented. however, I am not sure what you mean by "without the ATC being selected". I don't use FS ATC (being a Radar Contact user), but I think the controls you listed are those used to select from an ATC menu. Doesn't the presence of the Menu necessitate ATC being "selected"? Hmmm. I didn't think it needs specific focus, unless perhaps you have undocked it, as when it is present it is stealing the keystrokes or controls it needs in any case. At least, it seems to. So the GF ATC panel uses keystrokes, not FS controls? That's rather surprising. Is there anything on the GF support forums dealing with this? But access to most all actions in FS is actually via controls (also known as "events" or "key events" -- I have always called them "controls" because they are tabulated in FS's "CONTROLS.DLL". That's what they are for. Keystrokes are assigned to controls. Gauges use controls. You can log controls in FSUIPC's logging facilities. Even when you have an application program writing to FSUIPC offsets in order to get something to happen, more often than not all FSUIPC is then doing is sending the requisite control to FS. I'm not sure how you got onto "offsets", which are more typically for application programs and programmers. Doesn't GF's config program deal with control assignments? If not can you not assign stuff via FSUIPC's button assignments? Regards Pete

I'm not surprised, as those are NOT offsets, but controls. They are assignable as controls in FS itself or in any of the Buttons and Keys drop downs in FSUIPC. What on Earth made you think they were offsets? That looks like a section from the list of CONTROLS not the Offsets documentation! Why? FSUIPC offsets have never actually been extended beyond FFFF. Where are you thinking there are extra offsets beyond? Please do use the documentation provided. The offsets lists are provided in the Offsets document. The list of control isa list of controls! Exactly as it says! Pete

Looking at the code it seems the limit of 25% is imposed on the separate reverser axes, and always has been, for all the years the facility has been provided. It is easy to fix, but it will only be in an interim incremental release for now as I am away on holiday from next Thursday and won't have time to put together a full release till October. Look out for revise interim releases with this fixed in the FSX and Other Downloads Announcements above. I should be able to get them sorted within the next few days, maybe even later today. Regards Pete

I don't know that product, but surely the autopilot shouldn't need offsets and parameters. Don't the standard FS controls work with that aircraft? Num7 is normally used for elevator trim nose down. Is this "HDG key" the heading hold button? Well, for an offset setting you'd use one of the Offsetcontrols -- they all start with the word "Offset", so they are all bunched together in the assignment drop-down list. But then you'd need to now whether to write a Byte, Word, Dword, Float or Double, and whether it's a normal "set", to write a value, or a "setbits" or "togglebits" for individual bits rather than a specific value. Once you've selected the right control, you will see that you can enter the offset (x50C0 in this case it seems), then the value to be written as a parameter. Those fields appear on screen when you select the control. How strange. I just checked, and offsets 50C0 to 50FF are assigned to Oleksiy Frolov for a Dash8+EPIC project. I had no way to relate that to this "Majestic" name. But now it makes a little more sense. However, I've no way of interpreting what is meant by "APHDG AUTOPILOT HDG 201 1 12865". Aren't there any column headings for that table you extracted a line from? The number 12865 appears to be the decimal equivalent of hex 0x3241, which makes no more sense to me than 12865 except that it could be interpreted as "A2" in character format. Perhaps you should be asking the person who would know, the one who designed the aircraft and wrote that document? Isn't there some support address for it? If you want me to help I'll need rather more information, maybe a bigger extract from the document you are quoting from? Regards Pete

Hmm. So, it is still a puzzle as to why the unconnected non-existent Z axis from the CH unit was interfering with the new R axis. Pete

Processor activity, maybe not memory demands. Well, I don't know what is causing that (though FSX reinstalls seem to cause more problems than anything, unless you also reinstall Windows), but SP2 was and is a significant improvement to many many parts of FSX and most certainly streamlines SimConnect-using applications, especially FSUIPC, TrackIR and other local-to-FSX applications. I have no idea why you had problems with SP2, but I really do think you need to sort them. It isn't any use having the SP2 SimConnect installed in Windows when the core SimConnect support, which is in FSX, is still SP1 or before. The problem of TCP/IP usage in SP1 and before concerns the communication between the SimConnect.DLL (the one in the Windows Side-by-Side folders) and FSX proper. If FSX proper is still at SP1 level it forces SimConnect connections to be at the same level. You can only use SP2's SimConnect if you update FSX to SP2. That's where the SimConnect code really is. The DLL's installed by the SDK are simply interface routines for applications. Regards Pete

Well, the only "not start" condition I know which can be caused by FSUIPC is when FSUIPC finds it doesn't know the version of FS it is in and then it does actually provides a message telling you it is the wrong version. And for that to happen the version of FSUIPC installed has to pre-date the version of FS -- presumably in this case 9.1. That makes that FSUIPC at least 4 years out of date. Any other reasons for "not starting" are certainly nothing to do with FSUIPC, but may be due to the bad behaviour of some add-ons. There is absolutely no way I can support other add-ons, and especially not bad ones! Exactly, so that's where you should have gone in the first place. That simply cannot be true. FS must always work without FSUIPC, otherwise Microsoft would have withdrawn it long ago. You DO NOT NEED FSUIPC to have a WORKING version of FS. You never, ever have! It is NOT an essential part, but an additional facility. What you simply cannot expect is to install any old piece of software into the FS9 modules folder and expect FS to work -- it doesn't matter if it is an ancient version of FSUIPC or any other DLL you might pull from a hat. If it gets loaded into FS and messes it up, it won't run properly. At least FSUIPC does tell you exactly what the problem is. If you didn't want to update it to a supported version, less old than 4 years of so, you only needed to delete it! Pete

Hmm. Strange. You should be able to. I experiment here, see what I can find. Maybe I have a bug. No, neither. It should calibrate the -4096 position it shows on the screen to actually provide the maximum reverse thrust allowed for the aircraft. If it isn't it is an error. i will check. Regards Pete

Sorry, you misunderstood or I didn't explain too well. I didn't expect it to see CH pedals as they are not connected. I wanted to know what values they reported for the Z axis. If neither of them even show a Z axis then I really don't understand how it could possibly interfere with the R axis! Regards Pete

No, but you've added more activity. If your system was near the edge already that might just have been enough. now I'm not saying there SHOULD be OOM failures. That really indicates a severely fragmented memory rather than actual shortage of memory, so it can occur at 94% if FS needs a contiguous block of a few megabytes and can't get it. The trouble really is that nothing is doing regular de-fragging of the memory allocations. You can install programs which take care of this, but then you tend to be adding stutters to the simulation as those programs do their stuff. Most times I've read about someone getting OOM problems with FS the answer was to reduce some display settings or reduce other activities somehow. In FS2004 there was also the memory leakage problems most often apparently caused by combinations of scenery (landclass) files incorrectly placed. Well, I don't know any more -- only that the TCP/IP traffic uses memory same as everything else, so adding more regular traffic increases the load on the memory and so also the fragmentation. Yes, so it is going to be lack of continuous real memory when FS requests it. Possibly. I really don't know if that makes a difference to memory usage. t might be worthwhile searching in the FSX forum here fr reports and solutions to memory issues with FSX. I seem to remember seeing several there. The main thing I just noticed, though, is that you said you are using FSX with only SP1. Why haven't you added SP2? It does make SimConnect much much more efficient and in fact avoids TCP/IP altogether for all local SimConnect interactions (such as that with FSUIPC, TrackIR and local add-ons). SP2 is really an essential fix for FSX, so I think that should be your first step. Regards Pete

Yes, I understood all that from the earlier post. But I don't understand how the assignment of a non-existent axis, Z was preventing the existing one, R, being seen. FSUIPC allows multiple assignments to the same control, and arbitrates between them for maximum deflection. I can only assume that the non-existent axis was somehow providing a fully-deflected value somehow, which is rather odd. Even if it did, as soon as the new assignment exceeded it it would take over assuming the other (the non-existent one) wasn't giving continually changing values. Maybe, because the axes are all on the same device (0), and all are read together, the Saitek driver provides some impossible-to-reach value for those axes not supported for that device. If you have time I'd like to see what the values being returned actually are. Maybe one of the attached programs will show it (DiView is using DirectInput like FSUIPC4, Joyview is using the older Windows "joy" interface, like FSUIPC3)? If I can distinguish between a "not connected" value and a true value maybe I can improve FSUIPC to avoid these problems automatically. Regards Pete joyview.zip DIView.zip

Thank you, but I'm not clear as to what was wrong nor why? Was Z not an active axis? What was Z before? Are you saying the rudder was previously Z (from the CH driver) and now R (from the Saitek driver)? And that somehow the Z assignment was interfering, giving a reading? Since FSUIPC only acts on CHANGES to axis inputs, then if Z was interfering by changing you should have been seeing it turn up in the axis assignments and therefore be able to simply unassign it. If it wasn't changing and so not showing up, I don't see how it could interfere? Regards Pete

Neither FSUIPC nor WideFS use much RAM at all, and certainly don't use anything progressively. Sorry, but none of that will be of any use, as there will be nothing indicating RAM problems as none of my stuff is a big or Continuous RAM user. You need to track down what might be causing a leak. It is almost always associated with graphics, things like scenery, textures, terrain, landclass, but with Network use it could also occur when the TCP/IP subsystem runs out of buffers space. If your normal RAM usage is 94% then any extra complication such as adding or enabling the things you mention could cause the problem. Do you have adequate paging file space? Try running without ActiveSky, as it may be related to the large numbers of TCP/IP buffers being used. Is the geographic area one with quite a few WX stations around? Regards Pete

FSUIPC cannot be responsible for any of that. Evidently something installed an old and incompatible version, that's all. To deal with that simply delete the FSUIPC.DLL from the Modules folder or replace it with a later version. There's nothing complicated about FSUIPC installation. It is either there, or it isn't. When it isn't it cannot possibly do anything at all. Purchasing? Why purchasing? I know of no problem whatsoever that necessitates any purchase! I think you are severely misunderstanding things. I have no idea what CaptainSim F104 is. If you want support of such products you must ask those that make or support it. I cannot possible answer for them or what they do. There is no way any program of mine EVER causes any loss of anything. They are all simple modules which are either installed or not. When you delete FSUIPC.DLL it is gone, has no effect, same as never existing! Pete