Pete Dowson

It was all right when it left here. If you have any difficulties with web sites, please contact the support unit who maintain the web site. I distribute to many web site managers, I don't have a site myself. In the case of the Schiratti page, I have just downloaded it as a test and it is fine! Try again -- if it is still a problem I think you need to contact your ISP who may be caching it wrong somehow. Regards, Pete

In C and C++ there is always a zero at the end of a string. You are not using "strlen()" are you? If so, just add 1 -- as you will see, if you check, strlen() counts the characters up to but not including the zero terminator. It is more efficient in any case to declare the string as a character constant (i.e. char xxx[] = "...";) and use "sizeof" to place the length in the FSUIPC_Write. The sizeof will include the zero and will be more efficient because it isn't counting bytes at run time. Regards, Pete

This is undoubtedly due to the fact that you've probably missed out the final terminating zero byte on the string you send to offset 8001. The result of this error is indeterminate -- it depends whether anything else has written to that area before your gauge -- it a Gauge or DLL with a longer name wrote its registration there first, then the apparent name of your gauge will be wrong, it will be longer because of your missing zero! This would have also been the case before 3.22, but due to this improvement in FSUIPC 3.22: as listed in the History document, all such cases are now detected and reported. Because so many gauge programmers seem to have made this same error, despite the specification being quite clear on the point, I have actually made changes in FSUIPC version 3.30 to hunt down the ".gau" or ".dll" in the name and insert a zero myself, but this really should not have been necessary. Regards, Pete

It must be version 3.xx as all previous versions were free of any registration requirement. A registration of version 3 covers all updates. Only the latest version is supported in any case. I'm sorry, but I am not at all involved in the issue of keys. All that is handled entirely by the retailers. They do get paid to handle all this so that I can concentrate on development and support, and it is a worthwhile system because of that. If you purchased it from SimMarket I think that, if you go to http://www.simmarket.com and open your account there, you can retrieve your key directly. Regards, Pete

What is it you mean by "data that comes into a CFS2 hosting computer"? Comes in from where? Please check the documentation inside the FSUIPC.ZIP for descriptions of what FSUIPC is and does. It most certainly is not about "controls", that's just an add-on user facility extending the assignment capabilities of FS. FSUIPC is primarily and originally an INTERFACE into the insides of FS. Most everything is about READING data from inside FS, WRITING data to FS is less useful in most circumstances. CFS2 is not explicitly supported, none of the CFS series is, but certainly, FSUIPC does run in CFS2 and, because CFS2 is, internally, something like a cross between FS2000 and FS2002, it does provide access to some of the same data. For details you need the Programmer's guide in the FSUIPC SDK (eee http://www.schiratti.com/dowson). However, I'm not sure this covers your need for "data that comes into a CFS2 hosting computer" -- that sounds like you are talking about something writing to the computer from another? via a Network? If so then you probably want a Network monitor, nothing that runs inside CFS2. Regards, Pete

Well, if switching the alternator switches off the battery, there most certainly IS an error! Else why are we discussing it in the first place? :wink: Anyway, thank you for all the informationI have found it! It is a typo in the code dealing with offset controls: it gets the length wrong! Odd that it hasn't been discovered before! It will be fixed in FSUIPC version 3.30, released tomorrow, I hope. Thanks for your help! Regards, Pete

Sorry, but this is of no interest at all. It contains none of the errors you mentioned, and it is for the Server, not the Client. From what you said it was the Client Log that was interesting, so why post this? Please check back in the thread and see how things were developing, then it might be clear. Also, please use ZIP to zip up log files and attach them. They are very small when Zipped. And please only send files which are relevant. Thank you, Pete

Eranswer? Oh, I see. you started a new thread called "Re:". That's not very meaningful, is it. Could you try to keep in the thread you started, please, so I can understand what's being said. I have to try to keep track of many things at once here and it is difficult without the threading. You see? Thanks. What do you mean, "try to connect GPSout". There is no connection to do. GPSout has no switches, no controls,, nothing. You simply install the DLL into the FS modules folder and it does its thing with no further ado. What "consol switch"? what "Parameters( Altidude / Speed / Position"? Sorry, but you've lost me again. Is this on a separate computer using a separate program and connecting with a null modem serial cable? Please be a little more explicit as to what you are talking about. You other message was talking about some FSUIPC program which presumably you are running on the FS PC. This cannot be anything to do with GPSout. They have nothing to do with each other. You ARE using two computers linked by a null modem serial cable I assume? Else what are you using GPSout for? What are you actually doing? How can I know? You don't tell me anything to make a judgement on. Sorry. Regards, Pete

You mean one operates the other? Can you give more details please, as they seem to work fine here. The two work completely independently every time. It sounds like you perhaps made an error in assignment, and maybe used "Offset Word" instead of "Byte" in the Alternator case? If there is an error I need to fix it before releasing the next update. You seem to have been quite a long time coming back with this detail, and I want to release 3.30 early this coming week if possible. If you cannot explain, please just show me the [buttons] section with the above assigned, and tell me exactly what you see happening when you press each of the two buttons. Use something like the default Cessna so I can try exactly the same here. BTW I am not sure why you are using offsets for these switches. There are standard FS controls for both switches. Theses are listed in FSUIPC as "Toggle Master Battery" and "ToggleMaster Alternator". The alternator switch is even assignable in FS's own controls (it is listed as "Generator / Alternator switch on/off"), but they appear to have forgotten the Battery. FSUIPC does offer an extra control to operate Battery and alternator together, too. BTW I've just tried the Bell Jetranger. The switch on the default panel, when operated by mouse, actually operates both alternator and battery. However, the switch itself is only affected by the Battery control (3102) -- the alternator control (3101) appears to change nothing at all on the panel, and certainly doesn't operate the battery at all. I'm still left wondering what you've been doing that so confuses the issue. The best control for this switch, and one which emulates the Mouse click on the panel switch, is the FSUIPC toggle for both battery and alternator. Please reply soon. I need to freeze FSUIPC soon to get it documented and released. Regards, Pete

Of course, it shows three clients connecting, Client1, Client2 and Client3. That's what it says, that's what it means. The socket numbers you can use to relate those to any error messages later. What is the problem, isn't this part of the log obvious enough? No. Ports and Sockets are not at all related, hence the totally different name! Sockets are allocated by Windows Sockets (WinSock) as needed. The numbers will change each time something connects. You don't control them, you have nothing to do with them. Sorry, I think you can have all that checked automatically by one of PM's programs. You can also get logging from the PM programs to help, but all this should be done with PM's direction. Even I have to ask them if I need help. Katy answers many things in the PM Newsgroup, and she is also a moderator in the FS2004 Forum, here. Regards, Pete

Please, please check the WideFS documentation. You are using IPX/SPX on a mixed network with WinXP on the Server. Only with Win98 (maybe WinMe) does Windows automatically link IPX/SPX clients to servers. As documented, for IPX/SPX you need to specify the Server Node in the WideClient INI file. The node is logged for you in the Server LOG, but you have not used it. Good luck with IPX/SPX on a mixed network. I hope it works for you. I had nothing but trouble with it and now have nothing but TCP/IP installed. Regards, Pete

GPSout does not need FSUIPC and does not need registering. You do not "connect GPSout". Please read the short text documentation which comes with GPSout. I think you are misunderstanding it. I also don't understand why you are talking about GPSout (which connects to another PC via a serial port link) in connection with an FSUIPC reported illegal access. Please clarify. Separate GPSout, which is surely totally irrelevant, and whatever program you are trying to run which uses FSUIPC. The Key LWVQ 7i2V 9GPB is for Squawkbox (see the Freeware Keys list earlier in this Forum). It is nothing to do with GPSout. I've never heard of MovingMapMaster. Sorry. Regards, Pete

I assume when you say "via FSUIPC" you mean programming buttons or keys for those FS controls offered in FSUIPC's drop-down lists? If so, these in general only list those supplied by FS, it is a fuller list than that provided in FS's Options-Controls-Assignments. True, I've added some special ones for FSUIPC. FS simulates the real Bendix-King type radios, in which you do change the standby frequency and swap it into the in-use. (With the NAV radios, if they are set to display the radial in the standby position (a feature not supported by default FS radios), the knobs do then adjust the in-use frequency instead). If, instead, you are talking about programming FSUIPC through its offsets (i.e. interfacing a control program to FS), then you can indeed read and write both standby and in-use frequencies. Why not just remove the standby frequency facility in your choice of aircraft? Look in the Aircraft.CFG file. Find the [Radios] section. In the default FS2004 Lear you will see: [Radios] // Radio Type = availiable, standby frequency, has glide slope Audio.1 = 1 Com.1 = 1, 0 Com.2 = 1, 0 Nav.1 = 1, 0, 1 Nav.2 = 1, 0, 0 Adf.1 = 1 Transponder.1 = 1 Marker.1 = 1 See how the "standby" is defined as 0 in this? Compare it to the Cessna: [Radios] // Radio Type = availiable, standby frequency, has glide slope Audio.1 = 1 Com.1 = 1, 1 Com.2 = 1, 1 Nav.1 = 1, 1, 1 Nav.2 = 1, 1, 0 Adf.1 = 1 Transponder.1 = 1 Marker.1 = 1 Is this for an Airbus? I don't know those, but the ADF frequency IS displayed in PM's Boeing ND if you've selected ADF for one of the sides (L or R) -- each ND can display ADF/VOR1/Off on the left and ADF/VOR2/off on the right as per the EFIS switches. I believe the ADF2 will be (or is already) supported in PM too -- FS2004 supports two ADFs. Regards, Pete

Whatever works best for you -- it depends mostly on the power of the Server PC. With a P4 3.2GHz server I set the lmiiter to 20 or 25 fps for best results. Not so good. Is this often, and during flight? Something is blocking up the network link there. Does the PM network checking program report everything okay? I used to have my MCP on the same PC as the FMS, but I found it was better actually on the FS PC ittself -- saves a lot of Network traffic I think. And don't forget the FMS uses the Network for standard file sharing too -- if it is having any difficulties it may clobber the WideClient traffic too. Otherwise, I would suspect the Network settings or hardware on that PC. Might be best to get advice from the PM folks though. Katy Pluta knows quite a bit about Networks, and there are some hints in the NOTAMS on the PM website. Why the "!!!!!" ? I can't comment on your descriptions of log lines. The number on the very left is the elapsed time in milliseconds. Is that what you mean? Why the astonishment? Are the socket numbers for the socket which the FMS/MCP is connecting to (you willl see the name of the PC on one of the messages)? If so, that is merely the other end of the same problem and also explains why some blocks are missing -- the Server couldn't send them because Windows couldn't reach the client. There is some Network problem there, but what it is I'm afraid I cannot tell. If I've ever had a problem I've used trial and error to fix it -- different PC, different Network Card, reinstalling Network Card, different cable, etc etc. Maybe Katy Pluta in PM support has some ideas, she is very knowledgeable with networks. Regards, Pete

Sounds like the network is not set up well on the CDU PC, or there's a hardware fault (or cable problem?). How far apart are the reconnections? It is still not too late for you to show me a part of the log, you know :wink: . Does that PC ever see any messages from the server? Try switching on some additional logging (the Log= keyworks available are details in the DOC). If this was a ready-assembled and supposedly working FMS from PFC you may want to contact their support and get some advice. Mine has always worked flawlessly. Regards, Pete

In such an arrangement there really should never be a problem at all. Sorry, I don't know. I assume that the Network is 100mbps not 10 mbps? If it is all perfect until you connect the FMS, possibly it is related to attempts by the PM CDU program to access the various common files (NetDir for instance), which it does using the normal Windows file sharing system. There is a check program from PM to make sure all that works properly -- have you run it? For help in this area you will really need to talk to the PM folks. I get rather lost too. Well, they really should not occur, because the times allowed are generous. In that sense they really are errors. But you might expect them occasionally, usually when getting FS busy loading new flights, complex aircraft, or scenery/textures. FS can occasionally cause WideServer to slow down enough for clients to timeout. Have you limited the frame rate in FS, as discussed in the WideFS document? If you let it run free it can make the Server's job too difficult at times. Yes, there weren't even any timeouts and reconnections -- just jerky operation on the PFC. This can be FS frame rates too low, or too high, or, more likely, OpenGL problems. Also having more than one copy of the PFC.EXE running on one PC can cause such problems -- I find I have to set "UserTimer=On" in all but one PFD.ini file else it is intolerable. I think they fight for both OpenGL and WideClient access. I don't think that counts as two monitors from the video driver's point of view, so it shouldn't have any adverse affect. Regards, Pete

If that were so you'd get shifted m (i.e. M) all the time, not the unshifted m. Also keys from the normal keyboard will be shifted too -- all thse keyboard messages go via the same queue in Windows. Do you have the Microsoft spyxx program? If so you can use it to monitor keyboard messages in the main FS window ("FS98MAIN") and see exactly what is happening. But it is not likely to be anything to do with the virtual buttons or WideFS operation -- the programming of keystrokes in FSUIPC is exactly the same no matter what the trigger. What is this "m" or "M" being used for? How are you actually detecting the difference? Regards, Pete

Yes, though apparently it is more so for those of us with Retinitis Pigmentosa, which has been progressively getting worse for the last 10 years. It was that which stopped me flying for real. The eye on which they removed the cataracts first is actually the one with the worst R.P. induced tunnel vision, so it gives me better long sight but very very narrow! :? Ah wellthe date for the other eye has just been confirmed as July 14th (Bastille Day :) ), so not long before I'm hopefully running normally again. Regards, Pete

Well the control acceleration only occurs when there's something (program, Gauge or DLL) continually sending controls to FS, a t a rate fast enough to fool the rather simplistic code inside FS which assumes that, if a control arrives within so many milliseconds of a previous one then it must be the same one again, so it needs to speed it up. Mostly this is caused by some add-on panels which have gauges or modules (DLLs) which send these controls. If it's a DLL it may not matter which aircraft you fly. The fix in FSUIPC is relatively simple. It intercepts ALL controls and if it sees one which is different from the previous one it overwrites the FS timeout which is used to accelerate it. If the control is the same as the last, FSUIPC leaves it be. Regards, Pete

Er, no. Chucking stuff generated by my own logic out to a COM port involves Writes. There are no Reads at all in GPSout. However, that's not the point -- there are no NMEA parsing instructions in GPSout. There are no writes to FSUIPC. None of the code in GPSout is applicable except possibly the opening and closing of the COM port (as a file). You'll find COM port I/O easy enough. It's handled in Windows just like a file. You open it, read it, close it. There are extra bits for setting port properties and so on but they're easy to look up! I don't remember this stuff, I look it up as I go along in any case! Regards, Pete

I take it that you are programming the button normally, in FSUIPC's Joystick page? Of course, there is absolutely no difference in that whether the button is local to FS or via WideFS, or whether it's a "virtual" button or a real one. So the question is, are you losing Shift events on your FS PC when using something local too? All FSUIPC does is use the Windows SendInput API to send the programmed sequence to FS. What triggers it to do this is completely irrelevant. The SendInput API generates the standard WM_KEYDOWN/KEYUP sequences. You can, of course, also send those yourself, from your program, using the facilities in offsets 3200-320B inclusive. What are you trying to do, BTW? Keyboard simulation is not the ideal and most precise way to control things normally. Regards, Pete

No, sorry. Personally, I don't see the point of using FS as a moving map when there are much better and more accurate map programs which run faster and smoother. However, others have already mentioned this (see several threads here on the subject), so I expect there are some developments along those lines in progress somewhere. It's an application that any programmer can provide, but it isn't really of much interest to me -- I provide the tools, like FSUIPC, which make it possible. GPSout was written many years ago (FS95 time, way before FSUIPC and WideFS) for my own amusement specifically to provide a moving map for FS. Ah, I see. I expect that reading the output from a GPS and using it to inject positional data into FS would be a relatively trivial program for you to knock up then. You could make it very specific to the particular GPS you will be using, so cutting down the work needed for a full NMEA parser quite significantly. Regards, Pete

What exactly is the PrecisionFC CDU? Is this the separate PFC hardware CDU built with its own PC inside (I have one of those) and running PM's CDU, or something entirely different? Errrors logged in the Server Log and/or the Client Log, or what? I cannot see them from here, perhaps you'd like to show me an extract? It does sound like you may have too much running on the one Client. What processor is it? If it is the PM CDU you are running, on the same PC, then it doesn't indicate an OpenGL problem particularly because I don't think the CDU uses OpenGL. But this sort of thing needs checking with the PM folks. If you are running all of the PM components on one slow processor I would thing another (cheap) PC would be a better bet. As I said, I don't think the CDU needs a particularly good video card. Are you perhaps running with 2 or more separate monitors on the one PC. If so, then it may be the loss of hardware acceleration for OpenGL which is doing it. In that case, possibly later drivers or a new video card may help. But I am the wrong person to help here -- you need some of the PM expertise you will find in the PM Newsgroup. Regards, Pete

Yes, it does actually explain the number of connections business, as follows (5th para under "Running WideFS"): However, if you get this often then you are having some problems. First, please make sure you are using the latest version -- 6.23. If you still get this symptom, check the Log files (WideServer.LOG and WideClient.LOG) -- show bits to me if you want some diagnosis. Regards, Pete