Pete Dowson

Sorry, you either need to upgrade to the current FSUIPC so you can override the PFC action with FSUIPC button programming, or somehow get inside the PFC device and stop it sending that switch value. I don't know if disconnecting its wires will help -- I doubt it very much. It will be a function of the firmware. Regards, Pete

Sorry, I don't quite follow. Are you saying that you crash because PM goes wrong and that PM goes wrong because you crash? I thought earlier (and on the PM newsgroup) you were saying that PM goes wrong after you crash, not before? As I thought I've explained before, I have no idea how it is even remotely possible for there to be a delay! Either PM is responding within milliseconds or it is stopped or hung or jerky. I cannot imagine any way possible for it to be running perfectly smoothly and nicely but in a completely different time frame to you. This is really something you have to discuss in much more detail with the PM team, because I'm sure it must be a completely unique thing and they would be astounded. Okay, so it isn't hardware and it apparently isn't software? So the only other thing left is your interpretation of what is happening, isn't it? If, after crashing, you restart things like the MCP, setting up a flight from an airport again and so on, isn't everything then working? I simply cannot imagine how you are trying to continue with glass cockpit operations after a crash. So, the Network was blocked? Or the PM program was hung? Both possibilities exist there. Not sure what you are saying here, sorry. You seem to be saying your aircraft descended from 500 feet to-50 feet? (Where in the world were you flying for the ground to be so low?). The problem may be more that none of us can figure out exactly what you think is wrong. Sorry. What new settings? The only thing I suggested you could try was Timeout=0, but that is trivial. It simply allows more time for the applications and less time for the Network. Perhaps once we understand the problem in more clarity things will be easier, but I am just getting more confused each time at present. I thought you said that, and it sounds so impossible to me that it is even nearly a miracle! Maybe, it is, as Jonathan suggests, somehow getting into "demo" mode, but in all the years I've been using PM I've never ever seen it do that. For me the ONLY time it ever enters demo mode is if it is started without Wideclient started first -- it doesn't even need FS to be running to operate normally. Of course, I am only ever using the Boeing software. I've never tried the Airbus stuff. Maybe that is entirely different, but certainly, for this aspect of your questions you do need to sort it with the PM folks. Unfortunately I think that both Katy and Enrico are away on visits and left poor Jonathan to fend for himself, so their response times may be rather slow. Regards, Pete

It isn't part of the definition of the aircraft, it is the state of the Flight you load. To change it simply shut down your engines, do whatever you want to set the aircraft as you want it to start, and save the flight, marking it as the default. All versions of FS as far back as I can remember have worked like this. You can have things started almost however you want, but you have to save them that way. Regards, Pete

Sorry, I don't deal with any of that. If you've paid for registration you should get an email with the key(s). SimMarket do this within 24 hours. I though Mr. Schiratti only did this for Project Magenta customers, but, either way, he is away in Sacramento at present so there may be a delay. Regards, Pete

Please understand that I see and answer many messages not only here but also in email and on some Newsgroups -- including the PM one in fact. I also develop and test not only WideFS and FSUIPC but several other modules. I cannot tie such things together as easy as you seem to expect. It is better, please, to keep things in threads so that the questions and answers develop rather than start over again every time. Looking back at the last things you said in your other thread: I said (and I still maintain) that this is not possible. Your observations need to be much more specific. I see Jonathan says he suspected that PM was reverting to "demo" mode, but I don't think that happens either. On my setup, for example, I can close down and switch off the Server, and the GC computer is just sat there, with the GC displays as they last were from my FS flight. If I then switch the Server back on and load up FS, after a short time they all come to life again. But I see no way for them to be alive when FS is not running. You also said: Did you try your other computer yet? You've not informed us about it. Finally, here is something I didn't notice before: ... and I think you were also saying something about crashing the aircraft (three times in a row? :?) in the PM Newsgroup. [I did, I think, manage to identify you in there -- from your initials, not from your non-dde-plume here! I never understood why normal folks need to hide their identity in Forums]. If your problems are only ever occurring after you do something like crash or pause for long periods in mid-flight or reload a flight and so on, then I think this is where you may be expecting too much from the current PM software. Certainly after a crash, or any reset type operation, the PM software will lose track. It is best not to crash, and to try to fly everything in real time. Rather than pause to go make a cup of tea let the A/P take over for a short time. That's what it is all about -- "as real as it gets". If you crash a real aircraft I don't think you expect a lot of the glass cockpit to be of use in continuing the flight! :wink: Perhaps in your reports to PM support you could emphasise this point, that things only go wrong when you have crashed or done something else quite extreme with FS. I doubt whether the complex cockpit programming in PM is designed to cope with any of that, at least at present. There are so many more important things for it to do yet for normal flight without recovering from FS extremes. If you do crash I think you go have a cup of coffer and come back and start again, not try to continue. Certainly the CDU will need its data clearing and plan re-cycling. Anyway, ask PM support for their opinion of this particular point. And try not to crash so often, eh? :) Regards, Pete

Sorry to see you getting no replies. I had hoped some VB programmer would help. I'm no good with VB at all. However, I do know there is a special FSUIPC call invented for writing strings to FSUIPC in VB -- FSUIPC_WriteS. I think this gets around the problem of needing a string pointer ("by reference" instead of "by value"). Isn't that enough to know? What exactly is it you don't understand? As it says in the programmer's guide, you write the string to 3380 (maximum length 128 characters including a zero terminator), and then write a 16-bit (2 byte) value to 32FA to make FSUIPC display it for you. You can do both Write calls (a WriteS then an ordinary Write) before a single FSUIPC_Process call to transfer the stuff to FSUIPC. Regards, Pete

Nothing. they are all defaulted except the Button scan one, which you can let default anyway if you've already tried that. What is the actual problem you are trying to solve anyway? Sorry if I should know this, but you started a new thread for this and I'm not sure how any of this relates to anything. It would possibly make more sense if I knew what went on before. Just some minor comments on the INI files, mainly for your clarification: ============ In the Client, there is no point having both ServerIPAdress=192.168.2.104 ServerName=sys001 If the IP address is provided, the name isn't used. If only the name is given, WideClient asks Windows for the IP address, so it gets there either way. ============ Also in the Client INI, sometimes you get better results with Timeout=0 instead of the default. This is the section in the WideFS DOC: ============ In the Server.INI, these lines are not valid, they are unused. There Server doesn't need to know where the Server is. ServerIPAdress=192.168.2.104 ServerName=sys001 ============ and, using this: RestartTime=10 is fine provided you are using WideServer version 6.23. In earlier versions it is better as 0 (a work around for a bug fixed in 6.23). Not sure what you mean, sorry. Regards, Pete

As supplied. It has been tuned over a long period to run best with PM. That's what I use. What new options? The only possibility I can think of is that you have some odd joystick driver which is making the polling in Wideclient (added in 6.22) go wrong. This has occurred in one case I know of so far. Otherwise there have been no significant new options in WideFS for years. Try switching off the button polling by adding: ButtonScanInterval=0 in the [Config] section of the WideClient.ini file. Regards, Pete

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