Pete Dowson

Yes, many cards have that facility these days. Alternatively, if you can find a PCI card, you can, with a little more difficulty, run an AGP card for one and a PCI card for the other. Regards, Pete

I think it is more to do with the gauge which insists on only working in FS2002 even though there is no reason for such a stupid restriction. For FS2004, which I assume you are using, there is an unpublished fiddle, which I am not about to expose here. You need to talk to Peter McLeland or at least read his readme files on the subject. Regards, Pete

Ah, the Alting module. It seems rather similar to a Microsoft tool, not yet made available generally. It is an FS module, not a free-standing program -- in the same way as FSUIPC is an FS module. In fact I think its AI graphics views are the ones you get with CTRL+W: it is generating that standard FS view for your selection. Since it is an FS module it can only run in FS. If you want to run it on a separate PC you have to have FS installed on that PC too. For FS2002 or before I'd then recommend you link them with Luciano Napolitano's WidevieW. That isn't available for FS2004 though, so for FS2004 the only way would be to link the two using Multiplayer. However, MP defeats the object completely as when MP is running you get no AI traffic. Even with two FS installations running on separate PCs, assuming you could link them and have AI running, there is no real way to get the AI synchronised so that it's the same on both PCs. I'm afraid your only solution is to have multiple monitors on the main FS PC and undock the AI display windows and drag them onto the other monitor. If you can do without the graphics and just want to keep tabs on the traffic details, then you can certainly do that on a second PC via WideFS using TrafficLook, supplied in the FSUIPC ZIP. For observing traffic movements at the airports, TrafficBoard (shareware) is very good, and that can be run on a second PC too. Version 2 works with FS2002, Version 3, for FS2004, is currently in Beta -- see the separate Forum near this one. Trafficboard also comes with an FS module which can bring up the appropriate CTRL-W window to view a selected aircraft -- but of course that window will still come up on the FS PC even if Trafficboard is being run on a client PC. Regards, Pete

The most likely possibility is that you have set the option to "suppress possible interference from Game Port throttles", on the Main Options page of PFC. As it says in the documentation "the suppression cannot be on by default because Wilco’s 767PIC (and others) uses the same input controls to operate the auto-throttle." -- perhaps this also applies to PSS aircraft? Otherwise, the A/T getting overruled is often a symptom of jitter on the axes, but this shouldn't really be applying to the PFC gear, especially not with the smoothing incorporated recently. Where do you 'park' the PFC throttle levers when using A/T? Certainly the PFC driver will only be sending throttle values to FS when there are changes, so jitter does sound a possibility. Try calibrating the levers with good "dead" zones at both ends, so you can park them at full throttle and at idle and be sure that no changes are being sent. Regards, Pete

Does AIView actually show the aircraft graphic, or just details of its activity, like TrafficLook? If you could tell me more about it I could perhaps advise what might or might not be done. Have you an URL where I can get it, perhaps? Pete

Sorry, I don't understand any of this. What's AOM and Sound Carpet? What's the FS top bar? You mean the Title Bar? What does that say? FSUIPC doesn't do anything with any "bar", title or otherwise, and since I've never heard of AOM or Sound Carpet I cannot really see how FSUIPC has anything to do with either. Very sorry. Regards, Pete

According to messages on some of the other forums, this is because the Microsoft/Jeppesen weather service has been down for a while. I don't know when it'll be back up. Maybe it is already. See for instance this thread in the FS2004 forum: http://forums.simflight.com/viewtopic.php?t=15341 Regards, Pete

That is because FSUIPC needs to know when you have loaded a new flight or weather scenerio using FS facilities so that it doesn't try to overwrite it with any externally set weather. That's all it means. It isn't FSUIPC clearing the weather, it is clearing its memory of external weather from FSMeteo or whatever. By doing that you are asking FSUIPC to make changes to the weather FS sets itself. If it does this you will never, for instance, get weather themes to stick. They will always revert to "user defined". That is what that is defaulted off, so you don't get FSUIPC interfering with anything! You needed to leave it alone, as it was. You have set it the reverse I'm afraid. FSUIPC doesn't touch downloaded weather UNLESS you change some of its options to allow it to. That is why the defaults are set that way, to avoid the confusion you have got into by misinterpreting one log message as its reverse! Regards, Pete

I'm sure that isn't the intention, but I'm equally sure that multiple users weren't possible in the early days. It might be worth seeing if there's a later version of the EPICIO.DLL -- check with R&R. I expect Ralph can clarify the issue. Yes. You'd have to disassociate the axes from FS (i.e. delete the asignments), and use either the joyGetPosEx or DirectInput methods to read the values yourself. The former is easier unless you are into COM and are a bit of a masochist! :) I don't know what you are trying to do, but if it is only the main flight controls (aileron, rudder, elevator, and throttles) that concern you in this, you can let FS read the values, and intercept them in FSUIPC instead. See offsets 310A and 3328-3336. Doing things this way has the advantage of using standard calibrated values in FS terms, not the devices. Okay. thanks! Regards, Pete

Sounds like you are either using older versions of WideFS, or have some other network problems. First please check you are using the latest versions of everything (see the appropriate announcement at the top of this Forum), then check in the WideServer and WideClient LOGs. Also make sure you don't have any odd network related settings in your Wideclient and WideServer INI files. Just use defaults except, of course, for specifying the protocol and the Server name or node. Older versions of WideServer use to deliberately disconnect clients if it couldn't get enough processor time to service them within a certain number of seconds. This was really to get over mishaps where all the data needed refreshing. It doesn't do that any more (well, it's optional and off by default), but, even if it did, each Client should readily re-connect and refresh the data within so many seconds (about 15-20) after FS becomes ready again. If they are not re-connecting there is a Network problem. You say "sometimes even when I start the computers they fail to connect", which is certainly an indication of Network problems, unless you just have the parameters wrong. All the information needed to look at these is available. Version numbers are always needed, then there's Log files and the INI files. If you cannot make head nor tail of them, let me see them. But try to keep them short please, and make sure you are using the latest versions, as I say. I have no interest in looking at logs and ini files for older versions -- I do not want to fix the same problems more than once. :? Regards, Pete

Ah, perhaps I misunderstood that part of your report. Are you saying that, starting FS from scratch with a newly-initialised EPIC (to make sure it is behaving), and not running your program at all, EPICINFO still seems to hang FS? In other words, with only my modules accessing EPIC? If so I can only think that it is a problem with the EPIC firmware, or the EPICIO.DLL, or the EPL coding for the KR-1, or some incompatibilities between these things. There has been no significant change in EPICINFO.DLL nor in the EPIC parts of FSUIPC and WideServer for a long time. Try it all without actually loading the EPL for the KR-1 into the EPIC. Just load a default program or leave it as it is when it starts. EPICINFO, with the same EPICINFO.CFG file, will still be doing pretty much the same things. This may show whether it is something in the EPL or EPIC firmware. There is also extensive logging in the EPICINFO armoury. You could try some of that and see if you can spot what might be going on there. Otherwise I am really at a loss. The KR1 program was originally mine, many years ago, but the EPICUSB version was rewritten by Ralph. You may in the end need to get back to him to help sort this out. At least he will suggest ways of debugging the EPICIO and EPIC firmware side of it. There must be quite a few KR1 users about with USB EPICs, so FlightLink themselves may know more about this. If it happens without any of your software touching anything then I think those are your possible courses of action. If you do produce any interesting EPICINFO logs I can help you interpret them, if necessary. Regards, Pete

Well, it must be different in your part of the world. Without that number I might as well scrap my credit card and never do on-line or telephone shopping at all, because no one I've dealt with for a couple of years will sell without it. In this country (and as far as I know all parts of the EU) the credit card company is liable no matter what. They can't get out of their legal responsibilities on such a flimsy basis. Your consumer protection laws need tightening by the sound of it! The security number is not a PIN number, used to get cash, it is what it says it is. PIN number protection is most definitely a different kettle of fish. SimMarket offer many other ways to pay, even cash if you want to trust the mail service. It's up to you. I'm sure many folk use PayPal, that's certainly the commonest option these days I think. I have no idea why you were refused that option, it makes no sense. Check with their Customer Services. Regards, Pete

You mean the three digit number on the back? Don't you use your credit card much these days? Every single dealer, whether by phone, email, website, whatever, want that now. It's all part of the improved security -- the number doesn't appear on receipts and so on, so if you quote that correctly they know you aren't just someone who picked up an old receipt or carbon, at a shop etc. It's for your security. Don't forget they don't get to see your signature. No idea, sorry. Ask them. Customer Services, http://www.simmarket.com. Regards, Pete

This is an ISA card, or the newer USB version? What Windows operating system? And this is using what to communicate with the EPIC? It sounds very much as if something your program is doing with the EPIC mucks up something that EPICINFO is doing with the EPIC. If this is with an ISA EPIC, using my own EPIC.VXD, theb you should be programming using only the joyGetPosEx calls as documented in my EPIC95 documentation. Otherwise you certainly run the risk of tying up the EPIC queues. If it is using EPICIO.DLL to communicate with either the ISA EPIC or the USB EPIC, then are you sure you are using a version of the DLL which can support multiple simultaneous users? If the EPICIO.DLL is hanging during a call made from EPICINFO then this would obvously create problems, like hangs, in FS -- some threads might still be running of course, which could explain what you see. It would also explain why restarting your program doesn't work (the EPICIO.DLL is hung) and why when you think you've closed FS you really haven't -- a DLL is still not closing because it is hung. I really am no longer an EPIC developer or even much of a user, though I do have a USB EPIC here connected and used for a few buttons. Certainly, if I experienced such problems I would have to ask Ralph Robinson at R&R (EPIC makers) about them. This is most particularly true for EPICIO.DLL, which is just a black box to me. Maybe he can tell you how to enable some sort of diagnostics. Maybe he has a later version whivh can cope with the demands you are making? Whatever, I'd be glad to hear of the outcome. Regards, Pete

Hmmmyes. Sounds okay. Thanks & Regards, Pete

I've not changed any of that code, and it works fine here. I've just tried all sorts of things and it won't go wrong. BUT! I do know what I forgot! Hell and damnation! :oops: When I inserted the new "737NG" standard quadrant, all the others after that got re-numbered up one. So the section in your PFD.INI file named [AircraftQuadrants] will, on their right-hand sides, have numbers which are wrong if they were 7 or above. They should now be 8 or above. If the wrong number now points to a quadrant which isn't enabled then PFC will make up its own mind what to give you. The fix for you is easy. Delete the aircraft assignment (button on front page) and re-assign the correct quadrant to your aircraft. OR (if you have a lot) edit the PFD.INI file and increase any quadrant assignment over 6 by 1. The fix for me is a bit of a problem. Should I just tell anyone who inquires about this to do the same, or should I fix it by automatically re-jiggling the numbers internally? If I do the latter, then anyone who has used 1.80 and sorted it will then be messed up in 1.81. Duh! :? What do you think? Sorry about this. There's always something, isn't there? Everything is connected to everything else. :( Regards, Pete

It sounds like you have not registered FSUIPC and Mr. Marciano's gauge is not providing an access code to aloow it to read the date. If you check the FSUIPC LOG file (in the FS modules folder) it should tell you what is going on with that. I don't know what gauges of Mr. Marciano have been modified to access FSUIPC correctly and which have not. This is really a question for him. I do have a list of gauges which have been issued with keys, but I don't know which are Mr. Marciano's. Regards, Pete

Which PM functions have you programmed? Did you ask anyone on the PM Newsgroup? There's a lot of experience there with this sort of thing. All the FSUIPC added controls for PM do is manipulate the controls that PM offers through its FSUIPC offsets. The rest is up to PM, so it probably depends how that is configured. You can also use PM's CDU to look at the FSUIPC offsets which it cares about. The only parts of your FSUIPC INI file which are relevant to programmed buttons and keys are these: [buttons] 0=H0,6,K120,8 1=H0,4,K109,8 2=H1,0,K109,8 These are for Joystick 0 buttons 6 and 4, and Joystick 1 button 0. They only produce keystrokes, You haven't programmed them for PM functions. The keystrokes produced are F9 and the Numpad - (twice). They are also programmed to stay pressed whilst you keep the button pressed, releasing when you release the button. I don't know what you are using these for (F9 is perhaps for FSNav?), but they won't be anything to do with PM. [Keys] 0=79,11,2115,22 1=87,8,2097,0 Here you have programmed two keypresses: CTRL+SHFT+O (letter O), to the PM Airbus ADF1 "on" switch (for the ND) -- oddly enough, with a parameter of 22 which won't do anything useful as the control takes no parameters. and W (on its own!!!???), to select PM's ND Map Arc mode. Mixing controls for the Airbus ND and the Boeing ND seems odd. Do you have one of each running? And being able to switch the ADF1 on in the Airbus ND seems to be not a lot of use if you don't also program something to switch it off again. All in all, I still really do not understand what you are trying to do nor what difficulties you are finding. First of all, does this ITRA device look like a keyboard and produce keystrokes, or does it connect like a joystick and produce button inputs? I think you need to understand that part first. Then use the appropriate page in FSUIPC's options to program the buttons or keypresses your ITRA device is producing. For PM don't try to send keystrokes, all you need is in the PM controls lists. But choose the controls that you need for your particular PM configuration. Also, please note that most (though possibly not all) the PM controls are actioned by the MCP part of PM, even if they are aimed at the ND. If you aren't running the MCP then those will be ignored. For some notion of which are okay without the MCP and which not you'll need to ask PM support. But if you don't use the MCP then, yes, you may well have to resort to trying to use key strokes. That will certainly involve programming FSUIPC "SendKey" controls for WideFS, and manually editing the appropriate Wideclient INI files to configure the appropriate key strokes and get them sent to the appropriate program. That is nowhere near as easy or reliable as the PM controls via MCP. Regards, Pete

Ah .. so AdvDisplay is capturing them when it should. That's good! Thanks for letting me know. That's quite a novel use of the facility! Good thinking! :lol: Regards, Pete

I really do not know whay they are not appearing. Evidently they are using some property of that window facility which I am excluding. I am not a Squawkbox user, so I am unable to determine the reasons here. There are two possible ways to proceed. Either you can ask the Squawkbox author to tell me exactly waht parameters he is using in the call to FS, or I can devise a modification to log these things and get to to run it. Let me know. Pete

Ooops! I can do this, but not here nor with this information. Please send both the emails notifying you of your registrations, to me at petedowson@btconnect.com. I can replace either one, state your choice, and send it by return. If you need to re-register, delete your FSUIPC.KEY file from the Modules folder, then register both parts. Regards, Pete

Yes, I've noticed that too. As you say, it is annoying. I thought it was just some odd quirk with my Matrox Parhelia. Please let me know if you do hear of a way to switch it off. I assume it will be something to do with video driver settings? I'm afraid there's little chance of that -- nothing in FSUIPC currently is related to any of the actual graphics. It is an area of complete mystery to me. Sorry. Regards, Pete

FSUIPC just does what it is told. You are lucky ot get overcast clouds at all, the main complaint I see about FS2004 clouds is that they are rarely if ever truly overcast. But are you sure the skies aren't simply gray, not from clouds, but from mist? Check the visibility. In FS2000 and FS2002 any visibility less than 4 miles made the skies grey instead of blue. In FS2004 this limit seems to have gone up to around 10 miles. Many METAR stations are automated, and those give visibility as "9999" metres or "10SM", which means literally 6.2 miles or 10 miles respectively, for any higher visibilty. If this is taken literally at that value, the skies will be gray. Switch on the option (in FSUIPC) for Extend METAR max vis) and it will generate a variable visibility between the 6.2 (or 10) miles and your maximum setting in FS. I think the option is also accessible in FSMeteo. Other than that, if it is cloud overcast you are seeing, you'll need to send the data to FSMeteo support to find out why the METARs are being misinterpreted. Regards, Pete

:o :o :) :) :D :D :lol: :lol: Thanks for a welcome interlude! Much appreciated! Regards, Pete

It's some sort of interaction with that ******* FS prop sync thing. I've taken all that out now. I wished I'd never set eyes on the blighter! :? Anyway, I'm releasing version 1.80 within the next two days, with quite a few other changes, so hang in there please. It will be okay. Regards, Pete