Pete Dowson

I don't know ShowADV. Is that like the ShowText utility packaged with AdvDisplay? Is it running on the same PC as all those others? What has "not enough hot key slots" got to do with the sequence? there should certainly be enough slots for both Radar Contact and FDC! What "add-ons" other than those you list above? Sorry, you lost me there. Check the WideClient.Log and WideServer.Log files. See if there any errors reported. Have you made any changes to the WideFS INI files? I don't know all of those programs you mention, but you may need to change the ApplicationDelay -- it should be defaulting to 0, but this may enable one of your programs to monopolise the interface. Also, I think both Radar Contact and FDC need good use of the sound card. Don't they clash somewhat on the same PC? Regards, Pete

It's available in the Avsim library (http://www.avsim.com). Author is Joshua Robertson. The latest version is there now, filename realtime_159172.zip. Regards, Pete

There is an option in FS which says to use System time or Flight time. Check the Options menu. Mind you, some have said that doesn't work for them. It's been an option in FS for many versions now, but I must admit I use "FSRealTime" to control the FS time. Regards, Pete

What program is giving this "error code 43"? What do the makers say? Regards, Pete

That is doubtful given our past history. Pete

I would assume so also, but you should research your needs first before making any assumptions. Everything there is for developers is included in the FSUIPC SDK, see http://www.schiratti.com/dowson. There is only one "FSUIPC", not a commercial one and a free one. Programs need an access key to interface to it. This is all described in the Access Registration document inside the SDK. There is no fixed price -- see that document. Regards Pete

Orders from whom? Sorry, I'm not sure what you are talking about here. If you are trying to control AI aircraft with FS commands through the FSUIPC facility, you should be aware that most do nothing and many others are only of limited use. For experimental purposes you might find it much easier to use the Traffic Toolbox from MS for this, sending selected aircraft controls via the dialogues it provides. Are you saying that you can still see them on screen, or in the MS Traffic Toolbox, but not in FSUIPC's tables? FSUIPC only lists what it reads from FS. If FS erases aircraft -- as it will if they are "stuck" for longer than a certain time -- it will erase them. Without interference from outside this mostly hapens on taxiways when two meet head-on. One or both will be erased if no way out is found. I think the time allowed for a resolution was reduced from 10 or 15 minutes in FS2002 to around 5 minutes in FS2004, after general complaints about blocked taxiways. Regards Pete

First, please update to 3.47. Version 3.45 is no longer supported. It was replaced yesterday. :wink: They are all in the list. Have you not even looked through? I think they are all named "Toggle xxxx lights" or similar. Anyway, I provided the List in document form in the ZIP so you could use Search. The names aren't always obvious -- I don't choose the names, they are the FS names from CONTROLS.DLL. Search for 'Light' in the document and you'll find those and more. Pete

For things that FS9 provides controls for you have no need to get into such complexities, you just use the controls. The first place to check is FS itself. Go to Options-Controls-Assignments. That's where all the more common FS controls are, provided there by MS themselves for you to assign to buttons or keys. If what you want isn't there, check the drop-sown list in the Buttons or Keys pages of FSUIPC options. They list all of the FS controls actually defined in FS's own CONTROLS.DLL, so the list varies automatically between FS2000 to FS2004. Not all of those controls work, though. MS seem to have left them listed in CONTROLS.DLL even when they've broken them or taken the code out. But it's worth a try. For obvious ones like light switches they should all by either in the FS assignments list, or in the full Controls list. The FSUIPC controls list also includes a lot of additional controls implemented in FSUIPC instead. A list of those appears in the Advanced User's document. There's a lot for Project Magenta, but many others besides. The FSUIPC User document does mention most of them too. The offset control facilities are just a subset of those added FSUIPC controls. Those come in useful when there's nothing else which will do what you want. Particular applications for those include interfacing to add-on panels and applications which use FSUIPC offsets for control (pmSystems is one such), and doing clever programming tricks with more advanced button or key assignments in FSUIPC -- examples of this are packaged with my GFdisplay program. Hmmm. You have a very old version of FSUIPC then? For quite a few releases of FSUIPC now, the FSUIPC.ZIP has contained the full list of FS2004 controls. Didn't you notice it? Well, yes, but that's exactly what FS itself does for you in any case when you use its Options-Controls-Assignments dialogues. Have you looked at those? Since FS2002, I think many, if not all, of the controls not assignable in the FS Assignments dialogue have also not worked when you put them into the FS CFG file directly -- FS removes them for you! This wasn't the case for versions before FS2002, and in fact some of my documentation about editing the CFG file is rather limited when it comes to recent versions of FS. However, you can assign any of the listed controls, and more, as I've just said, in FSUIPC. So, why the talk about "offsets"? :? Anyway, I think you will find it a lot easier to use the facilities FS and FSUIPC provide, especially if you try using controls which FS subsequently removes from the CFG file. :wink: Yes, of course. And more, all of the added FSUIPC ones. And of course that 'downloadable list' is included in the FSUIPC.ZIP in any case. :o Regards, Pete

In that case it is most certainly NOT the latest version you have installed! No versions of FSUIPC since 3.40 will give that message because it simply isn't in them. Please re-check what you have done. It sounds like you've not copied the latest FSUIPC.DLL into the FS Modules folder. Regards, Pete

Yes, because I cannot support any others. No. If you simply copy the DLLs in you have no problem as they will replace the previous ones with the same name. Windows does not allow more than one file with the same name in the same folder. What you must never do is just rename the files and leave them in the Modules folder, and you must never put them in the main FS folder. If you want to keep old versions, put them in a separate folder of your own making. You only ever need to replace the DLLs and EXEs when updating. I keep saying this. You can keep your INI file settings, though for WideFS I do recommend you allow the assorted performance parameters to default. Please read the documents, and see the lists of changes in the History section at the end of the WideFS document, and the History document for FSUIPC. I think the problems you had are due to something else you have running in Windows, as they are not things that FSUIPC or WideServer can do. I did suggest some things for you to check and to try, but you never told me what happened. :cry: Regards, Pete

Yes, exactly. Oh dear. Hex works as hex no matter whether you are talking about offsets or not. It is a number system. It is not specific to FSUIPC or offsets or anything!! "Hex" is short for "hexadecimal". Hexadecimal numbering is a system where each digit represents values from 0 to 15, unlike decimal numbers which run from 0 to 9. In a decimal number, each digit represents 10 times the next one, so 123 = 1 x 100 + 2 x 10 + 3 x 1 In hexadecimal, 123 means something entirely different: x123 = 1 x 256 + 2 x 16 + 3 x 1, which in decimal is 291. Because digits in hexadecimal need to go right up to 15, the letters A -F are used. So numbers go: 0 1 2 3 4 5 6 7 8 9 A B C D E F with A = 10, F = 15. When you add 4 to 3388 you therefore get 338C, not 3392. You were adding in DECIMAL, not HEXADECIMAL! 8 + 4 = C (see list above). It's all simple arithmetic, just in a different base system. That's as much as I can explain, really. Please refer to a guide to computers for more about binary, octal and hexadecimal number systems. Regards, Pete

I was puzzling for a while about what you were talking about, and it took me a while to realise that your question was split between the title and the text. :? The FS controls which take parameters have their own idea of how to interpret those, so, in general, no, you cannot assume anything of the kind. Best to experiment by assigning the FS controls in FSUIPC's Buttons or Keys page with different parameters. They vary -- I'd normally have to find out by experiment what was needed, which is what you'll need to do. But if you have any specific controls in mind, ask. Maybe I'll know. Also, check the original version of my FS controls document (the one for FS2000 or FS98, whatever) as I did try to explain a few way back then. Regards, Pete

Unfortunately it wouldn't fit in at all with the current FSUIPC control mechanism. It would have to be a complete new and separate facility. And, I'm sorry, but it is now too late for new facilities for at least two months -- much longer if Microsoft are planning a new version of FS this year. Regards, Pete

It has ALWAYS done that if the file is re-written, as any editing in the Buttons page would do. I can't do anything about that. Best to put the comments on the active lines. The best I could do, maybe, in a future version, is to allow active (numbered) lines containing only comments (n=;...). The main change in organisation now has been the retention of your line numbering -- in all previous versions not only would your comments be moved but also your lines would all be renumbered in seqience if not already. The file is a Windows "profile", just like FS's own CFG files -- they will do the same thing when re-written. Regards, Pete

You have some errors: The zero terminator is being written to 3392, which is 10 bytes later than 3388, not 4. You seem to have reverted to counting in decimal, not hexadecimal. 8 + 4 in hex is C. Hex digits go 0-9 then A B C D E F. No idea why that should be. If the 0,10 and 0,11 programming is similar they should be the same. Are you sure the button 0,10 isn't doing something in addition or different which is responsible for the delay? Regards, Pete

In that case it would be best to get support from your suppliers or from Elite. Sorry, but I know nothing about Elite, USB or hubs. It is nothing to do with FS or FSUIPC. Maybe you have windows power management operating and shutting off the USB power to conserve power? Pete

Ahwhy do you need to know, then? I'm a bit puzzled as to why you are interested in the effects of writing to an offset when you don't intend to do so? Check the documentation. There's a button you can press for any offset which gives you a window with two tabs. One gives a description, the other allows you to read and write. If you don't want to write a program, the other way is by using the Buttons or Keys programming facilities in FSUIPC. There are added controls for writing values to offsets, even incrementing or decrementing them. It's all in the documents provided. No. The program doing so needs an access key if you haven't registered FSUIPC. FSInterrogate has one already. You cannot use the Buttons and Keys programming though. Regards, Pete

What version of FSUIPC? Make sure it is the latest (3.47). Try again, close FS, Zip up the FSUIPC.LOG and FSUIPC.KEY files and send them to me at petedowson@btconnect.com. Regards, Pete

They are listed as "Elev trim dn" and "Elev trim up" in my FS2002 installation. Are you using some substitute FS CONTROLS.DLL? The names in FSUIPC's Keys and Buttons drop-downs are obtained from there. That's rather odd. Is your FS CFG file write protected? Pete

I'm pretty sure it's continuously variable, to 1/100th of a mile, but try it and see. You can only tell by watching the view. Best do it at a known airport, see what you can see then measure the distance to it. When the graduated visibility option in FSUIPC is enabled, and you climb or descend, the visibility changes reasonably if not perfectly smoothly. This uses the same fiddle in FS. There may be some "stepping" going on, but certainly not as coarse as the menu slider suggests. There may be graphic limitations also, which may vary from one video card/driver to another, but I wouldn't have thought so. Regards, Pete

Not the built-in GPS and ATC, no. They are part of FS. There are some third party GPS implementations around, which are separate programs and 9i think) will run okay on a Networked PC. For an external ATC I'd recommend Radar Contact. Regards, Pete

It won't be possible for FS to "miss" 200 mSecs of its processing, as each new value of each flight parameter will be derived from the accelerations and forces calculated before. This is a continuous process which may be synchronised to some time (quantum), but certainly a lot smaller than 200 mSecs. Just altering the time by adding 200mSecs someplace is not the same thing. That's just a clock. you don't affect reality by moving the hands on a clock. Same with pausing of course. After however long it is paused for, it continues from where it was, not from where it might have been. Or am I misunderstanding what you are trying to do? It seems very mysterious and odd. Apart from pause, you can also change the time (but only by year/day/hours/mins/secs), the simulation rate (even down to a sim rate of zero, which is like pause but not the same), and you can put it into slew mode. All these will have some effect on time in the Sim, but I really don't know what effect you are after. You should be able to get more consistency and a faster process switch by stopping windows doing anything else at all (delete all other non-essential processes), using a very fast, preferably HT otr dual processing machine, and, maybe, by raising the priority of your own and FS's processes to the one just below critical. Pete

Best ask him first, today. And so he expects it. I think he's away next week some time -- maybe not till Wednesday though. Regards, Pete

Ah, that explains a lot, in FS2004 at any rate. But it wasn't the same in all releases. I have so much hooked into these chains that finding a working alternative is not easy without risks, and the risks are concerned with stability of FS. If the calls are from an external application, two of them involves 4 process switches, so that is obviously a lot less efficient. From an internal program it is almost negligible -- an extra message on the message queue. Who will notice amongst the millions? It always amazed me how much FS uses the messaging system internally. Most odd. If you are reading data then you read it there and then, in that call, either from memory in FSUIPC, or from FS memory directly mapped. If I need to call other parts of FS to read such data or maybe just to convert it from a mapping, then that is done in the Chained part, but the results go into the FSUIPC memory which is where you are reading them. Therefore, how "out of date" that data is varies according to how close your read comes to the most recent Chained update. There again, to save processing time, FSUIPC classifies some data as lower priority than other data. Some of the lowest priority, like NAVAID names and positions, may only be updated infrequently, perhaps half-a-second at normal frame rates. And so on. Only the more important flight control values are updated every "frame" (chained call). If you are writing something, then it very much depends. If it is something that can be written directly to FS and have the desired effect, then it is done there and then, in your process call. If it involves me posting a message to FS, or, in most cases, calling an Event handler directly in SIM1.DLL, then that is normally doable in the process call. But some things aren't, because they are precarious. Changing the Traffic settings, for instance. If you change the percentage of AI traffic, I flag that and do it separately. The most important example is weather -- the calls I make to both read a specific weather station or set one are only ever done on the chained entries. I tried doing them immediately with horribly unpredictable results. I assume this is related to threading and non-reentrant code in some parts of FS. Regards, Pete