Pete Dowson

I've tried this on FS9 (first time I've loaded FS9 for many months!), and whilst this is certainly happening with, for example, the default 737, you can see from the crossfeed switch that value 1 sets crossfeed off, 2 sets crossfeed from right to left (the switch points to "right"), and 3 sets crossfeed from left to right (the switch points to "left"). I've no idea why it reports "14" for "crossfeed" only for right to left, sorry. If you actually use the switch with the mouse the values change to 15 (left), 1 (off) and 14 (right), so I'm guessing that, for this specific aircraft, 14, 1 and 15 are really the only valid values. If you use those instead of 2 and 3 then everything is consistent. I think you have to experiment with each aircraft to see what it is capable of in this area, and use the appropriate values. Instead of experimenting writing, I think you'd be better off first just Monitoring the offset on screen whilst changing things using the specific aircraft panel. You can do this without FSInterrogate -- see the right-hand side of the Logging tab . Regards Pete

You can't. FS doesn't supply such information in process.. You can read the Latitude and Longitude and then use an airport database to look it up. My freeware MakeRunways program can generate a database for you from user's sceneries. Regards Pete

3.75 is very very old, and unsupported. I can't believe we've been exchanging all these messages and you've been running such an outdated version! And I think there was no installer in those days. I implemented the first installer of necessity for FSX and did it for FS9 afterwards because of problems otherwise with Vista and Windows 7. Please don't come back with any further questions unless you update to 3.98 at least. :-( Pete

Oh dear! :-( What version of FSUIPC did you last install? Have you never actually run the installer? It is the installer which creates the FSUIPC Documents folder, and inside it it adds all of the documents -- the FSUIPC User Guide, the Advanced Users Guide, the list of FSUIPC controls, and the Lua package. Have you not even got the documentation? :-( I respectfully suggest you go to the Schiratti site, download the FSUIPC ZIP and run the installer. I really cannot support old versions or versions not installed correctly. You can buy PMDG aircraft from lots of places. Try SimMarket and Aerosoft for two. I've no idea whether PSS are still going. Sorry. Pete

Well, add-on aircraft makers do it, or at least create new ones, so I assume so, But I am not the person to ask I'm afraid. Try the aircraft making parts of the FS SDK. The Lua stuff is actually listed in the Installation guide document for FSUIPC. Look in the FSUIPC Documents folder, within the FS Modules folder. You'll find a package there. Alternatively check the Download Links and Documentation subforums here. Regards Pete

There's only one "minimum change" box which should contain a small value, the "Delta" value, which tells FSUIPC to ignore changes smaller than that. You are confusing the Delta value with the simply input value monitoring. If they are static, how can they change? Or am I misunderstanding something? If the axis is assigned correctly, the IN value will normally match the actual axis value shown in the axis assignments Tab. But if, for instance, you assign to the FS controls, it depends what controls you are assigning to and whether you have some add-on which is intercepting them. Therefore you need to state what exact option you are selecting for assignment, and which actual control (by name) you assign to. What if you press the "Reset" button in the calibration so the axis is no longer being calibrated by FSUIPC? You said that it "manifests in some payware aircraft but not in others", so it must be related to the aircraft, mustn't it? Always test with default aircraft. If you are assigning to the the FS controls instead of "direct to FSUIPC calibration" then aircraft code can conceivably intercept and change them before they get to FSUIPC calibration. Please, next time, state which version of FS and which version number of FSUIPC you are talking about. It always helps to know these things. Regards Pete

FSUIPC4 has nothing whatsoever to do witn ASE unless you are using ASE in FS9 mode, in which case it acts as it's intermediary in talking to SimConnect. You will need to direct your inquiry to HiFi simulations. There's an ActiveSky forum. I've been using all versions of ActiveSky since it started, and ASE works extremely well alongside FSUIPC. Regards Pete

Isn't that determined by the design of the aircraft model, someplace in the Aircraft.CFG or even it's AIR file? I don't think you can change the tank configuration "on the fly". FS only supplies fuel Flow values per engine, just like the instrumentation in the aircraft would do. If you want it by tank you'd need to sampel the fuel quantity at intervals and work it out by the changes. Of those 205C is only readable, as it's the number of tanks in the aircraft, 3104, 3125 and 3B98 are fuel pumps which don't always or often actually enable or disable fuel flow in general -- engines will suck it out anyway or get it by gravity feed. 3590 gives the fuel valve states which are opened and closed by the engine starters, so they are engine-related not fuel tank related, 3880 is the same as 0AF8 (0AF8 is FS98 compatible, 3880 is, or rather waa (before FSX) the actual directly-accessed FS value). I think the way fuel is used is controlled by the aircraft modelling. I really have no idea how to make FS do it the way you want it. I use Project Magenta and other ancillary programs which control fuel extraction from different tanks by actually manipulating the amount of fuel in them. I added a small Lua plug-in also to use fuel from the Left tank when the APU is running (this is on a 737). Try sophisticated aircraft models like the PMDG and LevelD ones. I'm sure they get it right. But I don't think the default aircraft do, not on their own at least. Regards Pete

Why not simply run MakeRwys correctly, then copy the files it generates from the FS root folder, to wherever that program wants them? Regards Pete

MakeRwys.exe must be placed in the FS root folder AND run from there on the PC containing FS. It won't work any other way as it finds the sceneries via the files stored on that PC and pointed to by the Registry on that PC. Regards Pete

No, you should use RunReady for programs to be started only when FS is ready. I have lots of apps which are best started directly instead. That's why there's a separate RunReady. BTW please try the revised WideClient which loads Lua's later, when they can read offsets safely. WideClient 6.847 Regards Pete

Hmm. Right. I only need one pair assigned then. I wonder why it is so consistent on your system yet I have a job to reproduce it? Strange. Thanks. I'll get to work on that next week. Thanks! Pete

Okay. I thought it might be related to that ... it narrows it down for me quite a bit. I'm going to have to try reproducing it again under my debugger so I can find out what is happening. Probably best to run with it off in any case. You shouldn't need it on for brakes at all. However, I would like to get to the bottom of it and fix it. I don't need any more logs, but since it was consistent for you with Flitering enabled, could you try once more with filtering enabled but only one pair of pedals assigned. Best just commenting out the lines in the [Axes] sections for one of the pairs, please. My problem is getting it to occur consistently enough to track it down, so any more clues are welcome. That's very kind of you! I do have it installed on one PC for experimentation. I think it was free or registration-free at least when I downloaded it. I assume there's a new version now? If you need to send me anything use petedowson@btconnect.com. Regards Pete

Yes, but the better offset for checking is 333C. This contains the official "connected" indication. It will 'come alive' at the same time. (9In the latest update to WideClient it will also clear to zero should the connection break or FS hang). To save such bother, which I admit I hadn't realised occurred quite so significantly, I think I will change the loading of Lua plug-ins so they don't even run until 333C shows connected. There's still the "initial.lua" option should you need to get in BEFORE connection in order to initialise local things. Look out for a WideClient update in the Download Links subforum. Maybe version 6.847 will do it that way ... Regards Pete

Okay. I was wrong! I have about 20 seconds too -- even when running WideClient on the same PC as FS! And this is the same for ALL Lua programs, not just yours. And I believe it is the same for all external client applications too. It is a consequence of the huge list of exchanges which WideClient has to perform these days before it has truly established a worthy "FSUIPC-like" environment for applications. This has grown over the years. Quite honestly, I was surprised when you started this question because I'd never even noticed it. And I'd never noticed it because it really doesn't matter. It is actually a trivial time compared to the actual loading of FS to the point where it is fully flyable, so surrounding programs never looked slow in starting by comparison. I am pleased, in fact, to note that trying to read offset data whilst WideClient is still initialising doesn't interfere as much as I feared. As you measured, it makes a mere 2 seconds difference over the 20. I expect I could shave off some seconds here and there, maybe by contriving to spread some of the initialisation out over a longer period thus allowing a lot more gaps for applications and Lua plug-ins. But this would surely adversely affect those programs which do depend on those "essentials" which are being initialised (things like timestamps for data read and write protocols, using in weather setting and reading and the like). So I'm reluctant to meddle. And it has been this way now for many years without anyone, before yourself, even noticing particularly. Please just be satisfied that there's nothing wrong with your system. Okay? Regards Pete

Hmmm. In that case there certainly seems to be something wrong -- 20 seconds from WideClient starting is almost okay, 20 seconds after FS is ready and connected is wrong. Can you paste you Lua into a message here, and I'll try it? Okay. Paste your Lua. I'll try it later. Dinner time here, then I relax a couple of hours or so, so i won't be back now for a few hours (I always do a bit of work before bed-time). Regards Pete

Not in WideClient because it generally doesn't process keys, and client PCs are normally unmanned, part of a cockpit somewhere very often. So all wideclient Lua's are loaded automatically, and re-loaded whenever changed (except for Initial, which is really intended to assist initialising attached hardware). The delay from WideClient saying "connected", or from your program being loaded? Or do you just mean the time from loading WideClient? you need to be specific. If you are reading the time in the WideClient log file, of course that won't change very much. It still has a lot to do. Yes, 20 seconds from "connected" is strange -- if that's how you are measuring it. 20 seconds from loading is longer than I would expect. But without being at your sysdtem to see why I couldn't really advise. I didn't expect you to understand the log, only to see how much it has to do! Can you explain why this is such a big problem for you? Surely you only load up things once or twice a day. Why is the start-up time so critical? Regards Pete

Since it isn't an optional part of the parameter list, FSUIPC simply attempts to get it as an integer using the Lua C/C++ call "lua_tointeger". I guess that routine (which is part of the Lua package code) treats "nil" like any other non-numeric and gives 0 rather than an error. Actually, I just looked it up in the Lua reference manual, and it is designed and documented to return 0 for anything other than a recognisable number. Ah, you meant "designed behaviour" differently! Sorry. No, I expected that there might be cases for different handlers. The only thing there can be only one of is the timer -- one per running Lua thread. Else it became a bit of a nightmare. I'll try to remember. Regards Pete

Sorry, I missed those.I actually suggested logging for YOU to look at, not me. Things are working. You wanted an explanation. The explanation is in the log, it tells you what it is doing. I don't want to see it unless there's a problem. BUT ... I now see that you called your Lua "initial.lua". That is not good at all. You should NEVER use "initial" lua for doing anything with data from FS. I suspect this is the main problem. INITIAL.LUA is started when WideClient is started. You should call it anything BUT "initial" so it starts when WideClient is connected and actually ready to handle offset requests! Additionally such plug-ins can be changed whilst Wideclient is running and they will be automatically reloaded. That is not the case with INITIAL. I think you must have missed this part of the documentation? Even the process of trying to access offset values will mess up the initialisation sequence where WideClient is trying to exchange only essential information to the environment it provides on the client PC. Regards Pete

After more experimentation, I did for a while get EXACTLY the same as you. I enabled both Reverse and Filtering in the calibration. I was just about to put a trace on it to find out why, and it stopped happening. Grrr. I suspect it's a complex relationship between arbitration and filtering -- filtering does make it a lot more complicated because values from axes don't go direct, they go through a pipe-type arrangement so the pattern can be smoothed. That makes it very difficult indeed to work out what is going on, even if it was consistent, which, at least here, it is certainly not! So, can you try not only without assignments and calibrations but also with only one set assigned and calibrated, and also with the filtering off. I need to narrow it down. There are far too many possibilities and matching code paths at present. Regards Pete

Could you turn off IPC write logging and instead use the Monitor to monitor 0BC4 and 0BC6 both as type U16, with "normal log" checked below? Then we are comparable. Hmmm. I'll need to try and set up another pair of axes to dual the toe brakes. Your log is so completely different that I'm mystified. There's no sign of any AXIS BRAKE controls. That can be a sign of them being captured and discarded elsewhere, but you said you had this with default aircraft. The presence of those other readouts definitely means FSUIPC is acting on axis inputs (it's the only way into the code which provides those messages). It may be related to the dual controls arbitration facility. That's what I'll need to check. Maybe I can get away with two left brakes being arbitrated rather than find a couple more axes. (Most of my stuff is PFC driven via my PFC driver and that wouldn't do the same in any case). What I still don't understand is that you said you got the problem even with no rudder pedals assigned or calibrated? Or did I misunderstand that? If I did could you try it, please. Also try with only one set of pedals assigned. [LATER] With two axes both assigned and calibrated on only one of the two brakes, so they arbitrate, I still don't get a problem until I touch the axes so causing jitter. THEN with arbitration I am getting the same Brake messages as you. And with the Monitoring as I requested I see the pressure going down to zero, not immediately changing (you can't see this with your logging). I certainly suspect it's jitter on your pedals. Try calibrating with a dead zone in the foot-off areas -- I see from your calibration that you've left absolutely no room at all, look: LeftBrake=-11796,16383/24 RightBrake=-11342,16383/24 The axes are reversed, so 16383 is the "off" setting. Even a very mild jitter to 16382 will operate the brakes, or even taking your feet off if the springs aren't really really strong. Try calibrating correctly with unused zones at either extreme, exactly as documented. Regards Pete

Sorry, FSInterrogate isn't mine, and I didn't write any documentation for it. Also, 0AF8 is most certainly listed and has been for many many years -- it started in FS2000. I don't use FSInterrogate myself much these days, but I just loaded it up, and I can right-click anywhere on the Variables grid and select "Add Variable". It's the third option down after "Edit Variable" and "Copy Variable". Maybe you are looking at the Interrogate grid instead? ON the Variables grid, the information on the left-hand panel tells me I'm using data which I last updated on 2nd February last year. You ARE running FSInterogate2std.exe I assume? Regards Pete

Sorry, I can't really make a true comparison. I'm using FSX and it's a long time since I used FS2004 on a network. That's for first time -- it is fast when the initial housekeeping is over, right? What exactly is the problem you want to resolve? If it runs okay when it is running, what is the worry? I really don't know. Did you do the full log and plough through it as I suggested? It tells you exactly what WideCloient is getting up to. Regards Pete

Might be a good idea to install 4.667 so we can compare things like with like. But the log entries: 1254233 *** TOE BRAKE AXIS, Left set = 0 1254233 *** TOE BRAKE AXIS, Right set = 0 only occur with FSUIPC calibrated toe brakes. They don't appear in my log, as you see, because I had no toe brake movement or jitter. It certrainly seems like you have axis inputs for the brakes and it is they which are doing this. Could you add Event and Axis logging to the log options so we can cross-compare? Also show me the [Axes] and [JoystickCalibration] sections of your INI. They aren't related to ASSIGNMENT, only to CALIBRATION. Maybe you are looking on the wrong FSUIPC Tab? BTW the extra logging of the actual SimConnect values returned, as shown in my log above, is obtained when you use the Monitor facilities, just to watch for changes to offsets. You are logging all IPC writes, which might fog the issue a little in your logging. egards Pete

Yes, but I think that was a change between FS9 and FSX. By then I had already settled on the convention of assigning positive IDs to aircraft injected by external programs, such as that done by AIBridge and SquawkBox, and I had to maintain compatibility rather than force programs to be re-written. Good, but the normal way of programming it would be to use the ID from the TCAS table offsets, exactly as it is with no conversion. Then it would work for injected aircraft too. Regards Pete