Pete Dowson

The lights are indicators of something. You need to detect the condition which makes them light. Apart from "emergency battery" which I don't think is simulated in FS, you can find values providing the amounts of all these things. If the warning lights are to operate when the levels go below (or above) a given limit, that's what you'll need to check. Regards Pete

Ha ha. It would be if it worked literally like that, but it doesn't. ;-) Reading and writing are two different operations and actually use different buffers in any case. The illusion that FSUIPC provides access to a memory space with those offsets is confusing you a little in this case. It is only an illusion. writes to 3380 over the IPC interface actually get sent to FS's display routine, not to FSUIPC's memory. This is why you'd need AdvDisplay running to intercept them and put them into FSUIPC's memory, where you can actually read them "at 3380". Offsets in FSUIPC are really "tokens" identifying variables rather than truly offsets. They started out as offsets in FS95 and FS98 days. The illusion is maintained for compatibility. Texts intercepted by AdvDisplay and placed in 3380 behave identically to the displays they are meant to show -- ie. they stay for the number of seconds specified, or scroll off to the left one character at a time, or stay till the next message arrives. Just like the display itself. It will be reading it quite frequently, looking for changes, yes. When used across WideFS this is no load really as WideServer only sends out changes. You have to hook a particular procedure in FS. It is in a different module and in a different place for each version of FS. If you know how to hook FS procedures I can tell you which they are. Hmmm. Possibly. Regards, Pete

Yes. You need to run AdvDisplay to trap the messages and route them to FSUIPC's offsets. As an example, the freeware program "Showtext" provided in the AdvDisplay package does exactly what you are asking. This is actually documented in the description of offset 3380 in the FSUIPC SDK's Programmer's guide. Note that Advdisplay doesn't monitor such messages, it actively diverts them, so if you wanted them visible too you'd need to display them yourself, or use AdvDisplay's window or ShowText. Regards Pete

All assignments are currently handled by FS, not FSUIPC -- go to Options-Controls-Assignments. I think you will find that all those axes are assignable there, with multiple devices (there's a drop-down to select the device for each set of assignments). I am currently working on facilities in FSUIPC for assigning axes directly, without involving FS. Hopefully I will be releasing a Beta version here later this month. Regards Pete

I'm afraid I don't understand. "Text of any resouce" -- displayed in FS? How, where? Where do they appear? FSUIPC/AdvDisplay is only able to grab texts sent to the standard FS message line, the same one used for FS's own ATIS messages. Regards, Pete

Most really great add-ons for FS2000 did also work fine in FS2002, and even some in FS2004. I can reproduce the odd crash when the menu is hidden, but I could not find the reason. It is hidden too deep in low levels of FS's use of DirectX. I suspect it is something forgotten in FS over newer generations of DirectX and Windows. I cannot make the same problem occur when the menu is not hidden, so I am sorry, I do not know of any way to help, except by registering in FS2002 or FS2004 on the same PC, and copying over the FSUIPC.KEY file to FS2000. How did it fail? There's no sign of failure in the log. Only S-Combo being started three times. I am fairly sure there are some extra steps you need to take to make S-Combo work via WideFS -- you will need to contact the author I think. Sorry, I don't know. This is purely an application thing. I don't know why they would "point to" an FS installation. Doesn't S-Combo come with any documentation for use on WideFS? If that is the case, you would have to point them to the copy of FS you are actually using -- i.e. the Network path to FS on the Server. Make sure that the FS folder is set for sharing on the Network. I think all those run fine on a client, but, yes, I think they do need to know the path to FS -- possibly excepting Radar Contact. I don't really know S-Combo, but Flight Keeper needs to generate its database from FS files. I'm reasonably sure there are instructions for all this in the individual program's documentations or websites. None of this is really related to things I know, where WideFS is reproducing the FSUIPC interface for them to use. All the other stuff is specific to programs which need access to FS files, often the scenery installed. Regards, Pete

Not pressure as such, but the relative amount of application (relative to full pressure) is available in the control offsets -- 0BC4 and 0BC6. Unfortunately these don't operate for autobraking. Regards, Pete

What sort of explanation is really needed? The format of the frequencies is explained in the Programmer's guide. They are all simple 16 bit words -- i.e. type "unsigned short" both in C and C++. Read then into such (length 2). They are in binary-coded decimal, which simply means that each group of 4 bits represents one decimal digit. For display it is easiest to simply convert them to hex character form, using the printf "%X" facility. For instance, if the frequency is actually 112.75 the value you get, in hex, is 0x1275 (the 100 digit is assumed). To print that you'd simply do a printf with "1%02X.%02X" (to put the decimal point in correctly), with parameters (val >> 8) and (val & 0xff). None of this is complex programming, just basic C. (I don't know C++, sorry). If you can say why you cannot understand then maybe I can see what is wrong with the documentation, but having someone do the code for you doesn't help anyone in the long term. Regards, Pete

Windows Help and documentation. If both PCs are running Windows XP, then it should be pretty easy. I wouldn't be able to tutor anyone on Netwroks as I know little, I just let Windows do what it needs to do. The only thing you may need to do for WideFS is to turn the Windows XP firewall off, or at least do something to let WideClient (on the client PC) talk to WideServer (on the FS PC). But this applies equally to any program using the Network for anything. An Ethernet twisted cable for Ethernet connection, or a USB 2.0 cable if you want to connect via USB, or a Firewire cable if you want to connect using Firewire (IEEE 1394). I think links also work with serail and parallel cables, but avoid those as it will be clunky and too slow. Windows supports many ways of linking PCs. Doesn't matter. WideClient doesn't need much installing in any case. Depends if you want FS to download things from the Internet too. Whichever it is connected to, Windows can share it over the Network in any case. See Windows help. It would really be better (safer too, from attacks over the Internet) to replace your modem with a modem/router, and connect both PCs to that. Then both PCs have Internet access even if the other is switched off. Ethernet links are best for this. That's because it isn't either WideFS's nor FSUIPC's business to make Networks work. That's all in the realms of Windows. Look in your local bookshop. There are hundreds of books about this -- you surely don't really think that every program which uses a working Network should tell you about Networks? It just really isn't feasible, even if I knew it all, which I most certainly don't. Please, get your Network working as per Micrsoft instructions, then and only then buy and install WideFs. Regards, Pete

If you have a valid registration for FSUIPC 3 or WideFS 6 then it is valid for the life of FSUIPC 3 or WideFS 6. Sounds like you've moved to a different PC, or reinstalled Windows or FS? You'll need to re-register in FSUIPC with the exact same details as originally. Regards, Pete

Check your arithmetic. P = 37, following W? I think not. Try 27. Likewise 29 for R. Also you don't need to multiply the last result by 38 as there is no more to follow. 34 x 38 = 1292, +20 = 1312, x 38 = 49856 + 27 = 49883, x 38 = 1895554, + 29 = 1895583. 1895583 in hex is 1CEC9F, shift left 5 (x 32) = 039D93E0 You say you found 039D93E1, but obviously the '1' at the end comes from something else as it cannot result from a shift left of 5 bits. As your extract says "Bits 0 .. 4 of the resulting DWORD are frequently used for other purposes." Regards, Pete

I'm afraid I know of no other way but to take the Latitude and Longitude and find the nearest airport from a database. There should be an easier way, for sure, but if there is I've never found it. A value for this was added in version 3.53 of FSUIPC, as listed in the History document (and above, in the details of recent releases. Here's the relevant entry: Note that this is metres per second x 256. You will need to convert it for feet per minute. (x 3.28084 x 60 / 256) Regards Pete

Only the lower 17 bits constitute the FS control number. X1041B is decimal 66587 which is listed as "ROTOR_BRAKE" in my FS controls list (packaged with FSUIPC.ZIP). Control 71023 is certainly outside the range of FS controls known to FS's own CONTROLS.DLL, which is why it is logged as "unknown". I don't know what panel you are using, but it may be an internal addition used only by specific code. There are also probably losts of WM_COMMANDs which are nothing to do with the assignable FS controls. FS controls are not always posted or sent as Windows messages. FSUIPC itself sends most of them directly to the SIM1.DLL module using the "SendEvent" call it supports. I expect many panels do the same. You cannot discover everything internal to a program via Spy because that is only able to see Windows messages. By hooking the controls calls, a facility offered to modules and gauges for just such a purpose. Check the FS panels SDK. Regards, Pete

Not at present, as the assignment of functions to your levers is done in FS, not in FSUIPC. But I am currently working on facilities in FSUIPC to make assignments completely independently of FS. Such facilities have been on my "list of things to do" for some time, but have only just reached the top. They will certainly be able to be set as "aircraft specific". With the new facilities you will actually be able to switch FS's joystick facilities off altogether and use only FSUIPC to assign axes and buttons, and do the calibrations, and all of this can be for all aircraft or be specific for each individual aircraft or group of similarly named aircraft. I hope to provide a test version of FSUIPC with these facilities, for general Beta testing via this forum, within the month of February, so keep an eye on the top announcements here. Regards, Pete

I fully agree, if you were doing so -- which I didn't say. But unfortunately that's the way it reads. Hence the word "seems". I have to somehow get folks to read what is written rather than what they think should be written. How many ways can I emphasise "forget WidefS and the Network, interface to FSUIPC"? Maybe much bigger fonts in red? Regards, Pete

I don't know FSHost or Ventrilo I'm afraid. There are, I know, on-line flyers who have Squawkbox running on a client PC, talking to FS on the other via both multiplayer and WideFS (multiplayer for other users aircraft, WideFS for the FSUIPC connection for weather and user aircraft radar reporting). FSUIPC and WideFS are only of use to programs using the FSUIPC interface. Whether yours do or not I don't know. Regards Pete

Okay. So FORGET WideFS for now. That is where you are totally confused. You do NOT interface to FS through WideFS but through the FSUIPC interface. For that you need the FSUIPC SDK. Do NOT mess about with ports and TCP/IP or anything like that. All that will be handled for you by WideFS WHEN AND ONLY WHEN YOU HAVE A PROGRAM INTERFACING TO FSUIPC! No, absolutely not. You will NEVER get that working. Go download the FSUIPC SDK. Forget WideFS. You obviously totally misunderstand the whole concept. WideFS just provides a Networked copy of the FSUIPC interface. It is that you need to deal with. Do not use TCP or anything to do with the Network. That is handled by WideFS. Write your program to talk to FSUIPC, following the examples provided in the SDK. If you want to do your own Network linking program, that's fine, but it is absolutely nothing to do with either WideFS or FSUIPC. That's all your own affair. You'd have to do both client and server ends of your own link. That's not relevant to anything of mine. It is NOT only "the intention". It is what is implemented, and it has been so since FS98 days. It is well established and heavily used. WideClient "pretends" to be FS running FSUIPC. Any program written to interface to FSUIPC will run okay on the FS PC without WideFS even installed, or on the Client via WideFS. The interface is reproduced exactly. That's all you need to use. No network stuff at all. Of course not. It responds only to the WideFS protocol, which is not published and which will not be. Please FORGET the Network, write to the FSUIPC interface only. I'm sorry, but this is getting no where. If you insist in talking about TCP streaming and so on then you may as well continue talking to yourself. I cannot help you. You seem to be deliberately misinterpreting me. IGNORE NETWORKS, IGNORE WIDEFS, use the FSUIPC SDK and interface to FSUIPC, like hundreds of other programmers have done before very successfully. Pete

Odd that you make no mention of having installed he MixW pair of virtual serial ports on the laptop? There's absolutely no way that the same COM port can be used by two programs simultaneously -- only one program can get a single serial port at a time. There has to be two ports, one for WideClient to send the data on and the other for your map program to read the data from. Normally these would have to be real ports with a cable linking the two, but the MixW program I provided does this by "pretend" ports ("virtual" ports) and links them by software. Please read the GPSout and WideClient documentation through again. It really looks as if you've skipped some important points. Regards, Pete

FSUIPC doesn't have any such message. WideServer does. Where's the log? What's a "Blitz3D basic"? Sorry, no. I really have no idea what program you are using nor what "point it at the right port" means? Doing what? This is getting thoroughly confusing. If you run WideServer in FS, just run Wideclient on the client PCs. You then run FSUIPC applications on the clients. Let WideFS deal with the Network stuff. What are you trying to do with it? What "linking business"? We seem to be talking different languages here. If you want to use WideFS please check the documentation. It is all explained there how to use it correctly. There is a library for FSUIPC, of course, it is part of the FSUIPC SDK. If you want to interface to FSUIPC you need the FSUIPC SDK. There are sections in the SDK for several languages, including Basic. Have you looked? Please just download the SDK and check the documentation. It sounds like you are starting from completely the wrong end of things. Ignore WideFS, write to interface to FSUIPC. WideFS is just a way of interfacing to FSUIPC across a Network. Regards, Pete

If the "dock" option is grayed then all that means is there is no cockpit panel part for it to dock to. The INI relates to the Locking, not Docking. There was no need to "RAR" the file and upload it for downloading. it is only a few lines long, look: [AdvDisplay] Window=1290,382,324,188,1,1 Enabled=Yes PositionLocked=Yes HideWindow=No AutoHide=No AlsoATIS=Yes MultiLineOnly=No Scroll=Normal There's nothing wrong with that, so I think you are seeing another symptom of how FS2004 misbehaves in full screen mode on multiple monitors. Pete

Well, FSUIPC doesn't care about the Internet, and FS9 will only "trigger" a restart if it detects a serious error -- and even then you should first get the error report with the "restart FS" option. Okay. But it might be worthwhile trying the No-CD crack for the FS9.EXE file in any case. I have grave suspicions over interactions between what it does to protect MS's copyrights and what Internet and Anti-Virus related routines do to protect your system. In general most game programs advise disabling virus checking whilst using them. Regards, Pete

No, not when "Locked", only when "Docked". I must admit I don't know about Virtual Cockpits. They didn't exist when AdvDisp was designed. What you say does happen, at least on the main monitor, when the window is Docked to a panel part. The Lock facility is not related to panel parts at all. The window should simply stay locked in position. It is never hidden of its own accord when locked. If it disappears it sounds like the way FS is handling the display is causing the Z-order to become messed up. The details for "Locking" are saved in the AdvDisp INI file, those for Docking are panel-dependent and saved in the aircraft's Panel.CFG file in the [AdvDisp] section. You can check that to see what it is docked to. It seems there may be some second monitor arrangements in full screen mode which cause some problems. I wonder if this is all related to the problems I've seen with FS2004 on two monitors in any case. On my nVidia two-monitor set up, having FS2004 in full screen mode makes it almost impossible to have a panel set up which is remembered from one aircraft load to the next, let alone across reloads of FS. I think others have complained about this FS bug as well. It used to all work fine in FS2002 and FS2000. I hope this sort of thing will be resolved in FSX. Meanwhile, possibly swapping the use of the two monitors over might help? If the main one is to the right, the coordinates for the left probably go negative which may just be one cause of problems. If you are using Lock instead of Dock perhaps you could show me the AdvDisplay.ini file so we can see the saved position? For Dock you'd need to find the section in the Panel.cfg file. Regards, Pete

Does it interface only to FSUIPC? If so then it should have no problem at all through WideFS. I don't understand what you mean here. Certainly nothing of mine requires any application to link a DLL. You need to explain what you mean. Any application written to interface to FSUIPC on the same PC as FS should certainly have no difficulty connecting via WideFS, as the interface is identical. That's the whole point. There is no application DLL necessarily involved in any of that. That does not make sense. FSUIPC has no Network code in it whatsoever. And "sending stuff via TCP" is not ever going to get WideFS interested. It has its own complex protocol in the interaction between Server and Client. This is independent of the Network protocol, which can be TCP/IP or SPX/IPX. Regards Pete

I'm sorry, you need to direct your inquiries to the sellers. I only do development and technical support. As far as I know you pay in whatever the units say on screen -- it is your credit card company that converts it, you won't know the final amount till you get your bill. At least with all my purchases on the 'Net this is what always happens. Regards, Pete

I'm sorry, but if there is no version info there there is no way it was gain free access to FSUIPC. The whole license checking process revolves around automatically reading that data when the program connects. The only answer for such programs is to purchase a user registration key for FSUIPC. Most users find this quite worthwhile in any case, for access to the facilities it provides. Regards, Pete