Pete Dowson

I didn't receive any email from you, I'm afraid. Maybe my mailwasher removed it -- there seems to be some email addresses that get on its blacklist. If you'd like to try again I'll take a careful pre-look first. The Access Registration document in the FSUIPC SDK explains what I need by way of information to make the Key, and also explains how you can build the key into your program. Regards, Pete

"My software" being only FSUIPC? You know I provide a module called EPICINFO which can send data to EPIC? If you wish, of course you can. You will have to learn how to interface to FSUIPC (the FSUIPC SDK) and also how to program the EPIC, both from the PC and internally in EPL. Alternatively you could take a look at EPICINFO and see if that will do the job for you. I believe there's also a program called FSCommunicator or similar which can handle EPIC. Regards Pete

Just place the FSUIPC.DLL module into the new FS modules folder, along with your FSUIPC.INI file if you want to retain your previous settings, then, after running FS, re-enter your registration details as you did originally. If you save or print the FSUIPC.KEY file (in your old FS Modules folder) you can copy the details from there. It is a simple text file. Regards, Pete

Go into the Buttons section of FSUIPC, press your button, and assign the appropriate keystroke. If the gauge's ident function is only provided with mouse operation, then the only way would be to get Luciano Napolitano's "Key2Mouse" program and make your assigned keypress combination operate the mouse movement and click. But in general most of those new panels provide keyboard shortcuts too. Regards, Pete

FSUIPC doesn't do any calculations. The ground altitude is read directly from FS. I don't know where it gets it from -- when over an airport it's definitely set by the airport elevation, which overrides any mesh settings. Otherwise I would have thought that it would be the ground altitude set by whichever mesh it is using at that place. I can't see FS deliberately going to find other values when it needs the currently operating mesh to actually draw the surface and detect crashing/landing. Regards, Pete

Sorry, you need someone who knows about hardware interfacing first. Then your software will depend how the hardware connections are accomplished. There's a cockpit builder's Forum near here. Perhaps a message there might elicit some useful suggestions? Once you sort that side out, you may need the FSUIPC SDK, from http://www.schiratti.com/dowson. Regards, Pete

How is the PFC TQ connected? If you are using my PFC driver (PFC.DLL) then you can re-assign and calibrate any of the levers in the option screens there -- just use one of the User Configuration pages, and assign it to the aircraft so it is automatically selected when you load the aircraft. Please check the documentation provided. Regards, Pete

They are signs that something is not quite right, but if the errors are so infrequent, and do not become noticeable in the flight, I wouldn't worry so much. Sumcheck/length errors can only occur if a block gets corrupted or truncated in transmission. Theoretically this can only happen on a faulty cable or switch, or possibly more likely, a faulty Network Adaptor. Less likely are memory errors on one of the PCs or interrupt (IRQ) conflicts. But as long as it doesn't get worse I wouldn't worry about it. Regards, Pete

No, not stupid. The stupid question is the one that's never asked! It can't get much more stupid than that! :wink: Regards, Pete

Yes. For FSUIPC offsets you need the Programmer's guide from the FSUIPC SDK -- download it from http://www.schiratti.com/dowson. Searching that for "weight" gives you several references. Try 30C0 (apparently not verified for FS2004 yet -- please let me know) for pounds or 30C8 for the mass in "slugs". There's also the Zero Fuel Weight in 3BFC. Regards, Pete

I advise using the Name rather than the set of numbers making up an IP address simply because: 1) it is easier to remember and less likely to get wrong, and 2) if you use dynamic IP addressing, as is defaulted on Windows, instead of a fixed IP address, then it will be different each time you boot up and so WideClient will not find it. In terms of performance there's absolutely no difference. The Server address or name is only used once, when connecting. If you give a name, WideClient merely asks Windows to convert it to an address -- that's one short call extra per connection. It won't be detectable. You quote it out of context. That was not talking about how you tell WideClient where the Server is, that was about optimising your Windows network -- and not just for WideFS. It is obviously more efficient in Windows for each PC to have a fixed IP address than having it reassigning them dynamically. In Win98 especially (less so in WinXP) the latter action is repeated from time to time and it causes regular small stutters in programs like FS. It doesn't particularly affect WideFS itself. This setting only relates to WideClient in that if you do have Windows dynamically assigning addresses then you simply cannot use the IP address to tell WideClient where the Server is, because then you'd have to edit the INI file every time Windows changes the address (as well as having more of a job finding out exactly what IP address Windows has actually assigned!). So now, Im in doubt: what is the best in terms of performance? In terms of WideFS performance, neither method of specifying the Server to WideClient is "best in terms of performance". It's just a damned sight easier to give it a name than a possibly changing set of numbers. But please yourself. You are actually making a big subject out of something absolutely trivial. Regards, Pete

http://www.flypfc.com is PFC's site, or you can write to Eric@flypfc.com. They should certainly be able to send you a driver. Alternatively, nearly all USB-Serial adapters use an FTDI chipset. Drivers for those are on their website, http://www.ftdichip.com/FTDrivers.htm. Regards, Pete

PMDG have their own code for A/P etc. There's no way I know to control it other than via the keyboard short-cuts. They do have some sort of FSUIPC interface, but they won't publish their SDK at present. I don't know when that will be resolved -- some folks have hacked into it somewhat. I'm sure you could find out more if you searched. All I know is that at least they have published an SDK and that some folks are doing things with it. I don't have any other details. Check their Forum on Avsim. Regards Pete

No need to be sorry. You'll find everything you need to know about the main PM offsets in that document, but if you use pmSystems too the only list is the Sysvars.txt file inside the pmSystems package. Regards, Pete

Obviously PM documentation is to do with PM, it isn't mine. The PM offsets in FSUIPC are all fully documented where they've always been documented, in the PM offsets document on the PM documentation site: http://www.projectmagenta.com/resources/docs.html You'll see all the MCP/FCU indicators listed at offset 04F0, thus: Since you already know bit 0 is the AP 1 switch, how come you don't see LNAV and VNAV (for example) listed too? For a Boeing MCP, LNAV is evidently bit 6 (M0040) and VNAV bit 14 (M4000). Regards Pete

No. WideFS supports the FSUIPC interface over a LAN connection. That is what it is for. But only applications which use FSUIPC can run through the FSUIPC interface. FSNavigator is not an FSUIPC application, and it isn't even a separate program. It is an add-in module for FS, just like FSUIPC. For FS add-in modules to work, FS is needed. Without an FS installation on a PC there is no FS for an add-in module to be added into. The same aspplies to other add-ins like scenery, aircraft and FS panels and gauges. They all need FS to run inside. Regards Pete

Hmmm. That's a "how long's a piece of string?" sort of question. From the time FSUIPC actually receives the message (which is via the FS message queue) to the time it exits the Message procedure having filled in your data will, for reads only, be much less than a millisecond (it gets difficult to quantify such values). However, the time for Windows to place the message in the correct queue, process change from your program's process to the FS process, then for FS to reach that message in the queue along with all the other messages it deals with, then for Windows to change from the FS process back to yours -- is unpredictable, and, what's more, will vary from time to time depending upon all sorts of other things going on on the system. If you are using Win98don't. Its multiprogramming is simply not good enough. If you are using WinXP, then it's good enough at multiprogramming and timeslices quite fairly. But some time do a CTRL_ALT_DEL and take a look at the list of processes awaiting attention. In other words, it's a very complex system. I'm afraid there's no guarantees. Check the menus. Options-Settings-Hardware-Display. It may appear more jerky than it should. Obviously, for smoothness you want your visuals to be timed the same as FS's would-be visuals. Since your process isn't running after you call FSUIPC_Process, until it returns, that question cannot arise, at least not in that form -- unless you are multi-threading. But you don't want to multi-thread calls to FS. That makes things worse, not better. If you get results too often they won't have changed so you'll not only waste processor time but produce micropauses, too infrequently and you'll miss some intermediate values and get jerks. Regards Pete

FSUIPC can supply distinct data for everything that changes in each frame at the frame rate. Somethings it could supply more often, but there's little point -- if the frame rate is so horrendously low you wouldn't be able to run anything fast enough to get the data faster in any case. I wouldn't worry about that -- even data adjacent in the table is often scattered in wildly different places inside FS. The contiguity you see is an illusion. Each Read or Write call merely adds the request to data internal to your program. That is negligible in terms of performance, a few nanoseconds at most. Every Process call is a process change, a message in a message queue, an interruption. You want as few of those as possible. Therefore do all the reads and writes you want, per frame, then issue the Process call. One such call per frame. Time your loop to approximate the frame rate in FS -- you can regulate the latter using the Frame rate Limiter in FS. 2Ghz is okay for FS2004 as long as you don't turn things up full. I use a 3.2 Ghz P4 and an Athlon 64 FX 53 -- the latter is super, but even the 3.2 is stretched. Regards, Pete

Sorry, I don't think I understand the question. What is this "Default Module"? Anyway, offsets in FSUIPC should be regarded as mere "tokens", a way of identifying the specific data item. They rarely relate directly to any sort of real address, at least not one which is fixed. They were true offsets (into GLOBALS.DLL) in FS98 and before, but no longer. FSUIPC maintains that illusion for continued compatibility. Regards, Pete

I should say that's a certainty. I provide access through FSUIPC for things that I other others (more expert in FS's simulation than I) have identified. But each one take many hours of hacking into the code to locate. It used to be easier, because the data was either in global variable space (e.g. in GLOBALS.DLL in FS98, and in the individual DLL's global variable space in FS2000). But since MS have been re-writing everything in C++ and using OOP class-type structures, it has become a nightmare. Data is private to each Class, classes are inherited and polymorphed and all that sort of stuff, and data is ephemeral not fixed. Data structures which used to be there whether or not the data is used or not are now not even pointed to when not applicable, and chains of pointers have to be followed for almost every access simply to get commonly required data. I'm doing no more of that sort of hacking for FS2004, because I'll only have to start again for FS2006. The work involved for FS2004 took several thousand hours, I am hoping that MS will not completely re-write everything yet again. Even so, it will take a lot of time. If you wish to try to locate things, feel free. Disassemble SIM1.DLL and start working through it. Tracing using something like Soft-Ice gives you a start into where to begin. The disassembler I use is Ida Pro. Regards, Pete

No need. I managed to reproduce it here. The problem is that the "Carb heat/Anti-ice" control mistakenly got marked as a PM control, so it only gets listed in the drop-down list if the "PM controls" option is set. This error was not new to version 1.92, it has always been there! Surprisingly no one came across it before. Anyway, the fix was easy. Here's interim release 1.921 with it fixed. Regards, Pete PFCDLL1921.zip

Does the FSUIPC_Process routine you are using have a short timeout? Does it have any retries? The C library I supply only gives a TimeOut error after 10 times timeouts of 2 seconds -- a full 20 seconds with no response. There are also other reasons for an error return from FSUIPC_Process. It looks like your code is assuming a timeout when, in fact, it may be a data error. The C library can return these errors from FSUIPC_Process: FSUIPC_ERR_NOTOPEN FSUIPC_ERR_NODATA FSUIPC_ERR_TIMEOUT FSUIPC_ERR_SENDMSG FSUIPC_ERR_DATA Now whilst it is undoubtedly not one of the first two, you may need to distinguish between the others. In my programs I simply Sleep() a little and try re-connecting (i.e. on error, FSUIPC_Close, then Open again, and retry). I do this until connection is made again. This takes care of long outages which can sometimes occur when FS is very busy doing file operations in menus and so on. Regards Pete

Er. Sorry, I have no idea what you mean here. Are you referring to an existing error report? Please clarify. Please do not fiddle about with the parameters. They are set optimally after many many hours of testing and adjustment on different systems, including Win98SE, WinXP, WinXP Pro and Win2K Pro. Without knowing anything about what you are saying, I really cannot help you. This is not a good way to start a thread. Perhaps you should please start from the beginning and explain what you are doing and what your problem is? Regards, Pete

Just one more thing on this. Well, two really. First, there's no such thing here as an "MSFS interface" -- the interfaces Microsoft provide officially don't come anywhere near providing what you see in FSUIPC. Nearly everything in the FSUIPC "interface" has been obtained by hacking into FS code over many years. Second, almost all of the engine values in the 088C-0AE0 offset area are actually derived by FSUIPC and populated there explicitly to provide compatibility across FS98-FS2000-CFS1-CFS2-FS2002 and FS2004. Those ones you can write to, such as the throttle, these days actually cause FSUIPC to call procedures in FS to action the change. You don't access anything directly anymore -- that only used to happen completely in FS98, less so as time has passed. You might like to try, instead, writing to some of the more "original" values -- for example the N1/N2 values in the 2000 offset region. I've no idea if you can achieve any success there. You'll see several inter-related values -- whether you need to change them all for consistency, and whether they would stick, I really don't know. The only reason I even suggest this is that I have been surprised when folks have actually written so some of the velocity and acceleration values in 3060-30B8 and 3178-31D0 areas and achieved actual changes, albeit rather short-lived. All those areas are "directly mapped" into SIM1's private data structures. Regards Pete

Yes, I agree with all that. I don't think that is in disagreement with anything I said before. Try setting it up and saving a flight. When you reload that flight, it should set everything about the simulation according to the saved parameters. That's your "initial state". The process of loading a flight actually destroys all the data structures owned by the SIM1.DLL (the core simulation engine) and creates completely new ones from scratch with entries and values based on the flight just loaded. From then on the simulation is in operation. I'm sorry, but I don't know of any way of changing the initial states other than by loading a flight, as it is that which creates the needed structures and initialises them. Regards, Pete