Pete Dowson

Hmm. Sounds like Enrico's version is ignoring the relevant SYSVAR variable settings. That's a bit sad. Easy enough to fix, though, if you don't want those subsystems handled. You just need to add logic to copy the pmSystems SYSVAR offset changes back to the FS offsets. I would have thought he would do that by default for variables he is not handling. I may need to tackle him about that after Christmas, but it is not a good time now. Sorry. Meanwhile I'll add the option to bypass pmSystems altogether, as I said. If you don't have a pair of sixpack annunciators it wouldn't have made any difference in any case. If you did have, the added PFC treatment is simply a superset of Enrico's defaults, but the extras would depend upon parts of the pmSystems logic which are only in Thomas's files in any case. Regards Pete

Well, before you fire up FS again, please check in the announcements above. Look for FSUIPC 3.714 or later. I am now adding more persistent logging in the case of a signature problem, and if there are any errors they will appear in your normal FSUIPC Log file, without the need for DebugView. Don't bother before tomorrow though -- take the rest of the day off and fuss the wife! ;-). Just don't use 3.71 next time. Let me know when you have a result, and show me the Log then, please. Regards Pete

Well, I think i said you need to check them, not actually delete them and start again! ;-). And I think I was clear that only applied to the recent change to AXIS assignments, which doesn't come into Button assignments -- they certainly haven't changed. If you still have your old INI file accessible, try cutting and pasting your old [buttons] section from the old INI file into the new one. Regards Pete

That certainly sounds like you are assigning them in FS and have the sensitivity less than 100% and/or the null zone set off zero.

Meanwhile I found the problem. The number of flaps used in the detente setting part was not beinig initialised in the SimConnect data read section, even though the displayed number of flaps was1 The maximum number of flaps was therefore set wrong. Duh! It'll be fixed in FSUIPC 4.065, probably late tonight or more likely tomorrow. Regards Pete

Something else is wrong then. Well, it it the Client which connects TO the Server, so perhaps this shows the blockage is on the Desktop. something is getting in the way, for sure. FSX didn't run at all? I'm wondering if something in your Network Settings on the desktop are wrong. maybe uninstalling and re-installing your Network card & drivers would sort something out? Yes, please tell me what happens. I'd like to know what the problem turns out to be! Regards Pete

Okay. Thanks. I can reproduce the problem and I am trying to figure it out now. It's odd -- the small routine which operates the flap detente section is identical in both FSUIPC3 and FSUIPC4, yet it works in the first and not in the second. I'm tracing through it now. Please look out for another update today or tomorrow, hopefully! Sorry for the inconvenience! Regards Pete

Since FSUIPC 3.71 you don't need to register applications. ;-) Haven't you actually tried to use your add-in product at all? It will work with no further ado! Yes, sorry, I forgot to replace the picture in the documentation in that release. I did actually remove the entire section dealing with Application Registration, but forgot about the picure. The document will be fixed in 3.72. Ernot from FSUIPC 3.71, because there's no such checking or error message produced now. What is the message? Regards Pete

Two things. First, as Jim says, check the sliders in FSX if you are assigning them there. If you are assigning them in FSUIPC's "Axis Assignments" though, there are two input types there - RAW and calibrated. The calibrated will show the numeric results of what you did in Game Controllers, whilst 'RAW' bypasses that and shows the actual controller input. Generally it is best to rely on the Game Controllers calibration. Second, since FSUIPC has no graphic indications, since it calibrates by numbers, how are you actually "seeing" that it only uses 1/4 of the travel? Are the numbers simply not changing at all elsewhere? The input numbers themselves don't matter -- calibration maps whatever range you get to the full range FS needs in any case. The devices that give you large numbers are not necessarily giving that sort of resolution. Most pot-based axes will be good if they give as many as 100 different readings, let alone the 32000 they appear to boast, and I don't think there are many optical ones which give more. Most inputs I've dealt with seem to have about 30-50 positions which are detectable, and much less for reliable detection. Regards Pete

Thanks. I wasn't aware of that one, and will be interested to hear of your findings! Regards Pete

You wouldn't normally show the throttles on screen, would you? What matters are the engine gauge readouts. Adjust the levers to get the thrust you want. Unequal positions on levers are either due to different calibrations, or differences in the "linearality" of the potentiometers used in the device. If they are optical they should line up pretty well with equal calibration. If it presents a problem there is a "throttle sync" facility you can use, but it isn't totally unrealistic to have the levers at slightly different positions for the same thrust values on real aircraft. Hmm. Strange that it would vary between aircraft, unless you have aircraft-specific calibrations set. Regards Pete

Is there a Simconnect.dll file in that folder referred to in the FSX Help Announcement? Search for a file "simconnect.xml" in the Documents and Settings folder. If you find one, delete it. Otherwise, I'm sorry, I have no idea. We have exhausted all the things I can think of. Regards Pete

3.712 is the "Release Candidate" for 3.72. I release interim versions in order to resolve any problems before making a general issue and withdrawing support from the older one. If it were not for this problem I would be releasing 3.72 soon after Christmas. I don't know whether it is some difference between SP1 and SP2 or something else, and I cannot find out without some help from someone who is experiencing the problem. so far there's only you. When do you think you may have more time to try things, please? Regards Pete

Hmm. I'm afraid all the logs show is that the communication between the two PCs is being blocked by something. I don't know if this is some firewall settings on one or the other, and I cannot really solve Network problems remotely. I think you need to sort out your firewalls and get the Network fully operational, then try again. Regards Pete

FSX uses "CFG" files, not INI files, and I'm not aware of an adjustment you can make for trim rate. I don't understand, if you are complaining about what is purely an FSX function, why you mentioned, in your first message, "... with the new fsuipc version", as the problem you have is not in any way related to FSUIPC. I know everyone blames FSUIPC for many things, but this is rather extreme when it is patently irrelevant. ;-) You can certainly do cleverer things to give you faster or slower trim rates by programming buttons in FSUIPC. In fact this is actually shown as an example of the FSUIPC Offset increment/decrement controls in the FSUIPC User Guide (in the box on Page 24 in the FSX version). Regards Pete

A "corruption"? I thought I explained all this. Did you not understand anything in my last reply? The difference between the two versions you are using is that I've added "pmSystems awareness" to the PFC driver, so that, if pmSystems is running, the switches that pmSystems controls are routed through pmSystems instead of going direct to FS. This is the whole purpose of pmSystems -- to handle the subsystems of an aircraft. It can only do that properly if the switches it needs to control are routed through it. I have no idea what you mean by "corruption", but it sounds like your pmSystems logfic is not using the SYSVARs for the purpose they are assigned in the SYSVAR.TXT. Possibly you have made your own specific pmSystems system? That's is why I asked, and also listed the SysVar offsets I am affecting. And what logic file? The standard 737 one supplied by Enrico or the system enriched one supplied by Thomas Richter? Maybe there's some differences which adversely affect the systems. I must admit that I've been using Thomas's excellent 737 logic files for the last 18 months or so. However, I thought these weren't too far removed from Enrico's, especially in basic things like lights, starters and brakes. Hmm.. I wonder how that is arranged? Naturally, for pmSystems, the NAV light switch operates the NAV light bit in pmSystems. If your pmSystems logic does not handle the lights at all, that may explain that. Or possibly it is just that, before the lights would work without the Battery switch in pmSystems being on, and the relevant electrical subsystem energised? Possibly it is because the correct overhead procedures are needed that the confusion is arising? Er. I think you profoundly misunderstand something here. SYSVAR.TXT doesn't actually DO anything. It simply defines which offsets and which bits are used for which functions. It is the logic files for the particular aircraft which defines what happens as a result. I am not sure why you insist on repeating yourself so many times. I heard you the first time and actually did give a detailed response in my earlier reply. I know that too and I did explain why. You do not seem to understand much if any of what I have said! :-( :-( Look, if you want to stick with what PFC.DLL used to do and not make the subsystems work correctly with the PFC switches, I'll add an option into PFC and PFCFSX to totally ignore pmSystems and have nothing whatsoever to do with it, just like version 1.90 did. I honestly don't think that is the right way forward, as the whole point of pmSystems is to force correct procedures in relation to the assorted subsystems, but I cannot see any other way if you do not understand this. By having PFC do its thing always directly to FS, pmSystems cannot influence those aspects of aircraft operation as it is being by-passed. Look for an update within the next few days. You may need to change an option to make the driver ignore pmSystems. Pete

Looks like it is being blocked. Where's the Client Log? There are always two ends to a connection. Regards Pete

Don't know. Could you show me the joystick Calibrations section for this, from the FSUIPC4.INI file please. Have you used the facility before with FSUIPC3 at all? Pete

Ersomething wasn't installed then. Please check the FSUIPC.LOG, see if you really did have 3.713 installed. Perhaps it needs "Debug=Please" added to the [General] section of the FSUIPC.INI file. It shouldn't but that should certainly make it display the normal log entries "live" at least. The problem is that I don't know why it is happening. The debug log should have showed me. Can't you tell me at all why you are stuck on WinXP SP1? As well as SP2 there have been hundreds of updates and fixes for WinXP. I'm concerned that it is a WinXP problem. Regards Pete

Er, You need to explain what you are doing! The trim controls are processed by FS, not by FSUIPC. If you've assigned them in FSUIPC they are simply passed on to FS, and operate identically to assigning them in FS (or leaving them assigned in FS). Why are you assihning them in FSUIPC in any case, they are standard FS controls assigned in FS. Please explain what you are doing and perhaps I may be able to help. Pete

What do you mean "flaps 1 position AGAIN"? The calibration for Flaps position 1 must be greater than flaps position 0 and less than the maximum. You cannot move to flaps 2 till flaps 1 is set -- and by the sound of it ("AGAIN") you couldn't have done that? The flaps are numbered 0 = full up, then 1 to N full down. Pete

I'm sending FSUIPC 3.713 which is sepcial in that it contains extra logging. Please check the Email, as you'll need to get an extra program to capture the logging. BTW, why ARE you still on WinXP SP1? I don't think that should be a problem, but I've now tried 3.712 on all my systems and it is okay on all -- but then they are all SP2 + later updates. Regards Pete

Could you check whether you have a "WinTrust.dll" installed in Windows please? Do a search on your Windows folder. If it is there, could you right-click it and check the version number. I found many websites where you can download and install WinTrust.dll, so it may just be that it wasn't an original part of WinXP. See here, for instance: http://www.dll-files.com/dllindex/dll-fl?wintrust If that DLL isn't installed, or possibly if it isn't supporting the interface I'm using, it would explain your reported problems. I cannot tell here as all my PCs are fully updated to the latest versions of everything in WinXP. Regards Pete

Well i have that line it it, [simConnect] level=Verbose console=No file=C:\SimConnect%01u.Log file_max_index=9 No, that line isn't in it (you are confusing "max" and "next", which are different words). It is put there when Simconnect creates the first log, then updated each time. It looks like either you have the Simconnect.INI file in the wrong place (it goes into your My Documents\Flight simulator X Files folder), or simconnect simply is not running at all. Okay. Let me know if you make any progress please. Regards Pete

Hmmm. That's should be okay, unless there's some difference in the signing system between SP! and SP2. Any reason you are sticking to the older XP release? No, the problem you are getting is what would happen if FSUIPC thinks the code has been tampered with. If it has, then the signature should say it's invalid too, so it obviously hasn't. The code I use to check the signature inside FSUIPC is, as far as I'm aware, identical to the way Windows checks it -- that's why I asked you to look for the Signature details. Of course not -- the change to use signatures instead of my old sumcheck/CRC checking system is new in 3.712. Now that I have paid for an (expensive) software publishing certificate I am using it for all new releases. With the number of false virus alarms being attributed to my compressed and zipped modules these days, I feel it is beneficial in any case to give users the assurance of a proper signed certificate. When Vista comes along it will be a necessity in any case otherwise you will get security warnings. I am stumped at present as to why the certificate checking inside FSUIPC isn't working on your system. Until I get some more reports I'm not sure I can do anything, though I'll have a look at the code and maybe add some diagnostic logging to see where it is going awry. Perhaps, if I email you a test version (probably 3.713) you could try it and return the Log? Regards, Pete