Pete Dowson

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

That will likely nearly all be Windows process switching (x 2). Some may be time wasted whilst in the FS message queue waiting to be processed. The time actually inside my code, in FSUIPC, is very rarely as much as 1 millisecond -- it only gets that high when I have to call some function in FS which accesses disk files and loads or saves things. I think the question you need to ask is "is there any way to make Windows switch processes faster?". And I don't know the answer. You could try a 3.8 GHz Pentium 4 with hyperthreading, arranged such that your are in one virtual processor and FS is in the other. Or even a dual processor machine. But I don't really know if that switches processes that much faster either. Sorry, no. I don't know anything about how FS is threaded at all. Regards, Pete

Hmm. I didn't know about chain x10. Is that reliably 15mSecs? I use chain x02 which appears to be a normal Windows "tick" counter (55 mSecs) for many timing purposes, rather than directly access a new Windows timer, but a 15 mSec one might well come in handy. Chain x13 is the main one I use for synchronisation, yes. This was fine in FS2000 and before, but it appears to occur 4 times too often in FS2002 and FS2004 (compared to before) so for many purposes I only use every 4th call. To make matters more complicated, it appears that in FS2004 (not FS2002) if the Slew mode display is on it goes 8 times faster instead of 4, so I take every other one again in that case. Weird. Note that this is for the calling of procedures in SIM1.DLL and WEATHER.DLL elsewhere to set or obtain data I can't get any other way, and the tracing of pointers to privately owned data structures, all in order to keep a variety of values up to date. Where I can map directly I do, and in these cases there's no synchronicity imposed. The calls from applications via the message queue are of course aynchronous and are dealt with as they arise. Some action requests are left to the next synchronous time, but not that many -- mostly those concerned with the weather which seems very precarious otherwise (probably code re-entry. Very bad). So, really the synchronous nature applies to all those variables which I have to obtain by procedure call or convert from one form to another. It's all got far too complicated over the years. If I was to start again now I'd do it differently. I'd design for FS2004 (or 6 or whatever) and leave older versions to older unsupported FSUIPC's. But it's all predicated by time. I don't seem to ever have any. :wink: Regards, Pete

Yes, correct. but you don't need to find anything in FSUIPC.INI. You simply need to find the correct offset which indicates the state of the master battery. Yes. And this is offset 3102, as you have already ascertained! There's also another at 281C which was found after I had made FSUIPC set the 3102 offset. There are some duplications like that, arising historically. Either will do. Regards, Pete

Maybe it would be good on the http://www.schiratti.com/dowson site with all the other FSUIPC stuff? Make sure it is credited to you of course! :wink: If that appeals, write to enrico@schiratti.com. If not, I'll understand. Your choice entirely. Regards, Pete

Eryou need to start with explaining what you want to accomplish, not in the middle like this. 99.9% of anything you may want to display already has a value in an offset somewhere in FS. Are you adding something not at all supported by FS, like signalling the stewardess to bring you a cup of coffee? :) Until you explain what you are attempting to do, there is no answer possible to that. All the FS controls are listed in the list of FS controls provided in the FSUIPC.ZIP (and listed in the FS buttons & keys dropdowns), and all the added FSUIPC controls are listed in the FSUIPC Advanced User's documentation (and also included in the dropdowns). All the FSUIPC offsets already programmed with some information are listed in the big table in the Programmer's Guide, which is part of the FSUIPC SDK. It works more by luck than design. If you have more than one line operating on an object (display or LED) they need to be numbered, thus: [GFT8.0] L0.1=C14=1 L0.2=!C14=0 L1.1=C15=1 L1.2=!C15=0 L2.1=C16=1 L2.2=!C16=0 otherwise all that happens is that the first, or maybe the last (sorry, I can't tell without looking up the code) will be used only. In this case, by luck, it doesn't matter which is used -- the LED is set when the right hand side is "true" (non-zero), cleared when "false" (zero). And you don't need Conditions for this, so it is even more complicated than it should be. All you would need is: [GFT8.0] L0=X3101 U8; Alternator Master L1=X3102 U8; Battery Master L2=X3103 U8; Avionics Master The LEDs are lit if the result is non-zero, extinguished if the result is zero. I changed the variable type to "U8" instead of "S8" because, though it makes no practical difference in this case, they are really just unsigned bytes. The fact that you aren't using the numerical value, just the "zero-ness" of them makes it irrelevant of course. Regards Pete

Just use the FS controls for those things. Program them in FS, even. You don't need FSUIPC to program standard FS controls. Check FS's Options-Controls-Assignments. If you want to use FSUIPC, check the drop down list in the Buttons page for the same FS controls. Inside the FSUIPC.ZIP package there's a list of all the FS controls in FS. Why do you want to start messing with 'offsets'? Regards, Pete

Basically, yes. In fact it only affects those Clients that actually care about the offsets you are changing, because WideServer only sends updates to those clients who are interested in those offsets (to save time and bandwidth). Please, please, take a little time to read at least the introductory sections of the WideFS documentation. You seem to have missed the whole purpose of WideFS, and that is to extend the FSUIPC interface to all client PCs. The FSUIPC interface IS the reading and writing of "offsets". That's all there is. :shock: Pete

1. Check the slew mode sensitivities. Maybe they are too high. Did you tell FS to increase ALL sensitivities to max, or just select the throttle ones as suggested? You need to be a little selective at times! 2. You can also calibrate and adjust slew axes separately in FSUIPC in recent versions -- it's one of the pages near the end of the Joysticks section. Set slew mode first then enter the FSUIPC options. If you use a nice central dead zone you should be okay. Regards, Pete

Has it been over 24 hours? If so raise a problem ticket. if not, please be more patient. The requests are dealt with by humans. What do you expect? See some of the announcements and stickies at the top of the forum. They tell you what to do. Pete

Take it apart: C = "Control". this distinguishes it from a Key Press which would be 'K'. x = "heXadecimal, saying what follows in to base 16, not 10 like decimal. 5100 is the high 16 bits of the Control number. This identifies the command as the Offset Byte Cyclic Increment, as in the list: Hence "66C0" is the offset. The "x00030001" part is the parameter. the explanantion of this is just below the list quoted above: So, the upper 16 bits (0003) give the limit of 3, and the lower 16 bits (0001) gives the increment. As I said when you first asked this, these facilities are simply not designed to do what you apparently want to do. I've no idea why you should want to do such things in any case. But all you do is: Write the ASCII for 'L' (0x4C, or decimal 76), followed by zero (0x00) to 3380: ... Cx02003380,x004c The x0200zzzz control writes a WORD (16 bits) to an offset. 3380 is the offset. The value x004c is the letter L (x4c) followed by 0x00 (remember bytes are Lo->Hi in all Intel processors. This would be different in an Apple!) Then, to make that display, write the control word to 32FA. Write zero here for it to stay displayed until changed. write a number here for a number of seconds. e.g. for a 5 second display: ... Cx020032FA,5 Pete

FSUIPC doesn't actually work with the joystick inputs themselves. It is manipulating the actual values inside FS. It's the same for any axes, there is no difference in the code for throttles. It doesn't actually read the joysticks, but traps the AXIS_xxxx_SET control just before it goes to the simulation engine in FS. That places it after all Windows or CH calibration, and after the FS assignments and sensitivities. You do need all that working properly before FSUIPC can do much. The usual cause of this sort of problem has certainly turned out to be low, even zero, sensitivity being set in FS (Options-Controls-Sensitivities). FS2004 in particular seems prone to setting these at random (it seems) whenever you make any new assignments or changes. I've made a habit of checking there every time I try out a different or new connection. When the sensitivity is actually zero, only zero values are seen by FSUIPC. You can log the AXIS controls in FSUIPC's Logging page in versions since 3.45. This may help identify what the problem is. Do that first without FSUIPC calibration set (press the "Reset" button for the axis to cacel FSUIPC involvement). Regards, Pete

Is the fourth throttle active in FS itself? You have to have a 4-engined aircraft loaded of course. Check the sensitivities in FS. You should have all sensitivities set to maximum, all null zones to minimum if you want to make best use of FSUIPC's facilities. Flight Sim seems to be very inconsistent how it sets sensitivities. Please also make sure you are using the latest FSUIPC. Current is 3.45, but 3.47 is being released tomorrow. Did you check Bob Church's site, as noted above. He's written some useful stuff for the CH quadrant. Regards, Pete

Yes :lol: :lol: :lol: . I'm updating both the list and the FSI file at present, ready for FSUIPC 3.47 released tomorrow. I expect to re-issue the SDK with up to date information by Monday. Regards, Pete

The Z key operates the Level D767 A/P?? Pete

In the SDK, the FSInterrogate program comes with a file called "FSUIPC.FSI", which is, in itself, a "list of the offsets" -- what's more, it has all the right conversions already built in. You don't need one to use the other. I don't know where you found your "list of offsets", but the only official one maintained by myself is in the document I call the Programmer's Guide ("FSUIPC for Programmers.doc"). Pete

Yes, that is what FSUIPC is for. Download the FSUIPC SDK from http://www.schiratti.com/dowson and check the Programmer's Guide and example packs provided. Regards, Pete

FSUIPC works at the FS frame rate. If the frame rate is 20 fps then an average of 50 mSecs is what you may expect. Most of the variables being read by FSUIPC are read once per frame (at most). I cannot really support version 2.87 of FSUIPC, it is several years old and the code is almost completely different now. If you want to ask any more specific technical questions please upgrade to the current version (3.45) or wait for 3.47 which is being released tomorrow. Regards, Pete