Pete Dowson

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

Ah, right. Thanks. At present, then, 61B0 and 61B8 aren't really of any use. I'll not included them (yet). Same for 6178, 6180, 6188 and 6008. Rightthis may be important for some internal functions for the GPS/planner, but probably not for an external program. I'll leave them out of the dox for now. Thank you very much! Regards, Pete

I'm still a bit confused. There is a "seconds since midnight" in 600C according to your first list. It looks like you are saying that 61B8 is the number of seconds since some arbitrary starting point, divided by 5, and 6190 and 61B0 are copies of this at specific described events. I'll see if I have time to cross-check these so I get the descriptions right before updating the docs. Thanks! Pete

Well, as I said in another thread, I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we do later find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically. Regards Pete

Your throttles are behaving well then. I never really could understand why some (like mine) give no measured jitter and others wobble all the time. I'm sure there cannot be such variations in manufactured quality. I bet it's down to environment -- dirt, humidity, temperature and quality of power supply. Well FSUIPC 3.47, released tomorrow, is just a little different from 3.469 -- a fix for FS98-style visibility setting in FS2004 (still used at least by Squawkbox 2.3), added controls to disconnect throttles in case we can't resolve the issue on the 767. Changes planned for PFC.DLL are mainly in answer to additional requests, like having throttle equalisation for three and four-engined aircraft. Regards, Pete

Good. One down one to go. I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically. Regards, Pete

No, there's no such 'skeleton' key for apps I'm afraid. They are all uniquely dependent upon the program concerned. There's no "developer's license" as such. So far all developers have purchased a user key, which gives them complete access for any programs being developed or used, as well as to all the facilities (and of course does help me justify the work I put into supporting developers and the SDK). When the development work is advanced far enough to justify its own access key for use on non-user-registered installations of FSUIPC, then I can provide one quickly enough, and it can be tested easily by simply temporarily removing your FSUIPC.KEY file from the FS Modules folder. The programming changes needed to incorporate a key are minimal -- in fact none at all if you simply place the key in the Version Information data. Regards, Pete

Why would you need FSUIPC to assign trim controls? They are standard FS assignable controls. Did you check the FS Options-Controls-Assignments list? They are assigned by default on the keyboard as: ELEV_TRIM_DN=36,8 (Home, or number pad 7 with NumLock off) ELEV_TRIM_UP=35,8 (End, or number pade 1 with NumLock off) These are lines from the FS2002.CFG file. The names here are the names you will see in the FSUIPC drop down list too. How did you miss them? FSUIPC only lists things by their 'official' names according to FS -- the names are those actually listed in their CONTROLS.DLL and included in the "List of FSxxxx Controls" documents available on http://www.schiratti.com/dowson. Also, they are the control names seen in the FS CFG file against the key presses and button assignments it makes. You've not calibrated them correctly then. Calibrate them properly in Windows game controllers first, and get them working in FS. Why are you using FSUIPC for this? Neither is likely. It seems to be a problem with them not being calibrated correctly. FSUIPC is merely a way of getting more accurate end points and centres, with response curves and filters. But you need to get things working properly BEFORE attempting to use FSUIPC. Start again from first principles. Use FSUIPC when everything is pretty good. Regards, Pete

I'll need to fix it before I make a general release, some time in April maybe. I'll have a quick look next week when I add a few other changes I've been promising. Even if I can't fix it then maybe I can add some diagnostics to try to track it down. Nothing there any different to what I'm running. Could you send me your PFC.INI file just in case it's some combination of options? petedowson@btconnect.com. Thanks, Pete