Pete Dowson

Ah, right. Thanks. At present, then, 61B0 and 61B8 aren't really of any use. I'll not included them (yet). Same for 6178, 6180, 6188 and 6008. Rightthis may be important for some internal functions for the GPS/planner, but probably not for an external program. I'll leave them out of the dox for now. Thank you very much! Regards, Pete

I'm still a bit confused. There is a "seconds since midnight" in 600C according to your first list. It looks like you are saying that 61B8 is the number of seconds since some arbitrary starting point, divided by 5, and 6190 and 61B0 are copies of this at specific described events. I'll see if I have time to cross-check these so I get the descriptions right before updating the docs. Thanks! Pete

Well, as I said in another thread, I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we do later find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically. Regards Pete

Your throttles are behaving well then. I never really could understand why some (like mine) give no measured jitter and others wobble all the time. I'm sure there cannot be such variations in manufactured quality. I bet it's down to environment -- dirt, humidity, temperature and quality of power supply. Well FSUIPC 3.47, released tomorrow, is just a little different from 3.469 -- a fix for FS98-style visibility setting in FS2004 (still used at least by Squawkbox 2.3), added controls to disconnect throttles in case we can't resolve the issue on the 767. Changes planned for PFC.DLL are mainly in answer to additional requests, like having throttle equalisation for three and four-engined aircraft. Regards, Pete

Good. One down one to go. I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically. Regards, Pete

No, there's no such 'skeleton' key for apps I'm afraid. They are all uniquely dependent upon the program concerned. There's no "developer's license" as such. So far all developers have purchased a user key, which gives them complete access for any programs being developed or used, as well as to all the facilities (and of course does help me justify the work I put into supporting developers and the SDK). When the development work is advanced far enough to justify its own access key for use on non-user-registered installations of FSUIPC, then I can provide one quickly enough, and it can be tested easily by simply temporarily removing your FSUIPC.KEY file from the FS Modules folder. The programming changes needed to incorporate a key are minimal -- in fact none at all if you simply place the key in the Version Information data. Regards, Pete

Why would you need FSUIPC to assign trim controls? They are standard FS assignable controls. Did you check the FS Options-Controls-Assignments list? They are assigned by default on the keyboard as: ELEV_TRIM_DN=36,8 (Home, or number pad 7 with NumLock off) ELEV_TRIM_UP=35,8 (End, or number pade 1 with NumLock off) These are lines from the FS2002.CFG file. The names here are the names you will see in the FSUIPC drop down list too. How did you miss them? FSUIPC only lists things by their 'official' names according to FS -- the names are those actually listed in their CONTROLS.DLL and included in the "List of FSxxxx Controls" documents available on http://www.schiratti.com/dowson. Also, they are the control names seen in the FS CFG file against the key presses and button assignments it makes. You've not calibrated them correctly then. Calibrate them properly in Windows game controllers first, and get them working in FS. Why are you using FSUIPC for this? Neither is likely. It seems to be a problem with them not being calibrated correctly. FSUIPC is merely a way of getting more accurate end points and centres, with response curves and filters. But you need to get things working properly BEFORE attempting to use FSUIPC. Start again from first principles. Use FSUIPC when everything is pretty good. Regards, Pete

I'll need to fix it before I make a general release, some time in April maybe. I'll have a quick look next week when I add a few other changes I've been promising. Even if I can't fix it then maybe I can add some diagnostics to try to track it down. Nothing there any different to what I'm running. Could you send me your PFC.INI file just in case it's some combination of options? petedowson@btconnect.com. Thanks, Pete

That's really more a job for an application program. FSUIPC is just passing information back and forth in the main. it really doesn't know what much of it is. Possibly. Sorry, I don't know. maybe someone else can help here. I'm a Project Magenta user so my waypoints are in the PM CDU, in any case. I don't think I've ever used the FS flight planner or its GPSs. Regards, Pete

Ah. It says FS2000-FS2004 on my copy. I'm gradually managing to update the text parts, but it is a slow job. Anyway, it's the columns on the right that are definitive for recent releases. Blank means "don't know yet". Are you sure that's as up to date as the Programmer's Guide in the FSUIPC SDK? That's the only one I maintain. http://www.schiratti.com/dowson. I cannot take responsibility for any one else's lists. Regards Pete

If this Flight Instructor program uses FS98 facilities to set the visibility, like Squawkbox 2.3 apparently does, then this is the same problem as reported in the thread "visibility issue on FSUIPC > 3.4.10", and will be fixed in the 3.47 release I will be making this weekend. It is very odd that something that went wrong five whole months (and an equal number of new releases) ago has had no reports until this week, and then two reports within days of each other. Weird! Regards, Pete

Which offsets are you talking about please? The values at 2EE0-2EF0 should be sufficient for your needs and work in FS2000-FS2004, as it says. Regards, Pete

Odd. That's not been changed. What about the throttles? I'm not sure how I can help at present. What operating system FS version, other things running, and so on? I really wouldn't know where to begin. I'll be trying to make another interim release next week, but then that's it till late April. Pete

I'm sorry, I have a little difficulty following you. The installation of an updated FSUIPC.DLL is by copying the FSUIPC.DLL into the FS Modules folder. That's it. That's all. Exactly as described in the user documentation. It sohludn't need to sound as complicated as you make it. I'm not sure what you are trying to do or say. Meanwhile, I am still waiting for you to tell me some more details please. All I know so far is that you try to start FS, but it immediately crashes with a blue screen. It seems that this blue screen has no information, or if it has you are not telling me about it? and you say that you see nothing of FS before this happens? In other words, it isn't starting the Network, it isn't running FSUIPC or loading an aircraft, nothing? I don't know what you have tried to do so far to help yourself, but I can only help if you explain what it is you do, and exactly wat it is you see. Not much has been described at all yet. Try only FSUIPC first, don't install WideServer.DLL. That may tell us whether to look for a Network problem or not. Try deleting (or removing to a safe place) the FS9.CFG file, so that FS2004 starts with defaults. Maybe there is a problem with the initialisation. Check what other things you have running. There are known problems with, for instance, one of the Kensington mouse drivers. There are undoubtedly other things which may cause problems. Check other add-in DLLs in the Modules folder, try removing those one at a time. If you have FSNav installed then make sure it is up to date. Early versions caused FS to crash or hang if FSUIPC was already installed. Let me know what you have tried and, always, EXACTLY what you see, with as much imformation as possible. I cannot possibly interpret anything you've said so far. One of the things you said several messages ago was very strange. Maybe you can explain that too. Here: There is no way I know of having anything "too fast". IPX/SPX is rather more efficient than TCP/IP and therefore places less loading on your PCs, allowing more time for other things, but too fast? It cannot possibly be that which was making your system unstable. Maybe, by not actually identifying and fixing whatever was wrong then you have discovered it again now. Anyway, first find out if the change in WideServer or the change in FSUIPC makes the difference, and proceed from there. Since your versions 3.30 and 6.23 are so very old now (there have been many updates since then!), there's really no possibility of identifying a specific cause of your problem without a lot of checking and testing. Regards, Pete

As far as my tests go, that works for all versions FS2000-FS2004, as it says in the Programmer's Guide. Regards, Pete

The critical part is: You tell me how I can detect that, and the throttle disconnection is easy. Check that monitored locations for me first. Then I'm stuck. If the modes are entirely contained in the aircraft's own code then the only thing I can think of is to have another programmable button to specifically disconnect or reconnect the throttles. Regards, Pete

I fear it will be much more complex than that. The current stuff in PFC.DLL for 767PIC is a real mish mash, trying to cope with the original (pre 1.3) version and the later update simultaneously. If the Level D team is more or less the same as the 767PIC team then really I don't want anything to do with them. When I was trying to develop the facilities I did do, for their very first version of 767PIC, I was trying to interact with them on behalf of PFC to get adequate controls included. They were very rude to me and basically told me to get *******. I really want nothing whatsoever to do with them, they are not the sort of people I can deal with I'm afraid. Later (in their version 1.3 update) they did produce almost the interface I had suggested to them, and published it privately, I think, to Aerosoft (Oz) for their MCP driver. I got no help or information and had a lot of difficult work to do just to provide the rather crude support that exists in PFC.DLL today. Maybe that was all about money. I don't know. Either way, I really would rather not go through any of that again. Sorry. Even if I was eager to do something, it would not be possible till late April at the earliest. Regards, Pete

It would need AIbridge if you are using Squawkbox 2.3. I think the function of AIbridge is being incorporated into SB 3, and it is already in the IVAO programming I think. Regards Pete

The normal way is to park the throttles at max or min. If you've calibrated with reliable dead zones both ends this will prevent any inputs from them. I usually leave them at max on climb, then bring them back to idle before descent. You really should not be getting so much jitter in the hardware. PFC.DLL is only obeying the signals it is receiving. There are some filters available in the PFC DLL which you can enable and maybe adjust to help. Check "Apply digital filtering" in the Main options page, and take a look at the "AxisSmoothTime" parameter, described near the end of the documentation. Are you enabling the A/T via PFC controls too? Or, alternatively, does this aircraft's auto-throttle operate the FS default auto-throttle switch? If either of these are true I could provide an option to disconnect the PFC throttles when A/T is enabled and re-connect them afterwards. If I cannot even detect when the A/T is enabled then I wouldn't be able to do anything automatically. I could instead maybe provide an FSUIPC-programmable button to disconnect them. Please monitor these locations (FSUIPC's Logging page, right-hand side): 310A type U8 07DC type U32 07E4 type U32 0810 type U32 If you check the "AdvDisplay" option, below, the 4 values will show in real time on the FS screen. Let me know what happens when you engage autothrottle and disengage it. Try both Airspeed and Mach hold. Regards, Pete

If FS's own weather is not providing upper winds, even with the option to do so enabled, then I think it really cannot be to do with the FSUIPC interface. I assume you've checked the FSUIPC Wind options to make sure you are not imposing some limits or taxi-wind or something -- although they would affect surface winds. Sounds like something is bad with the FS9 install. I really cannot think of anything which would have such an odd effect. Sorry. Regards, Pete

Sorry, no. I've no idea. If Lee has re-written his gauges to use the MS provisions then that's great, but I can't re-program any gauges for you myself. If you want Eric to do the same you'd have to ask him, not me. Regards, Pete

The PM offsets are being used by ALL of its modules, no matter where they are. Hardly anyone has them all running on the FS PC. They are all designed to be run on Clients! That's how they communicate, via FSUIPC, and that's how they obey instructions. You seem to have missed the whole point of WideFS -- it is precisely the because of the sharing of the offset data amongst all Clients that it is being used. What else did you think it was for? The KeySend stuff are just part of some additional frills for programs not using FSUIPC offsets for control! Regards, Pete

Yes. In some of the facilities I do insist on a refresh every so many seconds, else there's automatic clearance, but this is a bit awkward with so many possible entries all with probably different last-written times. It's never really posed a problem. After all, if several applications want the same keystroke, they will all get it, as it says, so the only possible harm done is if the table became full. Not happened yet (touches wood, crosses fingers! :wink: ). Generally if things around FS crash untidily it is often a good idea to restart FS too. There may be other things not quite right else. I can't watch everything! :) Regards, Pete

AIBridge is not my program, it is by Jose Oliveira. I assume the TrafficInfo.dll is the Microsoft FS DLL? I'm afraid I don't know anything about that. Sorry, that's a bit ambiguous. What TCAS gets the info from where? I'm not following you at all. I think Eric's gauge uses the TCAS data in FSUIPC, which is where AIBridge puts the MP aircraft data. I have no idea at all what you mean by "avoid having to connect to the host outside of the existing fs9 connection". Regards, Pete

Are the two developments related? I thought this "Level D" 767 was a new product. Are you saying it is just an FS2004 update an the old FS2000/FS2002 767PIC? It depends what it thinks is running. With Project Magenta it does one thing, with the (original) 767PIC it does another, with default FS another still. For the old 767PIC it sends the keypresses listed as PIC_AP_MASTER and PIC_AP_LEFT (ids 1000, 1001). Currently PFC.DLL recognises the 767PIC by modules "APS", "B767W" and the gauge "B767WAFDS.GAU". I don't know if this new one looks anything like the old one. You can program any of the PFC buttons, knobs and switches in FSUIPC. If you do so it overrides the PFC.DLL default action. Note that the A/P disconnect button on the jetliner yoke is indistinguishable from the A/P Engage button on the PFC avionics. So it connects as well as disconnects. Regards, Pete