Pete Dowson

I'm not saying you are in error READING the value, only in interpreting it. It is no use showing me examples of VB.anything, I'm afraid. If your code is in error I hope someone who uses this language can jump in and help you. But I am not he, sorry. You are therefore not understanding what "BCD" means. 120.60 is represented in BCD by 0x2060 which is decimal 8288. so when you read 8288 this is correct for a frequency of 120.60. What can be more obvious than this? You already just proved it to yourself!! Please use FSInterrogate where you can see the values read in all sorts of formats, all at once! Then maybe you will understand? If you get 8288 in decimal as you say, this IS the BCD (Binary-Coded-Decimal) version of 2060 as in hex it is 0x2060, as you already so clearly pointed out! Why are you asking HOW to "get the BCD" when you've "got it"????? Pete

Okay, that sounds fine. These are in the [user] section of the appropriate WideClient.ini file, as documented? No, that seems to be correct. At least it works fine with all the versions of RW I've tested it with. I cannot guarantee it will always work with every version, as the author seems to change the Registered message names used for PTT sometimes. No, not at all. There's your error. You have the parameters in the wrong section. Pete

If it is only WideClient (NOT FS and the Server part) you want to run on NT4, then just possibly the attached version of WideClient (5.53) will do the job. I've provided an option to bypass the use of ToolHelp (it was only being used to log the names of Client programs). Just edit the INI file, adding "IdentifyClients=No" to the [user] section. I cannot say for sure whether it will then work -- maybe other things will conspire to stop it. Let me know. Pete WideClient553.zip

Yes. It is called "Flaps Set". No, it appears there is not. Pete

Thanks. I'll forward your message to the author. I had assumed he'd tested it, so this is a bit odd. I know nothing about VB or .Net so I don't just want to change it myself. Pete

My Latin is a bit rusty, but if you mean has anyone tried all the possible FS controls listed in CONTROLS.DLL (which is where FSUIPC gets them) and reported on the results, then the answer is no. Do you want to volunteer for this? It is rather odd to find that these are mapped so oddly inside FS. But I think you'll find that the plain "COM RADIO ..." (i.e. not the Standby) controls do actually operate the Standby. It is not surprising that MS did not bring all these controls through to the user interface for assignment in their own dialogues! You definitely have some errors in your code then. 120.07 would be encoded as 0x2007 which is 8199 in decimal. You cannot get 6567 from any BCD encoding as this is 0x19A7 and the digit "A" has no place in BCD. Just think of BCD as having 4 bits per digit. i.e. 0x2007 is, bit by bit: 0 0 1 0 0 0 0 0 0 0 0 0 0 1 1 1 If you AND the value with 15 (1 1 1 1 in binary) you'll get the last digit as a number (7) in this case. Add the character '0' to this and you get the character '7' for display. Repeated shift down by 4 bits and do the same again and you get the correct characters for the other three. Insert the decimal point and add the leading '1' and you are there. This BCD method of encoding frequencies in FS has been the same now for many many years and there are plenty of applications using it with no problems. Stop thinking numerically, think of it as merely packing characters into smaller spaces, and just unpack it as I suggest. No, there's no shortcuts if you want to increment and decrement BCD. And remember that many of the frequencies are invalid. The last digit can only be 0, 2, 5, or 7. These represent 0.000, 0.025 0.050 and 0.075 so if you want to do it numerically you would have to convert something like 0x2007 to decimal 20070 then increment by 25 and convert back again, ignoring the last digit (0 or 5). To convert 0x2007 to decimal 20070 you'd take the value of the top 4 bits (2) and multiply by 10000 then the next 4 and multiply by 1000 and add, and so on. Vice versa converting back -- you use division, on the remainders each time. Pete

No, sorry. You need Win2000 or Win98, or later. Pete

Well certainly all those things are programmable. I really would have no idea about graphics overlays, but I presume that could be done by some sort of scenery design. Sorry, it isn't my subject. You might want to get hold of one of the official scenery design SDKs, or perhaps a scenery design package, and see if it is possible. You are probably right. I don't think there's anything which records sequences of keystrokes or buttons for FS. I supposed you could design a panel with such an arrangement. Apart from the "W" option you have 9 possible panels selectable by Shift+1 to 9. So the PANEL.CFG file could define different gauges, in different places, for each such selection. That's easy to do -- PANEL.CFG files are only text files. You can edit them yourself. But be aware that each gauge needs a bitmap to sit on (but it can be a blank bitmap). Again, there are some panel design programs that could help you. Pete

There is a stall warning horn implemented in most (all?) of the FS aircraft. No. VASI and PAPI, etc, are purely visual. If you can't see them properly you should be doing an instrument approach, not a visual one, or seeking an alternate airport if you are not Instrument Rated. Depends on what the failures are I should think -- and anyway not many things are repairable in flight. Emergency procedures usually involve using alternative methods or instruments, and so on, not performing actual running repairs. There's not normally enough time to repair anything even if the diagnosis was easy. The priority is to fly the plane. There is a flight recorder (black box) application. "FltRec" I think it is called. You can probably get it on several FS download sites. I don't know exactly what it records I'm afraid. Pete

Hmmm. Very strange. Everything else looks right now. so now I've really no idea what Windows can mean by "Socket type not supported". Windows documentation says "The support for the specified socket type does not exist in this address family. For example, the optional type SOCK_RAW might be selected in a socket call, and the implementation does not support SOCK_RAW sockets at all. " The "socket type" I am asking for in WideFS is SOCK_SEQPACKET. Now this was new to Winsock Version 2, but Winsock 2 was most definitely introduced with Windows 98 (and possibly 95 SR2, but I cannot remember -- it wasn't part of the original Windows 95, I know). So the only conclusion I can draw is that your Win98SE installation is in error, possibly corrupted or changed by something else that's been installed. Try running the System File Checker (SFC, accessible through System Information I think). Maybe re-installing Win98SE over the top will recover it. But first of all, in case it is down to your NIC driver, try re-installing the NIC itself -- delete it from the Windows System-Device Manager list, then re-booting and re-installing its driver(s). I really can't think of anything else. sorry. Pete

Well I suppose a program interfacing to multiplayer could do that. It isn't an area I know anything about I'm afraid. Perhaps someone who has actually used, and, better, programmed, MP could jump in here. [Jose, are you here?] Regards, Pete

FSUIPC has options to prevent turbulence, in clouds or in clear air (winds section), or to induce random turbulence. Be warned that with either form of turbulence enabled you will get poor frame rates in areas of denser AI traffic, so you may want to turn them down. All this stuff is covered in the FSUIPC User Guide, and it should be easy enough for you to find the options in FSUIPC's options (look for the word "turbulence" in the Wind and Cloud pages). I expect FSMeteo has options for some things too. Have you looked? Pete

You say you are using WideFS 5.50, but the WideClient LOG shows otherwise: You should use the matching WideClient which was inlcuded in the WideFS 5.50 package. The above error message most certainly shows that WideClient is trying to use a protocol you've not installed. You do not show your WideClient.ini file, but the default protocol bfore version 5.50 was IPX/SPX, so that could be the reason. For TCP/IP you will also need to provide the ServerName in the Client INI files, of course. Pete

Yes, there's no use for the parameters in those two controls. If you wanted a button to set, say 50% spoiler deployment then you'd use the Spoilers Set control with a parameter like 8192 (maybe -- I can't remember off-hand whether the spoiler runs from 0 to 16383 or to 32767, or neither). Mostly, when using a control with parameters, it's a matter of experimentation. Pete

All of the "AXIS ..." and "... SET" controls for FS use a parameter too -- for Axis controls it would be the value of the joystick input, and so on. the example given in the FSUIPC documentation for the KOHLSMAN_SET control shows the parameter being used to set the value for an Altimer setting of 1013.2 mb (29.92"). For FLAPS SET you'd work out what parameter values you need to enter for specific flap settings (this would vary according to the number of detentes). And so on. If you are not using any of the controls which accept a parameter then it is irrelevant. Do not worry about it. Pete

Hmm. I don't know it, maybe Chris will chip in here, but you'll need to check its "cycle" time and what your code is doing to find out where those extra seconds are coming from. Certainly WideFS will be easily capable of sending updated values at rates similar to FS frame rates -- in fact you can get the WideClient frame rate displayed in its title bar -- there's an option for that in the INI. Check the dox. Project Magenta would be out of business if its instrumentation was several seconds out rather than pretty well instantaneous, and its Autopilot, running on a separate PC, would lose control in no time! Regards, Pete

That's exactly what Lago's "FSAssist" did for you, automatically, in FS2000 -- it had different settings you could adjust for different modes of flight -- taxi, takeoff, climb, cruise, descent, landing. That sort of thing. For some reason in the FS2002 version they only monitor these settings and allow manual adjustment by hotkey. I don't know why the automatic adjustment was removed. Possibly because FS stops and reloads textures et cetera when some of the settings are changed? I really don't have a clue where in FS they get these parameters nor how they adjust them. Maybe one day I will have time to do some research and find out, but if FSAssist is also provided for FS2004 I would not want to undermine their product in any case. This is precisely what the Graduated Visibility option in FSUIPC is for. You don't need to reduce the "maximum" only the actual setting, which is what FSUIPC does. Regards, Pete

What are you using to get such a delay? If this is with WideFS, there's something strange going on in your code -- there are many folks using cockpits powered by Project Magenta, using WideFS with multiple clients, and the PFD/AI/ND et cetera run at the same frame rate as FS. In fact since version 5 that's exactly what WideFS is designed to do -- send every Client updates at the FS frame rate. The latency is just a few milliseconds. Pete

Yeah, I downloaded it to check and it is definitely faulty on the Schiratti site. I did this immediately after replying to you and then immediately wrote to Enrico to tell him, but I assume he's out for the day/weekend with his family. Did you write? All my modules also go to Avsim, the PFC site itself (flypfc), and a load of others -- about 50 places altogether, all by request. Now some of those are software developers or magazines, not web-sites hosting files, but I don't know which are which without asking them. And I think many of the sites now either only post up selected modules (possibly only FSUIPC) or simply link back to Enrico's. I can email it to you direct if you have no joy soon -- I did try attaching it here, but there seems to be a limit of 125kb on attachments so it wasn't accepted. Sorry. Pete

Not when it left here to over 50 sites, via my normal distribution method. The ZIP is 1.2 Mb or so. If you have problems downloading from any site you need to check with them. It may well be your caching not the site at all. I can't do anything myself, I have no web site. Pete

Not that I know of. Only one of the PCs can actually be simulating the flight, so all the control inputs (rudder/elevator/aileron/throttle etc) have to be input to that PC. I did do a facility to link multiple ISA Epic Cards across a LAN, and you could have duplicate inputs that way. But it isn't terribly good because of the Network latency - ok for airliners perhaps, certainly not for aerobats and fighters. If your pilots are both actually in the same room, sitting next to each other as in a real aircraft, then all you are really talking about is dual controls. that can most certainly be done -- FSUIPC provides multiple axis input facilites (see the Advanced Users guide). But you are then talking about one FS simulating PC again --- if you want a nice wide view then consider projection or use a Parhelia with three large screens configured as one wide one. You could use WidevieW and separate PCs, but your control inputs still all need to be directed to the serving PC, the one actually simulating the flight. Hope this helps. Pete

It's the "/2" at the end of the Reverser= line in the [JoystickCalibration] section. Just delete the "/"2". Good catch by the way -- the inability to remove it in the Options page is a definite bug. It'll be fixed in the next version of FSUIPC. No one else has mentioned it! Regards, Pete

Ahsorry. I forgot completely about that special facility. Yes, you are right. It doesn't work now because, since about version 5 of WideFS I had to make WideServer's main message processing 'window' (an invisible one) a "top level" window rather than one within FS's enclave. I clean forgot that PFC sends messages to the Window and now it can't find it. I'm releasing an Interim version of PFC.DLL (1.53) with this fixed. The DLL now tries to find WideSever wherever it may be hiding! I've checked this here with RW on a Client and it works fine. Please take a look on the Schiratti site in a few hours or so. Thanks for the good "catch"! Pete

How are you configuring it? Are you assigning KeySends in the FSUIPC Buttons options pages, as described in the FSUIPC documentation, or doing it the older way, assigning the KeySends in the WideServer.ini? What settings have you got and do they match those you allocated in the WideClient.ini for "RWon" and "RWoff". Please cross-refer to the documentation which should be clear about all these, right down to the examples I added. WideServer does NOT send any button presses to clients. The KeySend mechanism is a way of sending allocated signals within the normal data distributed to clients. If your Client is receiving stuff for your applications it will receive KeySend parameters too as they are merely parts of the same data. It sounds like you simply have not defined matching KeySend numbers to operate RW. Pete

Sorry, you need to be more specific. What "client boxes" are these? Are you talking about WideFS and reading weather at the clients? The weather data distributed to clients by WideServer is the same as in FS, as you can see by running WeatherSet on the clients. How are you clearing the weather? There's a hot key assignable in FSUIPC's options which may be easier than going into the FS options, but they eventually amount to the same thing. If you are instead talking about mutliple FS installations linked by WidevieW, then this is a question for Luciano Napolitano, author of WidevieW. He has a website I think. Regards, Pete Dowson