Pete Dowson

Hi Martin, I think I've sorted it. Sorry about the hassle. I'm sending you an interim update (1.821). You'll need to rename your quadrants again. It was a stupid error related to using different headers for debugging and release versions. I'm change the methods now to stop it happening again. Regards, Pete

Hmmm. You are rightthere's something very strange going on. I've just tried to name my User Configs 1 to 6 the same as you, and I get the same result -- U1 is okay, the rest are missing except U5 which gets the name from U4! It isn't anything to do with the names it seems. There's a nasty bug in this some place! Even editing the entries in the INI file doesn't help. Sorry about this. I'll get onto it straight awayI only just released version 1.82 today. It's a shame I didn't learn of this problem a few hours earlier as I would have held back until I fixed it. Never mind -- it's always the way, I suppose. Keep an eye on the Release Notices at the top of the forum. I'll make another release (groan!) when I've got it sorted out. Regards, Pete

I use a Parhelia 256 Mb on a P4 3.2GHz Pc for the main FS PC. This is used currently at only 2400 x 600 x 32 resolution despite the three 18" TFTs being capable of 3840 x 1024 x 32 between them, mainly to keep frame rates well into double figures -- I like to run with most everything in FS2004 turned up to maximum (and with Ultimate Traffic that can impose quite a frame rate penalty). Really most all scenery looks as good at any resolution, so the lower values don't bother me. The screens on the FS PC are only used for the forward view, set at 0.50 Zoom. I find this right for me, though some I know use three screens at 0.31 Zoom. The performance of the Parhelia is not as good as the latest nVidia or ATI cards. In fact it isn't really as good as the previous generation of nVidia cards (the Ti4600 etc). However, for me, the splendid widescreen views out of the cockpit window are well worth it. Note that I do not use any FS cockpits at all. All my instrumentation is either on separate PCs using Project Magenta, or on hardware such as the Aerosoft MCP and the PFC Jetliner Console. I really could not recommend a Parhelia for a normal FS configuration with 2D cockpit displays. Maybe it would work well with the 3D virtual cockpit modes, but I'm afraid I don't like those much. If you have a cockpit design with external (to the FS PC) instrumentation and controls, then I think the Parhelia 3 screen system is really excellent. Otherwise I would not recommend it. You'd do better with dual monitors on an nVidia card, or ATI if they now allow a single window to be spread over two monitors with 3D acceleration still operating. The problem with only two monitors is that either you get left (or right) offset views, or the straight-ahead point is in the dividing line of the two screens, which is why I went for the Parhelia. I don't think anything else offers three screen windows at present. Regards, Pete

Sorry, VisualFX crashes aren't related to FSUIPC. You have something else going on there. Regards, Pete

This is not a bug in TrafficLook, which can only display the information it is given. It appears to be the way FS works. The data TrafficLook shows is the data FSUIPC is supplying it which is obtained from FS. Regards, Pete

90 seconds seems a long time, but when you change the time sometimes FS reloads the scenery and textures. This will take a variable time depending on your system. Regards, Pete

I don't know. All it does is save the names in the PFC.INI file and restore them afterwards. Maybe there's something in the names which don't work in a standard Windows profile INI. Can you tell me what names you used? Did you take a look at the INI file to see? Regards, Pete

Okay, I've sorted that out. It was easier than I thought. Basically, what I had was (where "active" means selected into FS's COM1) COM1: active -> off -> inactive -> active COM2: inactive -> off -> active -> inactive I did this because, with COM2 available in FS, there's really no such thing as "active" and "inactive", so active means "=COM1" and inactive means "=COM2". Written like that (as I did when designing it): COM1: =COM1 -> off -> =COM2 -> =COM1 COM2: =COM2 -> off -> =COM1 -> =COM2 You'll see this looks entirely sensible and logical. I thought folks would understand it better because of its complete symmetry. However, it does have the result you observed. I've now changed it to be asymmetrical, as follows: COM1: =COM1 -> off -> =COM2 -> =COM1 COM2: =COM2 -> =COM1 -> off -> =COM2 or, in "active" terms: COM1: active -> off -> inactive -> active COM2: inactive -> active -> off -> inactive You will see that, then, if you press the On/Off button of an inactive (non-flashing) radio it becomes the active one. This is how it was before 1.81. The only difference now between operation in FS2000 and before and FS2002 and later, apart from there befing no COM2 in FS before FS2002, is that when one of the radios is off, the on/off button in the other only operates as an on/off button, it doesn't change the "active" states. On the Jetliner Console, with its single COM radio, things are rather different of course. On this the on/off button does cycle through "off" to swap from controlling FS's COM1 and COM2, and it swaps the frequencies over too. It doesn't have the facility to use 4 frequencies all on COM1. All this is in Version 1.82 which I shall release later today, all being well. This version alson implements the Avionics Switch, which wasn't quite such a big job as I thought -- most of the avionics stack's buttons and knobs return values all in a group which was therefore easier to bypass than I anticipated. It does mean that avionics buttons which have been re-programmed will also be disabled when the avionics are off, but I don't think that is unreasonable. It already applies in any case to Cirrus and Jetliner users with the hardware avionics switch. Thanks for your help in this. I think the results are very worthwhile. Regards, Pete

Sorry, I'm not really into making applications programs. TrafficLook and WeatherSet are just basic programs, not clever at all, originally designed to let me test the facilities in FSUIPC. I release them as useful little things but that's about it really. The recent changes reflect changes in FSUIPC rather than any real developments in TrafficLook. There are of course a number of TCAS type graphical gauges and displays available, and the new TrafficBoard for FS2004 will show AI traffic around your selected airport. There will be an AI toolkit provided by Microsoft themselves soon (well, I hope it is soon -- I thought it was ready a long time ago, but it hasn't surfaced yet). I am not allowed to say much about it, I'm afraid, but suffice to say I don't think you'll be disappointed. :wink: Regards, Pete

Not that I know of, but then I'd never heard of exit controls till very recently. I wouldn't notice these things as I'm strictly a stay-in-the-cockpit pilot. :) I've looked through all the stuff I have about things I can read from FS, and there's nothing obviously connected with exits that I can see, so it would have to be located deep in some part of FS. I suspect aircraft modellers familiar with MDL files (the ones which have to obey the Exit controls) might be able to say more about how their status could be detected. Regards, Pete

[quote name="blave But' date=' effectively the on-off buttons acted as Active Radio Select buttons, and it worked perfectly in the FS2000 (or was it 98?) single COM radio world, and worked (past tense - see below) fine in 2002/2004 as well if one didn't need to access those versions' COM2 as a true second radio. I just got used to thinking of those buttons as the equivalent to what is found in a real aircraft's audio panel. Yes, this is why I've retained that same capability. Yes, it always did. Look back at the original documentation. It said this "On the separate stack, if both COM radios are in use then the On/Off button cycles between being a COM radio selector and on/off button, thus: Off -> On -> Selected -> Off In this mode only the COM receiver turns off, not the complete set. If both COMs are in use, the one currently operating FS’s single COM radio has a flashing decimal point in the active frequency display." I am only retaining that action and adding more. Hmmm. I don't think that was intentional, and it isn't documented that way. hold on, I'll try an old version ... ... Ouch! It was buggy too. The two radios can get out of phas and BOTH be de-selected (no flashing point)! Ugh. Seems in fixing it so it works as intended I've removed a facility I didn't even know was there! :) Sorry! I'll need to think about that. The old code was interacting wrongly and by coincidence gave you that capability. I'll need to work out how to do that properly. It means re-jigging the sequences so they are inter-dependent again. They aren't now, except that if one is off the other simply swaps functions as well as cycling to off. You must mean the Transponder IDENT, as the NAV ones operate the NAV radio switch. Ah, yes, you must mean the transponder IDENT! :) Yeah, most parameters to FS controls need experimentation to work out how they work. Frequencies and radio codes tend to be in BCD (binary-coded-decimal) internally, and the parameters USED to be quite sensible, but some are horrendous in FS2002/2004. No, you've got things backwards. The parameter you provide is DECIMAL. The decimal 10 value is binary 1010. Since the transponder only uses values 0-7 in each digit, only the lower 3 bits are used, hence 010 which is your 2. No 'huh?' about it. Decimal 100 is hexadecimal 64. Since both groups of 4 bits are valid (0-7), you see 64. Transponder 7777 would be 7777 in hexadecimal which is 30583 decimal. 1200 hexadecimal is needed, which is 4608 in decimal (1000 = 4096, 200 = 512). You might find the Programer's Guide in the FSUIPC SDK useful. It won't tell you what parameters things take, but once you get an inkling as to how FS sees things inside it makes these more obvious. Regards, Pete

Many folks have reported problems with minimising FS2004 and trying to re-maximise it. I think most of them got cleared up with video driver updates and similar, but I must confess that I still find FS2004 very precarious compared to previous releases. It seems very sensitive to a number of things. Ah. that's good to hear! Regards, Pete

Okay. This had me confused for quite a while. PFC.DLL has no knowledge of the "active xmit radio". It never has selected that or had a button allocated to it. There are none spare for what is basically a row of radio selector switches. As far as I can tell, with the option unchecked, there is absolutely no difference now to what happened before, except that now you can use the PFC COM2 radio as the FS COM2 radio. Before, COM2 just was not usable without checking the option. I think you are confusing it with the original (and still intended) action of the on/off button with the option checked. Before I added the support for COM2 you could, with the option checked, select either PFC COM1 or PFC COM2 into FS's COM1. With FS's COM1 as the "active xmit radio" it meant you could effectively have 4 frequencies for transmission. I didn't mean to take that away, and in fact it is correctly documented in the way I intended it. I did have it working, but it seems that fixes for the Jetliner (which has no COM2) messed things up. Sorry. In the corrected version, which I will send you to verify for me (please), if you ignore FS's COM2, the action should be the same as it was before. It's just that the inactive (non-flashing, not selected) PFC radio becomes FS's COM2. So this gives the best of both worlds, even if it does seem a little complicated to explain. Try it, play with it a bit, you'll see what I mean. It becomes second nature after a bit. The Jetliner Console operation is, of necessity, different, as it has no COM2. There, the on/off button changes the single COM radio to be FS's COM1 (flashes) or COM2 (no flashing). The avionics stack COM2 was confusing the issue there, so in the fixed version of the driver, if you select Jetliner (only) operation the stack's COM2 radio is permanently switched off. Anyway, I think it is okay now. Thanks for all your help -- you INI was useful as it enabled me to find it quicker. Starting with my settings it was more difficult to get it to play up. I'm sending 1.812 by email attachment for you to play with. Please see if you can break it! Now I'm back into PFC mode I'll look at adding the FS Avionics switch code before making a proper new release. Regards, Pete

Sorry, no. I think you will be much better off discussing this in the PM Newsgroup, as there are many there who have solved such problems with their Networks. And everyone there is both a PM and Network user, so it is the right place. There are so many variables. All the help I can give is already really embodied in the WideFS document. Whatever your problem is, it will either be sepcific to your Network, or something to do with the PFD INI parameters or video drivers. Regards, Pete

In Fs2002 and before wasn't it "ENGLISH.FLL" and so on? However, I think it was a different system. Sorry, I never really investigated this stuff back then. However, the menu has always been built as needed, not loaded by resource. Regards, Pete

I'm sorry, but I don't know the Jeppesen console. It is made by PFC? Does it use the PFC protocol? Do Jeppesen say it is compatible with FS? Even if it is made for them by PFC, it may be using the Elite protocol, which is a proprietary protocol not supported by PFC.DLL. You need to check these things with Jeppesen or PFC I'm afraid. Regards, Pete

By "AITrafficLook" do you mean the little example program called TrafficLook that i supply in the FSUIPC ZIP? If not, I'm afraid I do not know the program. However, maximising, minimising or re-shaping TrafficLook's windows, or indeed and FSUIPC application's windows, cannot actually crash FS. These programs are entirely separate processes. What is more likely happening is your swapping in and out of FS and its window being minimised and restored or its video mode changing from full screen to windowed or minimised or vice versa? There are some problems known and reported with FS changing video modes. Perhaps you could clarify (a) what program(s) you are talking about, and (b) exactly what is happening to FS windows and so on at the time. Regards, Pete

It's built up dynamically, not completely stored as a resource. The labels are stored in LANGUAGE.DLL which is only a resource DLL. Pete

Programs can use FSUIPC for many things. I think WidevieW only uses it (in FS2000/2002) for weather transfer. The other stuff it does itself. It's an FS module. Regards, Pete

It depends on your Operating System I think. Assuming you are using WinXP, go to Start-Settings-Control Panel-Network Connections, select your Network, then Properties. In the General tab, select the Internet Protocol, then press Properties. Where it says "Use the following IP address" click the radio button then enter your chosen IP address -- for instance 192.168.0.N where N is your choice of number in the range 1-254 (different for each PC). The Subnet mask beneath that needs to be 255.255.255.0. That's it. Okay your way out. I think it is similar on other operating systems. Not that I know of, though I have heard of difficulties with ICS (Internet Connection Sharing). You might be better off asking folks in the Project Magenta newsgroup as there is a wealth of Network experience there. Also the PM network expert Katy Pluta hangs out in the FS2004 Forum here. Regards, Pete

I found and fixed the problem. Version 4.22 is being released now and should appear on the Schiratti site later today or maybe tomorrow. Regards, Pete

I have no check version file. That looks like the Project Magenta check version program. You are appealing to the wrong site, you need to talk to the Project Magenta folks. This forum is for support of programs by myself, Peter Dowson. Sorry, Regards, Pete

You are welcome! Pete

Yes, you are right. None of the Engine RPM values are working! :( It's surprising no one found this before. It's because in FS2004 the values aren't provided by FS in the normal places -- in fact they are from different places depending on whether its a jet, turbo or prop -- and FSUIPC derives them, but to avoid conflicts it stores them differently. I forgot this when adapting EPICINFO for FS2004. :oops: Sorry. I'll get it fixed and release a new one today or tomorrow. Regards, Pete

Please check the release notices a little more often :) . Try 3.129, available from yesterday on AVSIM and this morning on the Schiratti site. Regards, Pete