Pete Dowson

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

PFC drives the 6 pack indicators in the same way as pmSystems 737 Logic, via offset 5530. These only affect the sixpacks, Fire and Master Caution indicators. The whole point of the change for 2.01 to 2.02 was to make the bit assignments compatible with the current assignments in PMS's SysVar.txt. The PMSystems functions in the PFC driver are pretty much restricted to those things handled by pmSystems logic when it is running. They've been driven in PFC.DLL now for nearly two years. This isn't a recent thing. These include: Offset 5530 for six pack, fire and master caution Offset 560F for APU Offsets 5642 and 5643 for lighting Offset 5645 for Strobe Offset 5610-13 for the starters Offset 5664 for pitot heat Offset 5657 for wing and engine de-icing Offset 5628 for the master battery Offset 561A for fuel cutoff/idle Offset 579B for the Parking Brake As above you mean? When I do a bit more work the Autobrake will go through pmSystems too, but I've not done that yet. It sounds very much like you are using PMSystems logic which isn't doing what it should. Can you tell me what you are using? If you have a custom written logic for your setup then we can sort out some small changes to make it work. What aircraft are you simulating? Backlighting? How does PMSystems relate to backlighting? Sorry, you will need to be more specific. Do you know how any of your kit works, or are you simply using stuff programmed by someone else? If you know, please get down to the detail of what offsets do what. I've put a lot of work in over the past two years to make the PFC stuff work properly with pmSystems, and I'm pretty sure all the offsets are used correctly. Can you please look to see why your pmSystems isn't using the standard SYSVAR.TXT defined values? Regards Pete

No, WideFS links computers NOT running FS to one (the Server) that is. WideClient won't run on a computer already running FS, because it provides an interface which looks identical to FS+FSUIPC. WideClient *can* be made to run on an FS PC, by changing a class name parameter so it doesn't clash, but then programs like Radar Contact wouldn't be able to connect to it because they'd be looking for an FSUIPC interface with the FS class name. Regards Pete

"Nothing" happened? You mean FSX didn't load, or just that Simconnect still didn't load anything? When you say "didn't work" do you mean the Installer didn't work? If so, where's the Install log, please? So there's no "file_next_index= ..." parameter added to your Simconnect.INI file? That's where it keeps track of the Log file numbering. Sorry, I'm all out of ideas. Most certainly Simconnect, that vital part of FSX without which add-ons won't work, is not running on your system. Why, I have no idea. Yours is the first case I've come across where a re-install using methods given doesn't succeed. I'm afraid you now only have recourse to Microsoft Support. Please send all these results to tell_fs@microsoft.com in any case, explaining all you have explained to me. But don't expect a reply from that direction. For actual tech support on FSX you will need to contact MS support. Regards Pete

That's what I thought you might mean, and that isn't the latest, only the latest on general release. Please re-read this part of my earlier reply: If re-installing Simconnect doesn't work, maybe fixing those files, by using the latest FSUIPC4 installer, will do the trick. Pete

Latest version of what? If you mean FSUIPC, can you check the Version number please? "Latest version" means nothing on its own, it just means "the latest I have downloaded". So, SimConnect isn't loading anytrhing at all. Ah! That apparently doesn't work! Please refer to the FSX Help Announcement above. You have to delete a folder first, else the repair won't touch SimConnect. That's why I posted the FSX Help Announcement in the first place, and why I referred you to it! Regards Pete

Thanks for the KEY file. I've tried that here and cannot make it fail at all. I'm really puzzled about this. The only thing I can think of is that the signature checking mechansim isn't working correctly on your system for some reason. Can you tell me what version of Windows you are using please? Can you also right click on the DLL, select Properties, and see if there's a "Digital Signatures" tab? If there is click it. It should show the DLL as being signed by me, Peter L. Dowson and have a Timestamp shown there of 14 December 2006 13:24:55 (you may need to change some field widths to see the time -- or just click "Details" and read it there). Note that if you are using WinMe or earlier this may explain it. I'm not sure that these facilities were implemented back then. Hence the IMPORTANT note in the Announcement. Regards Pete