Pete Dowson

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

It's a bit nasty of it just locking things up rather than returning an error if it won't allow access! Any error returned to WideServer would certainly be reported in its log. Sorry, I've no idea. It sounds like a bug in the latest version of ZA. I should revert to the previous (good) version if I were you, and report the problem to the makers. If it were providing a diagnostic I could maybe understand it, but simply locking up a genuine Network user is most definitely not a good thing and must be counted as an error. Regards, Pete

Ouch. It sounds (and looks) like something is wrong with the Network installation. Does your Network behave well in all other respects? Can you share folders and so on with Windows Explorer? The only thing peculiar that WideServer is doing is trying to open a serving port on the Network. There's nothing of a low enough level in any of FSUIPC or WideServer to lock things up. Please see if you can check out your Network first, then get back to me and we'll figure out the next step. I'm afraid I don't really know much about Networks, it's all trial and error for me to get them working. The Network code in WideFS is straightout of Microsoft examples and has been virtually unchanged now for five or six years. Regards, Pete

If merely recognises standard Windows messages arriving in FS. I.e. "WM_KEYDOWN" and "WM_KEYUP". If these are programmed in FSUIPC it captures them. Otherwise it lets them go through for FS to deal with them. There is no need for any low level stuff in this. If your device can produce keystrokes that FS sees then FSUIPC will see them too, it is effectively part of FS when installed. Regards, Pete

You only showed a little of one WideClient. Is that the only one with pausing? You still haven't said where you see the pausing. You also missed some other questions. What frame rates do you get in FS2004? Do you get pausing there? I would really recommend moving stuff off the FS PC if possible. What is your frame rate limiter in FS set to? With FS2004 on a Pentium 2.4GHz and with all those other things running on the same PC I wouldn't expect you to get smooth operation with anything more than 20 fps, probably less if you have many of FS's quality sliders turned up high. With so many things running, you may need to start taking some off to see which ones are contributing to your problems. Regards, Pete

What PFC equipment are you using? Does "On Top" use the same native PFC protocol as FS? I know that PFC also do Elite protocol systems which are certainly not compatible. There is more extensive logging available in the Test page. If you enable the "Log all COM port send receive data", and show me an extract from the PFC.LOG file you get, I can see if it looks like the right sort of data. You might want to check back with PFC to see if your equipment is compatible with FS, or possibly needs a different driver altogether. Regards, Pete

FSUIPC only needs the FSUIPC.KEY file in the FS modules folder, and some entries in the Registry NOT associated with you as a user. Have you got separate FS2004 installations? If so, please simply copy the FSUIPC.KEY file across so that it exists in both Modules folders. Otherwise the only way I know that could happen is if you have separate Registries for each user, and I don't know how to accomplish that. On my system every user has entries in the same registry. What's an "Admin group"? I have multiple users on my system, but I have not set up any "groups". Maybe it is something to do with that? Regards, Pete

There's no "readme" of mine which gives any codes. The FSUIPC user guide explains the registration system, and I referred you to the "Sticky" post here in the Forum for Freeware keys. Glad you sorted it out nonetheless. Regards, Pete

Good! Also, good luck with C. It may be difficult at first, and, indeed, it is much easier to make mistakes in C, but I think you will find it worth it in the long run. I think it gives you much more control, more power, but of course with power comes responsibility. You have to be more careful too! Regards, Pete