Pete Dowson

No, it certainly is not. Bit 0 is actually a bit, a part of a byte, and you have no bits at all set in the value 0x0000. Zero is zero and contains no bits to "AND" with at all! Bit 0 has the value 0x0001. Please go to the FAQ subforum and look at the thread about bits and numbers. Pete

My editor (Ultraedit) has line numbers on the left. Line counting is easy if you have the file. Line 1 is the first, line 2 is the second, and so on. every line counts, and the line numbers increase numerically, one by one. So, if your editor doesn't give line numbers, just count them. I know 30 is a rather big number but it isn't that hard, and that's really the best way to locate the place it thinks is wrong. Why are you downloading Lua versions? FSUIPC has Lua built in, as you must surely know, you don't need other parts unless you are being very ambitious. If you simply want to learn more about the syntax and rules of Lua there's the on-line reference (though if you want to do a lot of Lua work buying the book is much better. Actually there are several). The reference guide is at the link I provide in the FSUIPC Lua package documentation, or just Google "Lua". It'll take you to www.lua.org, and all the documentation you might wish for is selectable by clicking "documentation". No, I meant, as I definitely said, that if you don't actually assign a value to panelset it will have no value (i.e. 'nil') -- if it has no value your instruction: ipc.display("lat="..lat.."\nlon="..lon.."\nalt="..alt.."\npitch="..pitch.."\ bank="..bank.."\nhdgT="..hdgT.."\nhdgM="..hdgM.."\ vs="..vs.."\nias="..ias.."\ntas="..tas.."\ngs="..gs.."\nmach="..mach.."\nPanelID="..panelsel) will fail because you cannot concatenate a nil value! As your program currently stands, if you did the "if" statement correctly, the only time panelset will have a value is when panelid == 3. When it isn't 3 your line displaying things will fail. A "default value" means a value used when none other is assigned. (This is a very common use of the owrd "default"). You could use a blank string: panelset = "" or something explicit panelset = "don't know what panel it is" but you really need to assign something to it till fill in the case when the panelid isn't one you expected. There isn't such an instruction in the program you posted therefore it can't do it. Regards Pete

This is NEVER true: logic.And(value,0x0000) ~=0 If you AND something with zero the answer is ALWAYS zero! Pete

That needs to be if panelid == 3 then To compare you have == for equals, ~= for not equals, and the usual >= and <= and < and >. "panelid = 3" as an assignment. The error in in line 30. Which is line 30? Note than "panelset" isn't set to anything (so will be 'nil') if panelid isn't 3. You should define a defalut value for it earlier. It needs to be a string or number to avoid a failure later. Pete

That'll send the same keypress each time you operate the switch. If it is a momentary press button then best not to assign anything to 'release; or it'll be sent twice. [LATER] I just realised you said you did NOT have the "key press not to be held" option set, so you are holding the keypress. Why? I need the log as I said if you still need help. Pete

Saying "latest" is no good. Folks have said that before and been using a year old one! This is why I always need the NUMBER. It isn't difficult to find -- it is shown in the main options tab, it is shown in the properties (right click on the DLL), and it is shown in the log files. uckily, because I also put it (these days) into the INI file I see it as "4928", but please remember to quote it next time. Huh? What are you trying to use the range assignments on the right-hand side of the axes tab for? Did you not read any part of the User Guide at all? The specific range assignments facility is there to allow different things to be sent at different points on the axis range, and even different things when moving the axis up or down. It allows things like switches to be thrown, keys to be pressed, offsets to be manipulated, even plug-ins to be handled. It is NOT an axis assignment facility for normal axis operations at all! One of the main uses, and the example given in the User Guide, is for a Gear Lever, to send Gear Up and Gear Down switch controls based on the movement of the lever. Do NOT try using it for simple assignment -- that's the whole point of the main section of the axes tab, on the left hand side. If you'd perused the User Guide you'd have seen this. You are using ENTIRELY the wrong facility! The left hand side provides different methods of sending the controls and drop dwon lists of all of the axis assignable controls to assign to. Furthermore, you say you have the throttle assigned in FS as well! Why? You must NEVER EVER have the same thing assigned in both FS and FSUIPC! You'll ALWAYS have conflicts if you do! I suggest you either delete the lines I show above, or maybe just delete your INI file and start again. And before doing anything further in FSUIPC please read at least some of the User Guide, especially the axis assignments chapter. Or else stick to assigning in FSX. It looks like you are doing in any case, so why are you messing with the assignments in FSUIPC as well? You can still calibrate in FSUIPC with FS assignments. For simple applications with only one controller that's probably the best option in any case. Regards Pete

It sounds like you are getting a shift key (shift, ctrl or alt) stuck 'on', so modifying other keypresses. Are you assigning the switches to "press and release"? If so then FSUIPC will certainly be sending the KEYUP messages a little while after the KEYDOWN ones. Maybe the 747 or MD11 coding somehow inteerferes with this. If you are, by mistake, assigning instead to just "press" then the keys will certainly be left pressed. If that's your mistake then it is easily rectified. Just assign to press and release instead. Use the Key/Button logging facilities to see what is going on. (Logging tab, one of the checkboxes on the left). If you (temporarily) run FS in Windowed mode and enable the console log (same tab) you can see what FSUIPC sees in real time, whilst you operate the switches. If you can't work it out, show me the log of you operating the switches, and then later trying to use the keyboard for other thngs (in FS), and also show me your settings (the INI file). You can paste the contents of these things into a message here. Regards Pete

Where are you reading the -2640 to 2640? As the "IN" value? Have you assigned to the single generic throttle? Without knowing your assignment it is difficult to know what you are doing from here. Assuming you haven't scaled the axis value in the axis assignments section of the FSUIPC4 INI file (something which would need some editing of the file), then there should be no difference at all between the value seen in the axis assignment screen to that in the calibration screen. In fact if you used the "FSUIPC calibration" assignment instead of the FS control assignment, then it is a copy, directly from one to the other. If you used an FS control then it is possible something else is scaling it, though I've never heard of anything doing something like that. You've really not provided enough information for me to help further. Maybe the best thing is for you to paste the contents of your FSUIPC4.INI filer into a message here -- you find it in the FSX Modules folder. Oh, and please ALWAYS state the version number of the FSUIPC4 you are using. Regards Pete

That will make absolutely no difference at all. The only reason the Installer looks for the CFG file is to make sure it puts or updates the DLL.XML file in the correct place. If your FSUIPC is getting loaded, as it must be if it appears (whether registered or not), then there is no problem with that folder. Do NOT delete and CFG files -- they are completely irrelevant. I did not ask for any install file. The Install log shows everything installed okay, but I had assumed that from what you said. The answer might be in the FSUIPC4 run time log, which is what I asked for -- it is called FSUIPC4.LOG (no "Install" in the name at all) as I already said. Pete

Unfortunately, WideClient doesn't really know that FSX has crashed. It will be constantly trying to reconnect. There are ways you can detect the disconnection. First there's offset 333C. Bit 1 there should get reset to 0 on a disconnection. But in case it is a temporary interruption, best to check that it stays that way a while. Second, there's the FSUIPC activity counter at offset 337E. Just check that this changes within reasonable times. You could also check things like the elapsed time offset, to see that changing, but the above two should be okay. Regards Pete

Does this "EMT" thing, whatever it is, rename the Prepar3.EXE file by any chance, or change its version number? Please show me the log file from a session in P3Dv2 (FSUIPC4.LOG, from the Modules folder). You can paste its contents into a message here. Please close P3D first. Pete

You need to write code to do that -- eg a Lua plug-in. You need to refer to the Offsets list (a document installed in your FSUIPC Documents folder) to find out how to send stuff for display -- look at offserts 3380 and 32FA. Pete

Oh, I see. Yes. You'd need to use the offset range I added to support my PFC driver -- 3BA8 onwards (please use 3BAA for elevator, as PFC does). Note that you then assign in the axis assignments, as usual except you'll need to select the "RAW" option, otherwise FSUIPC assumes a 0-127 range. Pete

Yes, perfectly. No, it isn't really correct, because the calibration operates on the Elevator assigned control, not on the raw axis value. If you send the axis value to an offset then it never gets near the calibration part at all, and you bypass it again by going direct to 0BB2. The way to do it if you want FSUIPC calibration is to disconnect the elevator axis by using bit 0 in offset 310A -- remembering that this needs refreshing every few seconds. Then you can read the calibrated elevator value in offset 3328, which you can then adjust before writing it to 0BB2. That can all be done very easily by, for example, a Lua plug-in. i don't know if SIOC has all the necessary options though. Sorry, but I don't really understand this bit. Regards Pete

The SDK isn't updated very frequently. The update information is instead included in the History document supplied in the package, and in the "Changes" document from there on. Not sure why that should be -- I have lots of utilities compiled with the same library. What language is this with? My stuff is all C. I only know C and ASM, so all the other packets are supplied by other users and generally unmaintained. For C the source is provided in the SDK so it is easy to both debug and correct if you need changes. All that code is on the application side of the SDK. Of course not -- that value is in 0E88 as I pointed out, and showed an example of earlier. (I've no idea what happens when you have both cloud and wind turbulence -- maybe the greater takes precedence, or maybe they are added. I'm not presuming one or the other). These are provided in offsets already for FSX. I'm no longer interested in updating FSUIPC3 -- it's for an 11 year old product! FSX is old enough, but at least it is now coming into its own with today's hardware and really good add-on sceneries, weather programs (ASN is fantastic), and aircraft. And the future is P3DV2 with maybe a 64 bit version in due course. I'm afraid FSUIPC3 is frozen. Sorry. Well, good luck. It's a great shame you are not applying your talents to FSX which would really be of much more interest and future use. Incidentally, ASN places clouds precisely and provides files mapping them and files providing proper WX radar data (precipitation/water density rather than just cloud maps). It also performs its own turbulence simulation, suppressing FSX's (much like FSUIPC4 does if its wind smoothing is enabled). Regards Pete

Okay, I've just run FS9 and can get values reported in those offsets very easily. I think either you are using an old version of FSUIPC or you are making some mistake in your code. All I did was load FS9 up with the aircraft on the ground, went into the weatrher dialogue and selected the major thunderstorm theme. Immediately the wind turbulence offsets were populated, as proven both in FSInterogate and using FSUIPC's logging (just put 0E88, 0E94, 0E96 and 0E98 as the four monitored values on the right-hand side of the Logging tab, all as type U16, and check "normal log" and, if immediate feedback is required, Advdisplay for a screen display) Here's an extract from that log when still on the ground: 1100867 Monitor IPC:0E88 (U16) = 0 1100867 Monitor IPC:0E94 (U16) = 28 1100867 Monitor IPC:0E96 (U16) = 1820 1100867 Monitor IPC:0E98 (U16) = 128 these corresponded to the reported surface winds at the aircraft: 1000762 Results: FS98 Wind0: ground (256ft) to 3215ft AGL, dir 331M, vel 18, gust 28, turb 128 Slewing up into the cloud layer: 1123909 Monitor IPC:0E88 (U16) = 252 corresponding to the lowest cloud setting reported: 1000762 Results: FS98 Tstorm: type=10, from 1896ft to 15020ft (+/- 100ft), cover 8, turb 252, ice 0 Slewing up further, once out of that surface wind layer (ie > 3215 feet AGL), the values returned to zero: 1129416 Results: FS98 AmbientWind at PlaneAlt=3543: dir 315T, vel 22 1129416 Monitor IPC:0E94 (U16) = 0 1129416 Monitor IPC:0E96 (U16) = 0 1129416 Monitor IPC:0E98 (U16) = 0 Seems to me to work perfectly! Pete

Well certainly FSUIPC can't swap letters around. No way. And changing hardware connects can't do anything in any case -- that's the whole point of having the lettering. The names and GUIDs identify the devices correctly wherever you plug them in. Seems it will remain forever a mystery. I surely already explained to you exactly what to do. Remember? W way back I said to swap the C's and D's over in the [JoyLetters] section. Only 4 characters to change, it can't be that hard can it? What's so difficult? Here, I'll even change the lines for you: The lines now: C=Saitek Pro Flight Throttle Quadrant C.GUID={4526EAA0-89AE-11E3-800A-444553540000} D=Saitek Pro Flight Yoke D.GUID={53D63970-89AE-11E3-800B-444553540000} The lines after editing them: D=Saitek Pro Flight Throttle Quadrant D.GUID={4526EAA0-89AE-11E3-800A-444553540000} C=Saitek Pro Flight Yoke C.GUID={53D63970-89AE-11E3-800B-444553540000} See? Isn't that easy? I would have thought you'd have done it as soon as I mentioned it! No way that either FSX or FSUIPC can change those over. Sorry, you are absolutely mistaken. I don't know how it happened, but there is no programming in anything of mine that can do it, and FSX doesn't know anything about these files. Pete

As far as I know those offsets work fine in FS9, though they were really developed in FSUIPC4 for FSX and "bolted" back into FSUIPC3 at a later date. I've had no feedback that says they don't work, but perhaps you'd better clarify exactly which version of FSUIPC you are using. You say "3.9" but if that isn't just an abbreviation for 3.999z8 or 3.999z9, then you are way out of date and this may explain it. Those offsets were not supported until 3.999, released in February 2012. Hmmm. In that case what about cloud turbulence too, a MUCH more common phenomenon. The wind turbulence is rare -- CAT (Clear Air Turbulence can occur at high altitude, and you might get turbulence in surface wind layers is certain circumstances. But cloud turbulence occurs in many cloud types. That's offset 0E88 which you didn't even mention. Also, the problem with cloud turbulence readings is that they really only apply when you are IN the cloud, but you can't tell when that is so -- if you have "few" or "scattered" clouds there are places where the aircraft is not in the clouds and therefore would not suffer turbulence. So, I still come back to the wind vectors. Isn't it better to detect turbulence by fluctuations in those? Regards Pete

Okay ... so that last report wasn't really about WideServer not starting, but about WideClient not connecting. Glad you sorted it. Pete

No, I'm not saying that. You asked: and the main part of my answer was explaining that you never actually get "values without any modifications, as this values was set in FS dialog". Did you not understand that part, that the weather varies across the entire simulated world and is changing all the time? Since you previous statement to that implied you wanted to do something regarding aircraft performance I naturally assumed that the actual wind vectors at the aircraft would be the most important. I can't see how the rather crude values about levels of turbulence and so on actually set in the FS parameters, rather than the values actually emanating from these, would be of use in computing any sort of performance figures. But still, if that's all you want -- what is precisely your problem with using offsets 0E94 etc, or those from weather "at aircraft" read using the NWI offsets?. It is dynamically changing. The initial settings only enable it to generate the starting conditions at each station, as I said. You can use any of these methods. Since you know about them, WHAT exactly is your real question? You seemed to come here asking why the values provided are not equal to the values set in dialogues or by the weather program, and i explained that. What else is it which concerns you? I don't understand what it is you now want to know. Pete

Is this a new problem? Are you now saying that the "InitDelay=30" change doesn't work after all? Note that there is no "problem with WideServer". The problem is MUCH worse -- FSUIPC is not actually starting its services to anything, not only WideServer. It can't do this because SimConnect is rejecting all of its requests with "too many requests". FSUIPC knows nothing whatsoever about anything you do in loading flights or changing aircraft or airports. All it is dependent upon is receiving information from SimConnect. I suspect that what is happening in the situation where you are changing things is that the 30 seconds has by then elapsed and your changes are causing Squawkbox to do its thing again. Howeer, I can't really tell what is going on without information. I explained what I thought with the earlier logs and so on. I'm sure you can look at them now yourself and work it out. Pete

FSUIPC never removes settings. It looks like you've got some older copy installed from somewhere? Certainly FSUIPC itself wouldn't have done it, it has no code to do deletions. I hope you have a backup. Pete

What context? Are you talking about FSUIPC? There's no "default" tab in FSUIPC so I'm confused. If you mean the Defaults button on the main About tab, that merely sets default weather and miscellaneous options, it doesn't touch any assignments or calibrations. What's "default mode"? FSUIPC certainly has no "default mode" for anything to do with axes, keys, buttons or calibrations. Pete

What's STRG and why 17? I thought you'd asked your last question? Pete

1071 presses the key and keeps it pressed! You'd need to use 1072 at some time after to release it, otherwise it will be "stuck" and not re-usable. Pete