Pete Dowson

What is "RFP"? It isn't my program, but one which used to be supplied by Thrustmaster to check their joysticks. Also, its display might say "none" or similar in all 16 entries, but when you open them you find those which contain responsive values -- I think the old Windows "joy" interface isn't supported in recent USB-oriented drivers with proper names for those "folder" entries to show anything. Since I've really no idea what this "RFP" is, nor why it uses FSUIPC --I have no record of any product so named having been given access rights (is it freeware?) -- I can't really comment. In any case your best bet would be to find out from the RFP supplier/support/author. It does sound like that product has some bug in it. It may be completely unrelated to FSUIPC, just that it doesn't run to the buggy part unless it sees FSUIPC is present. Regards Pete

Okay, but I'd rather you use 4.272, now available in the Downloads announcement. The fixes other things, probably totally unrelated. Pete

Could you resume this thread here, rather than in PMs please? And please also try http://fsuipc.simflight.com/beta/FSUIPC4271.zip just in case there's a difference. Regards Pete

Which one? The 4.271 I provided a link to in this thread? AAARRGGHH! I just noticed, I provided the wrong link! Ouch. Sorry. Use this: http://fsuipc.simflight.com/beta/FSUIPC4271.zip And please, please, please, never ever just use the term "latest". It is absolutely meaningless. Please always give the version number. That's why I update those things, so I know what you are referring to! Pete

Where are you getting your mis-information from? Two things wrong there: First, 6D60 is not the offset to write to for a message. It is only where the multi-line window title is set (exactly as it says in the documentation!). You don't need one of those for a normal single line message, or even for a multi-line message is the default "FSUIPC Window" (or whatever) will do -- and in any case, only the first program to write to 6D60 gets its title there as the Window is only created once no matter how many times it is used. Check offsets 3380 and 32FA, which are the ones handling messages. Please do refer to the documentation supplied in the SDK before writing to random variables! Second, even if 6D60 was the correct offset, writing only 1 byte wouldn't get you very far! Why do you use a length of 1 for a message which is obviously longer than 1 character? Pete

I wonder if one of the add-ons you are running needs some Vista service you've disabled? If you've set up a separate profile with a load of system services disabled, maybe running a test with the default profile would eliminate this as a possibility. However: 3 or 4 hours of flight seems an inordinately long period of things being "okay" before a "freeze". It certainly sounds exactly like a memory type of problem. Something must be slowly (very slowly) building up towards it over such a time. Well, I'm really not at all knowledgeable regarding things than take 3 to 4 hours to go wrong. If you are sure real memory AND virtual memory (disk space on the swap disk) isn't running short (that's always been the problem with such symptoms before, not just FSX but all versions of FS), then I've very little else to offer in the way of suggestions. I assume the temperatures of everything are okay (processor, video card, motherboard?). I have just corrected a weird bug I found in FSUIPC4 which affected a few of the offsets -- rather technical ones, concerned with pressure ratios and the like. I can't see anything it fixed being a cause (I can't see anything I could possibly do taking 3 to 4 hours to result in a problem!), but it might be worth you changing just in case. I've not released it yet. Download it from this: http://fsuipc.simflight.com/beta/FSUIPC4271.zip The only other thing I can think of which might be instructive is to enable SimConnect logging. Please see the "FSX Help" announcement above for instructions on how to do this. The log file you get over a 3-54 hour period will be absolutely HUGE, so make sure you send it to someplace with enough space. When the freeze arrives, it would be worth checking the last entries there -- also to see if entries are still being added, as this would show if that part is still active. If you need to send me anything, ZIP it and send to petedowson@btconnect.com. Regards Pete

Please now try http://fsuipc.simflight.com/beta/FSUIPC4271.zip . I've fixed an entirely separate problem which I cannot see having any affect in this, but you never know. [NOTE]. Regards Pete

Thanks. Please also try http://fsuipc.simflight.com/beta/FSUIPC4271.zip . I've fixed an entirely separate problem which I cannot see having any affect in this, but you never know. [NOTE] Regards Pete

You can assign in FSUIPC and calibrate in FSUIPC without using the "direct to FSUIPC calibration" option in the assignments tab -- so far it is only that route which seems to be causing any grief. Though it isn't that alone -- something else is interacting with it. Many folks use the same method (i do, for one) and never have any crashes, so it is down to some odd combination of factors. As well as using other assignment/calibration methods you could try my latest update. I've fixed an entirely unrelated bug, but you never know. Download this: http://fsuipc.simflight.com/beta/FSUIPC4271.zip [NOTE]. Regards Pete

FSUIPC 3.60 is very much out of date and cannot be supported. Update to the currently supported version (3.80, or even 3.809 from the Announcements above) if you want any support. Regards Pete

Ah. Then how are you programming the PTT? It is unlikely to be the same locally and with WideFS! Please describe both. You don't want errors in the WideFS logs -- that certainly sounds like you have something up with your Network. If short enough, paste them here. WideServer too, please (both ends are always relevant). Otherwise send to petedowson@btconnect.com. But please do this pretty soon, I am on holiday after next week and at this rate it could take longer;-) Regards Pete

Good. If you want to extend your control over the PMDG overhead (or other mouse-only parts), the latest update, 3.809, above will let you do that. I finished the mouse macro facilities. I've been trying them on the PMDG 747X in FSX, with FSUIPC 4.269, and they work there too! See you in June! ;-) Pete

Right, so certainly not deliberately using the toe brakes! ;-) No CTD with the latest updates? That's different from duacar's reports. Hmm. Seems it must be down to some weird combination of events, because there's only two reports and I know for sure that a lot of folks calibrate toe brakes through FSUIPC4 -- myself included! If the brake axes aren't being used at the time it is hard to see how they become involved, unless some early problem, before takeoff, actually caused some delayed-action corruption. I've traced through all the code paths which are invoked with directly assigned toe brakes, and it is all innocuous stuff. So I remain completely puzzled I'm afraid. I really have no idea how to obtain more information to help -- normally it is obvious that something ought to be logged or traced, but this time, nothing. :-( I have found a typo in the code which affects a few FSUIPC offset read-outs. I can't see how any of them would have any bearing on this problem, but it may be worth me sending you and duacar another test version, just in case. Later ... Regards Pete

Damn. I thought it might be related to having too many successive brake events being sent to FSX. I cut that right down, but it seems not to be the answer. I cannot reproduce the problems here but maybe I just don't try for long enough. From what you say, though, it isn't crashing when you are USING the brakes at all, just flying? Or will the brakes be occasionally engaging whilst you are using the rudders? Are you avoiding toe brake action when using rudder? Do you have a good dead zone calibrated? No. That won't make any difference at all. FSUIPC's menthods of calibrating haven't changed in many years. I don't think that will be different in this regard from 4.266. I am really puzzled by this one. Regards Pete

I'm afraid this is going to need someone from the Squawkbox development or support area to look at. There's really nothing I could do -- I know nothing about that program at all and have never used it I'm afraid. Any crash in any program outside of FSUIPC or WideFS does really need sorting out by the responsible party. It may well be that it is getting incorrect data through WideFS or FSUIPC, but I wouldn't know what data it is looking for or why it would consider it incorrect -- and especially not why it would consider it so incorrect it would actually crash. That sounds like an error path not previously tested! Certainly I can help them obtain whatever extra data they may need, and they in turn might come back to me for clarification or a change in FSUIPC, though why that should occur now after so long these programs have been used seems rather odd. But my problem at this stage is that I have no idea what they might be stumbling over so I wouldn't know where to start looking. Regards Pete

But the important thing to note is that the problems appear to be not with the calibration of the brakes, only with the assignment of the axes in FSUIPC4 "direct to" calibration. This is my question. Are you saying that is what you did, or not? Without knowing that your report is not useful I'm afraid. But version 4.26 does not have the changes I made to, hopefully, fix the problem. It is not the "latest" version -- that is 4.266 in the FSX Downloads Announcements above. There have been 6 increments since 4.26. This is why I stated that your work "latest" doesn't mean anything useful! I will be uploading 4.269 later today, but that just has new facilities in it rather than any brakes or other such changes. It may pay you to scan the Announcements from time to time. I do put a Date in the title so that you can tell when something new has occurred. Regards Pete

I just remove and delete any reference to the Brakes in FSPUIC So your report is of no help? You don't remember how you assigned and calibrated them, nor if the latest interim update fixes it? What does that mean? Folks often say that without even knowing what the latest version is! Only version numbers mean anything. And what was the last version number in which you had the brakes calibrated, or assigned, or whatever? Without information there is no point in these reports I'm afraid. Sorry. Regards Pete

Direct assignment in FSUIPC too? Otherwise yours was different. Anyway, I need to know if the most recent versions (interim update in FSX downloads announcement above) fix that. Pete

Yes, but the PCs you use to run the PM parts, using WideClient, will not have FSX running, so they will not be using WidevieW. The only place where both WidevieW and WideFS are together is inside FS, and they cooperate quite happily. Regards Pete

In that case it would probably have to wait until mid-June. I've got some holidays coming in May. Right. I did my flying lessons at Sleap, which I presume you will know too, then? Unfortunately, I never got a medical certificate because of my Retinitis Pigmentosa (tunnel vision) which I didn't even realise I suffered from till then. Biggest disappointment of my life, not being able to get my PPL. Well, not necessarily. Theory-wise I'm quite good, but I tend to be programming and/or testing rather than flying, so most of my "flights" are simply test runs where I'm looking out for specifics in something I've been working on. It's handy too, for me, having a pilot concentrating on flying the airplane properly! ;-) I have a PFC 737NG cockpit (see http://www.flypfc.com), but a little out of date at present -- awaiting some more MIP instrumentation and their still-in-development fully equipped overhead (mine has most of the necessary switches but no indicator lights or gauges). And my elevator trim pot has gone really wonky -- I have a spare part for it but I'm not able to fit it myself so I'm waiting for the other enhancements so that the PFC engineer, Eric, can fix it all together in one worthwhile visit. But it can be fun, nevertheless! ;-) Write to me in June, after the 7th: petedowson@btconnect.com. Best Regards Pete

If FSX is freezing, naturally FSUIPC freezes with it, so any program talking to it gets no response too. That's unavoidable. If doesn't mean FSUIPC is the cause, although most folks naturally always like to blame FSUIPC first. In FSX it is very very unlikely to be FSUIPC itself, as it is merely a standard user of the Microsoft-supplied SimConnect interface. In previos versions of FS FSUIPC's job was a lot more precarious because of all the hacking it had to do to provide the facilities. In FSX the "hacking" has been done by Microsoft instead. FSUIPC isn't really much of a Vista or Windows user -- it is FSX which is using the operating system a lot. And SimConnect is very very dependent upon the system for its communications with FSX. Do you have SP2 or Acceleration installed? If not I would strongly recommend that you update. If you haven't installed even FSX SP1 yet, then do that first. Then SP2. Or just buy Accelertation which will install both in any case. Before SP2/Acceleration, SimConnect used TCP/IP for all of its interaction between itsself and FSX. If you are short on real memory, or have any sort of security programs running (anti-virus, firewalls, etc), then the TCP/IP system can get slowed down to the point where FSX stops or crashes. Do you have any direct SimConnect-using add-ons running too? Some security programs are worse than others. AVG seems okay for anti-virus, and Windows XP/ Vistas's own firewall seems okay, but some of the commercial security programs seem to be a real nightmare for FSX. If you move to SP2/Acceleration, FSUIPC uses the later version of SimConnect and this doesn't use TCP/IP, so it bypasses all the security interference. Next time you ask for advice, it would be useful if you you find and paste up the Log files from the FSX/Modules folder -- there's an Install log and a regular FSUIPC4.Log. Please close FSX first. Regards Pete

You have a condition on the control for Panel 7, but not for Panel 3! You simply need the opposite condition on that: 5=CP(-1,8)0,2,C65908; Throttle Quad Button 2 (FSX-03) for Panel 3 See? "+" for "pressed", "-" for "not pressed". Pete

Thanks for the files. Your KEY file works fine here, and it all checks out, so I believe the problem is related to the FS hang you get. I notice in the KEY file you have these additional DLLs running: PMDGOptions.DLL=... fsint.dll=... ActiGate.dll=... Now I know PMDGOptions is okay, but I don't know "fsint", and I do know that some (early) versions of ActiGate caused problems. Do you think you could try with either or both of these removed from the Modules folder, please, and let me know? Try the registration without them, for instance. If ActiGate is the problem, it was fixed that I know, so maybe you need to find a later version. Regards Pete

Yes, good luck! Pete

Just make sure the top of the idle (centre) zone is a little above the very minimum readout from the lever, and the lower idle /centre zone and minimum value (max reverse) are the same, the lowest possible value you can achieve. When those two are identical there is no reverse zone, but you do need a small idle zone, not an empty one. Regards Pete