Pete Dowson

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

I never got IPX/SPX to work well on my systems with WinXP, so I am biassed in favour of TCP/IP for XP, yes. If I had ever managed to make IPX/SPX work I might be of different opinion. Maybe others can say. All that looks perfect EXCEPT the maximum send depth of 92, which seems rather excessive. However, that may have occurred if you had PFD running whilst still loading flights or aircraft of something in FS. In that case I can't really see why you'd notice any pausing. You didn't say WHERE you saw these 10 second pauses in any case? In the PFD? Could they be graphics problems in its OpenGL driver interface? The WideServer log would at least show performance. What are the reported figures at the end there? What frame rates are you getting in FS? What have you set the FS Frame Rate Limiter to? What processors are being used? Are the pauses coincidental with something going on in FS? Regards, Pete

It only needs registering once per PC (and operating system, if you multi-boot), and it can then be used from any account -- but it has to be registered by the Administrator. It is the same sort of thing as FS installation. You can only install FS2004 as Administrator, but you can allow any user to use it thereafter. Many programs are like that. It is because of access restrictions imposed by Windows on non-administrators. Regards, Pete

The pedals and yoke are connected directly, not via a throttle quadrant or anything similar? The USB connection, does that show as a COM port in the Windows hardware manager? Please refer to the List of Supported Versions near the top of this Forum. The current version of FSUIPC is 3.125. You should not be using 3.11. The first message indicates you are not using a current version of PFC.DLL either. It isn't even a recent one, and is certainly not compatible with any Version 3.xx FSUIPC. Current is 1.72 but I am releasing 1.80 this weekend. The second message is merely a reminder to you to tell the PFC driver which COM port you have your equipment connected to. It only occurs until you have done so, inside FS. PLEASE refer to the PFC DLL documentation, supplied in the same Zip. However, if you are not using any PFC digital controller, such as the Throttle quadrant System, the Cirrus console, or the Jetliner Console, then your PFC equipment probably just looks like a normal Windows game device, in which case you should not be installing PFC.DLL in the first place. Please clarify that with your supplier. Regards, Pete

Sorry, I don't know what you mean there. What's ITRA? All the PM controls you may need are available in FSUIPC for assigning to Key press or Joystick Button. You do not need to use SendKey for PM as FSUIPC suports PM directly. If you explain in more detail what you try, what you set in FSUIPC's Keys/Button pages, even show me the resulting FSUIPC.INI file, I may be able to help, but for most technical things to do with Project Magenta you will in general be better off posting in the PM NewsGroup. (I also appear there! :lol: ) Regards, Pete

No. it is nothing to do with when you connect. You are corrupting memory by incorrect declarations. Are you thinking that this reserved 1024 bytes for your FSUIPC connection? It does not. This defines a single byte (yes, just 8 bitss of data), then tries to initialise it to 1024 (which is impossible, as the maximum in one byte is 255. Doesn't the compiler complain about this?) To reserve 1024 bytes of memory you need to do this: BYTE FsuipcMem[1024]; Please refer to some C programming books! :? This is wrong in two ways. If FSuipcMem is an array, as it is when you define it correctly, then you either need to provide its address just as "FsuipcMem", OR give the address of the first byte in it, like this "&FsuipcMem[0]". Second, the FSUIPC_Process call processes your reads and writes, but you have done no reads and writes here, so it is a waste of time. It shouldn't do any harm, but it might. You must NOT use that library in a Gauge. The correct library is the "moduleuser.lib" which is included in the Module User part of the SDK. Regards, Pete

There's really no point. Your INI files should allow everything to default, except just set UseTCPIP=No in both, and in the Clients you may need to provide the Server Node details, as documented for mixed systems or NT/2K/XP servers. I cannot make that happen for you as your Server node address will be unique to you. If it is working at all it means the INI files are correct. Whilst there are lots of parameters you can tinker with, it is not a good idea to do this without any other information about this symptom, "some long pauses". It took me 6 months of tinkering and adjusting to get what are, for most instances, the 'ideal' settings. If you want to keep tinkering for another 6 months and get better settings, be my guest, but I would not recommend it. It is not hapy work I assure you! If there are these massive pauses, there'll be a reason. What do the WideSever and WideClient Logs show? WHERE are these pauses? In FS, in some Application? Which Application? Are you sure it isn't the application which has the problems? And, of course, are you using the very latest versions of both WideServer and WideClient, and FSUIPC for that matter? Please do not show me any logs of older versions. And please, if you do show logs, please close FS down and show complete logs -- there are summaries of performance added at the end which are useful. Finally, why are you using IPX/SPX? Is your system all Windows 98SE? It certainly should be okay if so, but since version 5 WideFS has been optimised more for TCP/IP. Mixed Windows systems, and Windows XP, are probably better with the TCP/IP protocol -- not faster, certainly, but smoother and easier to sort out. Regards, Pete