Pete Dowson

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

FSUIPC never clears that byte. As it says "This byte needs to be cleared by the application so that it can detect when the Hot Key occurs." Since FSUIPC doesn't know how often you are scanning, it cannot risk clearing anything. You should be scanning your list of hotkeys regularly, and clearing them down. If your program is going through phases where you only want to look at one key at a time you could conceivably do it by clearing byte 3 for those keys ABOUT to become 'valid', but obviously it would be easier to have a little procedure which checks all of them, and clears all of them, on each cycle whether you then act on them al or not. Take care only to clear Byte 3 on those entries you are using. These may not be contiguous of course. Other programs may have come and gone and occupied some of the slots. Regards Pete

It depends what you want to do. For most of the controls a pilot would have over his glass cockpit there are PM controls which are programmable directly in the drop-down lists of FS controls in the Buttons and Keys options pages in FSUIPC. There's an almost complete list in the FSUIPC Advanced User's Guide. For some of the controls there are parameters needed, and the complete list of those is best obtained from the PM documentation website -- the PM FSUIPC offsets document is the one. You'd only need to think about using KeySend if you want specifically to send keystrokes to the individual glass cockpit modules on their PC. But why would you want to do that? This sort of question is best asked over in the PM support forum/newsgroup, as you will get help from many others who've done all this stuff before. Regards, Pete

There's no way through FSUIPC I'm afraid. Provisions for doing what you want are, I think, built into the BGL programming system, as in "dynamic scenery". There are some variables you can use for two way communication between programs and scenery, but I don't know if they help. You could do with finding a scenery maker's forum. I'm sure there must be a place somewhere where the experts hang out? Regards, Pete

Did you search on the letters "ADF"? That's all I did! :? I don't remember all that stuff in the documents. Each time someone asks me here, I have to go look in the document too! :wink: Regards, Pete

Erit tells you right there on the screen, next to the checkbox which enables the limits, just immediately above where you enter the values which you enable by the check box! Isn't it clear enough? Regards, Pete

It's boolean then -- it can be represented by a number (1 for on, 0 for off) or just a single bit. I'll look to see where I can fit it. I'll add it before the 3.47 release I plan for the end of the week. Regards, Pete

Yes, thank you. Things are becoming a little clearer. This change in 3.410 is probably the cause (quoted from the History document): I must admit I forgot this change, a minor adjustment in a user facility. With an unregistered FSUIPC there is no possibility of the graduated visibility option being switched on, so it is a puzzle. I will conduct some experiments here. Considering this change occurred last November it is odd no one else has mentioned it. Perhaps all other SB users register FSUIPC? But that seems unlikely. I will look to see if I can fix it in the 3.47 release I plan for the end of this week. Thanks! Pete

You are correct about the other things, but where does it say to follow a keycode by K? Are you by any chance mis-reading the sentence: which is referring back to the Format of the [buttons] programming entry in the FSUIPC.INI file? i.e. The K is used in that entry to distinguish Keycodes from Controls ('C'). But that's all to do with FSUIPC buttons programming in the INI file, nothing whatsoever to do with programming hot keys in any application. You can find all the Virtual Keycodes in any Windows programming reference too. They are known by names starting VK_ and are returned by Windows WM_KEYDOWN and WM_KEYUP messages. Regards, Pete