Pete Dowson

No, it knows nothing about any other MCP you have. And it doesn't need to. You will just get two ways of controlling the A/P instead of one, that's all. PFC.DLL's MCP controls talk to one of FS's AP, PM's MCP or 767PIC. What happens then is up to them. But it will only send new Alt, Heading, VS or speed values when you change them, and similarly for the modes. Lke the Aerosoft COM-port based MCP, any other MCP should co-exist quite happily. It sounds like something is going wrong between the new hardware MCP and PM's MCP. I hope you get the answers you need from the PM Newsgroup. Regards, Pete

Thank you very much Francois. Now for the answers which I hope you can relay: Yes. The registration of FSUIPC belongs to you, the person, not your computer. You can use it on any of your computers, provided it is you who is the prime user. You will need to enter the same exact details (name, email and key) on your new PC. The French translation was done voluntarily with my approval, and involved replacement of the resources section of FSUIPC, which contains all the messages. With version 3 that is not quite as easy as the resources are bound up more tightly with the program. Nevertheless it is still possible -- no English messages (except for the Logging) are actually built into the code. I think the original volunteer translators may be amongst those who disagreed with FSUIPC becoming payware, and who would rather have seen no FSUIPC for FS2004 at all. Consequently, even though I offered to help resolve the more intricate binding of the messages so that a French version could be made, I've not heard from them at all concerning this endeavour. If I do receive any offers for such work I will certainly consider it, maybe even on a profit-sharing basis -- perhaps a French retailer responsible for a French translation? Regards, Pete

There certainly is nothing specific in any of my software to deal with or recognise anything about any such MCP, so the answer is "no", there is nothing in the INI files which is likely to make any difference whatsoever. I'm a bit curious as to why would you think it would? The INI files are basically just reflections of the options you select in the option screens in FS in any case. I'm afraid know almost nothing about this new MCP. Have you asked the suppliers? Does it use FSUIPC? I see you have it running on a Client PC, so does it use WideFS, or connect to FS or PM some other way? I thought from assorted messages on the PM Newsgroup that PM had specific direct support for it on its own COM port? Since you have PM's MCP and the hardware MCP on the same PC, I would assume there is no connection between the hardware MCP and any of my programs. Do you think there is? Regards, Pete

Is anyone here able to translate this for me, please? And translate my reply? Thanks. Pete

Not me, you didn't. I am not at all involved in FSUIPC or WideFS retail sales. That is all handled by SimMarket. I get my share weeks in arrears. I spend my time programming and supporting my programs, not selling anything. If you have any problem with SimMarket you need to check with their customer services, check on http://www.simmarket.com. Don't worry yet if it hasn't been 24 hours, they cannot guarantee an immediate response, and rember time zone differences. Regards, Pete

I have Ultimate Traffic installed, which is probably more intense, but there's no difference in performance since updating FSUIPC. However, try version 3.125, now available from http://www.schiratti.com/dowson, see if it helps at all. Regards, Pete

FSUIPC does not provide the multiplayer interface. That is built into FS. And FS2004 multiplayer is NOT the same as FS2002's. You need SBRelay I think. But I am NOT a Squawkbox user and know nothing about it. :? PLEASE post a NEW message with a proper title, in the Forum, and people who know how to do this thing will help you. This is the WRONG PLACE! It is a list of FreeWare keys. There is one key for Squawkbox (none for "Squawkbox2"). Please please please rephrase your questions and ask them in their own thread. You will get some help. I cannot help, I know nothing about this area. :( Regards, Pete

I'm not removing any FSUIPC facilities, so, yes, of course you can still generate keystrokes through FSUIPC. But if you are writing a program in any case I believe the PMDG SDK may actually allow you to interface much more effectively directly. My concern for FSUIPC was not for the programmers, more for those who buy or make devices with buttons and knobs currently usable with FS or PM, and want them to work into the new panels too. I thought "annunciators" were displays telling you stuff like the modes of the A/P and A/T systems. If you mean directly setting the A/P register values, like speed, altitude, heading, and V/S, then that as usual is one of my concerns, as trying to set these with just INCs and DECs with a rotary switch is a pain. Regards, Pete

(LATER): I've just checked it in FS2002 and it's the same there. I can't get my FS2000 installation running and haven't time to re-install it, so I tried my old bare-bones FS98. Guess what? It's the same there too -- well, almost. There seems to be a permanent deviation from 0 = true North in FS98. But it's only a degree or so. Odd. It isn't related to MagVar, it's the same all over the world. It was probably down to the longitudinal axis of the aircraft I used being off-centre or something. Anyway, I'm going to be bold and assume that, since it is there in FS2004, FS2002 and FS98, it'll be the same in FS2000! Odd that it's not been 'discovered' before. Evidently it isn't of interest to many! Regards, Pete

No, they're just too busy. I got an answer from the guy I deal with, who is always very helpful. They are planning on providing a proper SDK for programming their cockpits, and it sounds like it's being worked on already, but they won't give timescales yet (I don't blame them, really. It's always a mistake). Whether this is what I want to interface to or not remains to be seen. At the very least you'd be able to use a keyboard interface, programmed for buttons via the FSUIPC Buttons page. I am hoping for more, but we'll have to wait and see. Pete

Okay, thanks. I've now checked it here. I'll check in FS2002 and maybe FS2000 too, see if they have the same thing. I'll add it to the SDK documentation. Regards, Pete

That's the magnetic variation at Seattle. True north is 20 degrees different from Magnetic North. to find true North in FS, put your aircraft into Slew mode (press 'Y') then press the Space bar. The aircraft will face true North and you can read the variation off the compass/heading indicator. This is standard FS representation of headings -- as used and explained for offsets 0582 (the high part of 0580) and the wind direction indicators, and so on. It is also used for the Mag Var at 02A0. But is it the view direction of the nose direction? Does it change smoothly as you pan, or if you use view selectors? I'll look at it tomorrow if I get time, but it doesn't sound very useful if it only works on the ground ...? Active Camera does it very well, but I don't know how, and I don't suppose the author will give away any of his secrets. But you could ask him. You never know. Regards, Pete

FSUIPC has nothing to do with multiplayer. I think you need SBRelay for that, but please ask questions in a proper new Thread with a decent subject, not here which is to do with Freeware Key requests! That is not valid in any case. The program name, as clearly listed in the Freeware Keys list above, is "SquawkBox" not "Squawkbox2". You are using version 3.03 of FSUIPC which is at least 9 versions out of date and is not supported! Regards, Pete

Okay, I've added it to FSUIPC. You'll be able to read the radio height in metres * 65536 in the 32-bit integer at offset 0x31E4. This is supported on all versions of FS from FSUIPC version 3.123 onwards. Please note that the radio height when on the ground is not going to be zero. it is the height of something in your aircraft and will vary -- it's less than 2 metres in a Cessna 182 but a lot more in a 747, for example. If you want actual difference beteen being on the ground and airborne you'd need to do subtraction of a fixed constant, different for each aircraft, in any case. I'll be releasing 3.123 within the next couple of days. I'm just waiting for some feedback from testers. It's mainly a quick 'fix' release for some odd problems in 3.12. Regards, Pete

The problem is it then probably breaks many links others have made to it. However, Enrico may be able to do it by having two files, with different names. But it is up to him. I do not maintain the web page, I have no control over it. Regards, Pete

In that case my fixed version will make no difference at all. The only change made in FSUIPC 3.12 which may have a small impact on performance is the additional AI traffic data. To see if it is related to this, can you try some experiments, please: 1. try with AI traffic turned down, off, then back to your normal level. 2. Try with the FSUIPC INI parameter "TrafficScanPerFrame" parameter set both higher and lower than your current setting. Default is 10 (10%) try with 1% and 100%, see if either makes any difference. I do have FSNav installed here and cannot reproduce any problems in the sounds or other performance. Thanks, Pete

Is your FSUIPC user registered? There's no difference otherwise. There's a problem with add-on Gauges which use FSUIPC if it's not registered, but there's no other changes which would be responsible, and FSNav doesn't use FSUIPC. Each new version replaces the previous. I don't support older versions. If you want to try an intermediate version with the Gauge problem fixed, write to me at petedowson@btconnect.com. Regards, Pete

No, the subtraction is done in FS when FSLook asks for that Gauge Token. It's a clunky inefficient interface which I made only to help original C programmed Gauge makers. The interface and method is not suitable for production programs. I'm not sure I can offer an alternative to the subtraction at present. How are you handling conversion of all the other funny FS units, such as Latitude/Longitude, is any case? Or is it just that you don't allow values derived from more than one source? Anyway, I'll check into it for you and see if I can find a way. If I have to calculate it this won't be done continuously, but probably once every few FS frames. Regards, Pete

They are Gauge variables, available to FS gauges. It is best not to actually use any of the values listed in the second table in that document. They are not guaranteed nor maintained. Please refer to the first, very long table. You should find everything you want somewhere in there. Just not by the Gauge token name, or in the same format. That is a calculated value. It is not efficient for FSUIPC to keep calculating it just in case anyone may want it. To get this for yourself, simply read the Ground Altitude (offset 0020) and the aircraft altitude (offset 0570) and do a subtraction. Regards, Pete

Stutters near ground are almost always down to stuff like autogen and other ground scenery. Try turning something down. You may also get them with busy airports if you have the AI traffic set high. In version 3.12 FSUIPC is collecting more information on AI traffic now, but the time difference should be minimal -- by all means experiment with a lower value for the "TrafficScanPerFrame" parameter in the FSUIPC.INI file. By default it is set to scan 10 of traffic per frame. On faster PCs values even as high as 100 there seem to make no differences, however. The routines are fast. Alternatively you could program a button or key to reduce traffic density on approach. The new controls "Traffic Density Set" or possibly "Traffic Density Toggle" can be used for this. They are in the drop-down list in FSUIPC's Keys and Buttons pages. Be warned that whilst reducing AI traffic doesn't cause much of a hesitation, increasing it again stops FS for a short time whilst it re-reads the Traffic file (a progress bar appears). Regards, Pete

FSInterrogate is using FSUIPC, so it is identical. I've no idea what is in 05D2. What values apart from 0=North do you see? What view direction are you trying to adjust? I provided an easy to use selection for the main view directions at 3126, but I never found a way to tell which the current view direction was. I don't know what 05D2 is, so, sorry, I've no idea. Regards, Pete

I have a slightly modified version of FSUIPC, version 3.121, which may or may not fix this problem. If the sufferers who've written here already can contact me on petedowson@btconnect.com, I'll send this for testing if that's okay. In short, I found a possible timing problem, a sort of gap between an aircraft being loaded (i.e. the AIR file then panel) and my detecting this occurring. If any of the new gauges attempt to register during that period, there is a chance that their registration will be accepted then (hence the "ModuleOk" message), but then their access gets denied when FSUIPC actually sees that the aircraft has been changed. I don't know why this should be different in this version compared to 3.11 -- that part of the code hasn't changed. But in between these releases I have upgraded from MS Visual Studio C++ 6 to Visual Studio .NET 2003 with a new C/C++ compiler (version 7). It produces more efficient code (hence the smaller DLL file size), but evidently the timing changes this introduces are enough to cause this problem on some systems. Anyway, I've closed that hole, but since I couldn't reproduce it here I need it testing, first, before I release it. Please? Thanks, Pete

Ah, thanks to James, yes, I spot the error here. The first FSUIPC_Write above needs to be an FSUIPC_WriteS (for Write String). I forgot, VB is a bit weird with passing strings -- C and C++ pass the pointer, VB doesn't unless you force it to. Or something like that. As James' code snippet also shows, you still need to add a zero at the end -- it seems VB strings unlike C/C++ ones aren't stored naturally with terminating zeroes. Thanks James! Pete

There certainly isbut I'm at a loss at present. I simply cannot reproduce this. Can you turn on FSUIPC's read and write IPC logging please, keep the session short, just enough to show the problem, then make sure to close down FS and Zip up the FSUIPC.LOG and send it to petedowson@btconnect.com. The one log I've seen so far looks fine, but isn't with FS closing at the end, so shows me a little less, and there's no IPC logging. I have the PMDG 737NG and cannot make it go wrong even with my registration removed. I can only assume that my version of the 737 is different somehow, so perhaps you could include in the Zip the relevant AIRCRAFT.CFG and PANEL.CFG files, please? If I can think of anything to try to find out more I'll let you know. Maybe I'll try some code changes and send you a version to test. Write to my email first. Regards, Pete

But they are connected to the aileron control, and would be provided for in those FS models simulating them. Sounds like you want to make some adjustments to the aircraft modelling - AIRCRAFT.CFG parameters or possibly AIR file editing. That would be programmed into the visual modelling for the relevant aircraft, but still count as part of the ileron control. there's no separate control that I know of. Regards, Pete