Pete Dowson

Except that won't work for the 252 value unless you round up. Well, yes, if you want straight numbers I suppose. They are only fiddled like that to make them look a bit like FS98-FS2002 values, all in the name of continuous compatibility for programs written in those times. Regards Pete

Okay, get 4.754. Last now till at least January 6th 2012. Have a Happy Christmas! Regards Pete

Please see my previous reply. I amended it as you were posting your reply. The numbers are meant to emulate the encodings which were available since FS98 days. The offsets being used (0Exx) are part of the FS98 offsets, so I made them the same for consistency. The wind turbulence is basically 64 * N (N = 0 to 4). I seem to recall that the cloud turbulence in FS98, FS2000 and, I think, FS2002 only had 4 values, not 5 and went 0, 72, 144, 216. The top value i added for Severe should be encoded 252 not 270. I think it does that for the FS98 offsets. I'll check why it's not so limited in the newer "at aircraft level" offset. [LATER] Checked. There's definitely no way it should ever get 270. It's 72 * N with a max imposed of 252. Regards Pete

Where are you getting that error message from? Wwhat folder is ...Files\Lua\5.1\SciTE\scite-debug\scite_lua? That's nothing like anything I provide in either FSUIPC or WideClient. The logic library is built into FSUIPC and Wideclient for Lua plug-ins running inside those processes. What are you trying to do? If there's an error in your Lua plug-in it will show up in FSUIPC's log, or its own log file in WideClient or if you've selected Lua logging in FSUIPC. There's never any need to use an external debugger for plug-ins just to locate a syntax error. Regards Pete

There were changes in this recently. Have you checked 4.753? Is there a discrepancy between what you find in those newly populated offsets and the regular NWI or AWI readouts? Have you checked with the readouts in WeatherSet2? Because the source of the data is the same for both. And you need to log the aircraft altitude as well, please, because the values in those new offsets are dependent on that. [LATER] Hey, there's an error in the way FSUIPC decodes and encodes the turbulence. I think the METAR format definition changed sometime between the original FSX Betas and the releases, because I have them dpcumented as: N - None (default), O - Light, L - Moderate, M - Heavy, S - Severe I seem to remember I thought they were odd at the time, but maybe it was an early bug in FSX which was later corrected, presumably before release. The correct values I see now are: N - None (default), O - Light, L - Light, M - Moderate, H - Heavy, S - Severe which, apart from the two alternatives for "Light" make much more sense. What I can't understand why no one has noticed this before, or, rather, they have but assumed like I did recently that the discrepancies were results of buggy FSX weather implementation. The fix is really very easy. I shall upload FSUIPC 4.754 within the hour. Regards Pete

The only change was to fix the disabling of the mapped throttles, that was all. So what do you mean "it did not work"? What "did not work"? I'm not doing anything to change that -- that was what you are doing, isn't it? Why you wanted to use 310A to disconnect? We seem to be going in circles now. Pete

I assume the driver is writing directly to the offsets or using the specific SDK for those add-on aircraft. Not without knowing anything about what the driver you have is doing, no. Obviously it isn't emulating a normal joystick connection. Can you contact the author of the driver, or get any information about configuing it? If not you might need to get information about Phidgets and reprogram it yourself. An FSUIPC4 registration applies to all versions of FSUIPC4, and you should always be using the latest. Please update. Only if Linda knows about what your driver is doing, which I don't. It's the details of the driver that are needed. No of course not unless your previous registration was for FSUIPC3 which is a different product. You don't need to register again in any case, just install the latest. Pete

The ICAO of the nearest weather station is obtained in any case. I'll store it in offset 0E80 as 4 characters (no zero terminator). It'll be in the next update (4.754 probably), but it may not be uploaded till January. [LATER] Okay, I had to release an update in any case to correct something else (wrong turbulence encoding/decoding), so if you get FSUIPC 4.754 from Download Links you will be able to get the ICAO of the nearest WX station form offset 0x0E80. In Lua read it as a string with a length of 4. Regards Pete

Get FSUIPC 4.753 But re-calibrating with the same axes to the same values does nothing but replace the same numbers in the same places. Are you sure that it isn't simply that your joystick controller isn't providing a valid input until you've moved the levers? Don't they all work properly simply after waggling them back and forth once, after first loading? There's no way that FSUIPC will ever be discarding your previous calibrations. The controller is probably simply asleep initially. This is a common thing to happen, especially if you are allowing Windows to turn off the power to USB devices -- change the Power Management option on every USB hub in the Windows Device Manager to fix that. Regards Pete

Unfortunately it is too unreliable to be useful, often not even reporting the airport your are parked at. Very disappointing. Regards Pete

After some testing here I've found that it isn't really that option which affects it, but the Mapping of the one throttle input to the four throttle outputs. It seems that such mapping can defeat the disconnection facilities imposed via offsets 310A and 310B. Odd that this has not been discovered before. it doesn't apply to FSUIPC3, only to FSUIPC4 and is a result of the need to intercept controls at one level of SimConnect and send them on at another. In FS9 and before it was a simple matter of receiving WM_COMMAND messages via Windows and deciding whether to pass them on or not. Anyway, I have managed to fix it here and will be providing an update, FSUIPC 4.753, tomorrow (Tuesday). Meanwhile did you discover what your problem was with calibrations? Regards Pete

Yes, just assign to Elevator trim set with a parameter of 0. Regards Pete

The User contributions forum? Yes, indeed. And I'm sure others will be grateful, too. Thank you -- you too! Regards Pete

Sorry, I don't know Delphi at all, but doesn't it come with a debugger? If you debugged the program you'd surely be able to see why it is crashing with that bad pointer (FFFFFFF0) and fix it. The error reported certainly doesn't relate to anything obscure like a "memory leak", but a straightforward crash. Pete

Hmmm. I'm not sure why that would let the other throttle values through, though (I'll need to look at that here), but certainly you should only uncheck that option if the aircraft you are using specifically needs it unchecked, which is a rarity. You never have to re-calibrate, unless of course your joystick is going wrong and producing different results each time, which seems unlikely. Why do you think you have to? The calibration settings are all saved in the FSUIPC4.INI and restored when you reload FS. The values you se in calibration are there, readable in the INI. You seem to be reluctant to show me any INI settings so I can't really see what sort of calibration you are performing. Regards Pete

How are the axes assigned and calibrated? How often are you pressing the button? Why is it assigned for press and release? No need (ever) to provide pictures. All the details are in your FSUIPC INI file. Pictures show less and take more space. Regards Pete

Okay. It wasn't too hard. In the process of working out what to do I also found that the facilities for those offsets in FSUIPC4 only worked for the lower three wind and cloud layers, owing to the way they are linked to the old FS98 facilities. Versions FSUIPC 3.998p and FSUIPC 4.752 both include full support for offsets 0E84-0E88 for cloud data and 0E94-0E98 for wind data "at aircraft" no matter how many layers there are. Get the updates from the Download Links subforum. Regards Pete

I wouldn't have thought many users ever initiate macros with keyboard commands. What's the point? All macros in the FS Modules folder are added by name to the assignable controls in FSUIPC, alongside Lua plug-ins, FS controls and FSUIPC-added controls. Where do you get the impression that macros are to do only with keyboards? FSUIPC offers assignments via buttons & switches and joystick axes as well as keyboards, as surely you've discovered? Regards Pete

The bits for throttles 1 and 2 are bits 6 and 7 only. There is no bit 8 in a BYTE value. The mask you need is 0xC0 or 192 (128 + 64). It works for everything as documented. it is used in a lot of serious cockpits. Don't forget you need to repeat the setting every few seconds. If you are operating this action by a button or switch, you do realise that FSUIPC does provide special controls called "throttles off" and "throttles on" which you can use for this, assignable to buttons or keypresses? Considering that the only throttles inhibitable by this offset are #3 and #4 (via the same bits), and that a 737 is woefully short in this regard, I'm not surprised! Don't forget that FSUIPC can only disconnect throttle inputs which are calibrated through FSUIPC. Regards Pete

FSUIPC won't be doing anything different just because you have specific add-on aircraft in use -- unless of course it it different for those because of aircraft specific or Profile settings. If it works fine with default aircraft then the problem really cannot be in FSUIPC itself. Maybe there's some differences in timing which bring out some defect in those add-ons. Jitter will of course cause more data to flow, as also with mapping multiple throttles to one input, whilst filtering would throttle them considerably. So it sounds like those add-on aircraft have some non-reentant code which is being re-entered, causing stack corruption. Without being able to reproduce it here, or at least getting precise data about where it is actually hanging, I wouldn't stand a chance of 'fixing' it. If you can reproduce in with any default aircraft I'd take a look. Regards Pete

Yes, as also documented in the Advanced User's guide thus: GetNearestAirports=No: The facility to populate certain offsets with details of nearest airports has been withdrawn from general use, because it is buggy (a SimConnect problem) and cannot be relied upon. The code is left in and can be re-enabled by 'GetNearestAirports=Yes', but this is only useful for experimental purposes, not practical applications. It may well work in ESP (untested). The ICAO is a string of 4 bytes, so read it as such of course, specifying the length. But if you want the data as well, and since it's a structure of five values, it would be more efficient and easier to read it as such, like this icao, lat, lon, alt, dist = ipc.readStruct(0x0658, "4STR", "4FLT") Maybe you haven't enabled the option? If you also set this into the [General] section of the INI: Debug=Please LogExtras=32 FSUIPC will log all the airport data it gets, which you might find useful to double check. Pete

It might be a little quicker, certainly easier, to refer to the Lua package installed for you into the FSUIPC documents sufolder in the FS Modules folder, as listed in the Install list which was part of the Installation and Registering instructions which came with the FSUIPC installer. The User Contributions subforum you were using erroneously is also full of other examples, contributed by users. If you have any questions I can help, but please note that I am away from 22nd December to 5th January inclusive. Regards Pete

You posted the same thing yet again, in the wrong place! Why don't you please read the answer here and stop forcing me to move or delete duplicates! Pete

Sorry, i have. What was it about? I've scanned the thread a bit but I can't quite make out what it was you wanted now. Your quote from me is about 6 weeks old. Sadly, it is not a good time to remind me of anything -- I have only a couple of days before going away for Christmas and New Year. I suggest you remind me, preferably with details in a new thread, when I'm back -- January 6th 2012. [LATER] Looking more carefully, I think it is these offsets, currently only for FSUIPC4, you want in FSUIPC3 also? 0E84 1 byte Cloud type, 1-10, if the aircraft is in a cloud layer. Otherwise 0 0E85 1 byte Cloud coverage, 0 - 8 "Oktas" or eighths of the sky. 0E86 2 bytes Cloud icing level 0-4 0E88 2 bytes Cloud turbulence level, 0-255 (as for older offsets 0EFC etc). 0E94 2 bytes Wind gusting value (max speed in knots, or 0 if no gusts) 0E96 2 bytes Wind directional variation -- degrees in the same units as wind directions 0E98 2 bytes Wind turbulence value, 0-255, just like offset 0ED2, etc. I'll check later today. Regards Pete

I see FSUIPC4.DLL's entry is now a long way from being the 1st or 2nd! And that "missing" DLL is evidently not one loaded via SimConnect and the DLL.XML, so how is it supposed to be run? You do have a lot of stuff in the DLL.XML. Try renaming it and re-running the FSUIPC4 installer. If things are then okay it may really be more due to interaction with one of the other things being loaded. Also you may have an EXE.XML file which is causing SimConnect to load EXE programs. Check that. Initdelay=10 would make FSUIPC load up pretty much in the exact same was as it did before. Regards Pete