Pete Dowson

Er .. button on joystick numbers 64 to 72 are all VIRTUAL buttons, operating from bits being toggled in FSUIPC offsets. It sounds like you have some program (or Lua plug-in) also reading the rotaries and sending them to FSUIPC as virtual buttons! You most certainly don't want to assign as a real joystick AND as a virtual one! That will mess things up for sure. You must use one or the other, or probably best stop whatever it is you have running which is working the virtual joystick button offsets. So it is a Lua script to blame? Sorry, I don't know anything about PoKeys whatsoever, but if your rotaries are seen on regular joysticks 0-15 then I don't think you have any need for anything else, unless PKeys doesn't give you the fast/slow alternatives. Is that why you are using a Lua plug-in? Ah, that looks like it is based on the Rotaries.lua examle provided with FSUIPC. In that case you must do ALL your assignmetns on joysticks 64-72, not to the 'real' joysticks 10-15. No, there are only 32 buttons on each joystick. There would be 32 on Joy#64 and 32 on Joy#65. You only have 7 encoders, so just 28 buttons on Joy #64. Do NOT also program on Joy#2! To program the fast turn, turn it fast, for the slow turn, turn it slow. You should get different button numbers (on Joy#64) for each. Same the other direction, so 4 distinct button numbers. If you get the opposite results to what you expected you have assigned them incorrectly. Pete

Getting data values from FS involves finding the correct 'offsets', from the Offset list you will find in your FSUIPC Documents folder, then using one or other of the reading functions supplied in the Lua libraries -- again, the Lua Library documentation is provided in your FSUIPC Documents folder. The actual function to use depends on the type of value, from 8-bit bytes to ASCII strings. There is an example in the example Lua zip called record to csv.lua which you will find useful, though it does use rather more advanced features than just simple "read byte" etc -- for efficiency it reads groups of variables which happen to be consecutive in the Offsets as a group in "ipc.readStruct" functions. Of course, that example creates a CSV file, not XML. The latter merely involves a lot more formatting in the output, with appropriate tags and so on. For learning more about Lua itself you'd need to refer to the books on it, or the tutorials and reference text on the Lua webiste as linked in my documents. I have several text books on Lua. Pete

Please update to FSUIPC version 4.954, now available in the Download Links sub-forum. This blocks program changes to the logging, by default. (Install 4.053 first if not already done). Pete

Version 4.90 is very old and not supportable It dates back to May 2013, a full 3 years ago! The current version is 4.953. Pete

Do you have any hardware drivers which may use FSUIPC? I've just been reliably informed, for example, that the Flight Deck Solutions drivers write to offset 3400 in FSUIPC, which is the array of bits enabling assorted logging options. Maybe other software writes there too, probably by mistake. Pete

So, a one-year old version of FSUIPC? I can't tell the version number you are using because you deleted the first few lines. Current version is 4.953. So, with nothing whatsoever changing, you have all these sudden problems? Only hardware faults or file corruption can do that sort of thing. Unchanged software doesn't change the way it behaves on its own. Pete

Well something's been changed or updated recently, for sure. No updates to any part of your setup, at all? Pete

Does that use FSUIPC? What have you changed recently? Pete

I see you also have an ipcReady.lua plug-in running. Please tell me what that is doing. Pete

That only contains normal entries. And for some reason you've dleeted the top few lines which are most important, as they tell me about versions! Anyway, there is nothing there which will ever possibly amount to 24Gb, no matter how long you run it! I need to see some of the extra logging which may be occurring. Please don't delete the top few lines next time! Of those only CAAS and EFASS might be doing it. Can you try without them and let me know? And what about kACARS - ColoniaAir.exe which you seem to be starting in FSUIPC4INI? Pete

Without logging options set the Log is very small indeed. Can you paste a bit of this log here, please, so I can see what sort of stuff is being logged? I have one other report, and I am fairly sure it is due to one add-on which is interfacing to FSUIPC and enabling logging of things like the interface (IPC) reads and writes, which ofr a busy add-on using FSUIPC can amount to very many lines indeed. Please also list all the add-ons you are running, including those on any WideFS client PC, as I might then be able to spot one in common with the other report. Pete

I've moved your thread to the proper place! If you had posted to the support forum, instead of to the FAQ subforum, you would have got a pretty fast response. FAQ means "Frequently Asked Questions" and is a reference place for such. New questions must always be posted in the main Forum first. You are lucky I spotted your message while checking something else there! Yes, it is all possible, and no, there is no specific tutorial on how to do that -- it is one of an almost infinite number of things you can do with a tool like FSUIPC, and it is always going to be very unlikely that someone has written one just for your specific need! However, there are lots of examples in Lua installed when you install FSUIPC. You do NOT have to purchase before reading the documentation available and the examples provided, so why not do a bit of research yourself? You might also find something useful in the User Contributions subforum. Pete

Yes. Do you think you could repeat your request to my Email, please? My system for those is lodged there. petedowson@btconnect.com. Pete

Okay. The METAR strings are correct. The surface wind doesn't have an altitude specification, but a DEPTH, to quote the spec: The upper winds have a BASE altitude, AMSL: So the METARs are correct, surface to 1000m (assuming ground is close to MSL) then layer 1 base 1000m, layer 2 base 2000m. Unless you specify a layer above, the depth isn't specifiable. The SDK notes on this are contradictory -- as well as the above it says: which I seem to recall I believed at first and only found out the hard way that the Altitude was, indeed, the base -- though the top altitude seems far more sensible to me! I have checked the latest P3D SDK documentation too, and it is the same. I doubt that anyone in L-M can fathom out the intricacies of the FSX/P3D weather system. It was coded by an extremely clever young woman who was on a sort of sabbatical from her PhD studies in the US, and who left soon after it was "finished". Even Dave Denhart, the main SimConnect creator and my main contact in MS/ACES didn't really understand the code and never managed to fix any of the bugs found later. It's very impressive, really, that folks doing professional weather programs like ASN and OpusFSI have done such a good job. I wish I could have done as well trying to provide an FSUIPC interface to it all! Pete

These are events which are optionally logged through diagnostic logging options set in FSUIPC4.INI. If Linda creates a Console log withing the FS process, then it's console is the same as the FSUIPC logging console, as a Process can only have one console and everything shares it. If this was the case then ALL of FSUIPC's logging would get into the Linda console too. If it creates its console in a separate provcess, then where is it getting these FSUIPC log messages from? FSUIPC certainly cannot write to another process' console! And if it does this, why? (This wil be a LINDA question, I guess). Pete

I'd need to see the Extended METAR strings which are being written and read back. Simconnect is extremely quirky in the ayering facilities, but I'm pretty sure the METARs are constructed correctly, and interpreted correctly. It's the strange things which SimConnect does which are difficult to work out. The METARs are logged with Weather LoggingI used to be able to explain all this, and even understand my complex code, but we are talking about stuff which was complicated back in 2005/6, and I was a lot younger then! Ah. all I remember is that setting and reading global weather was always a very different business than the station weather, and I think C400 may use the old FS2004 methods. C000 and CC00 definitely are the result of interpreting METAR strings received from SimConnect.and using 'GLOB to write at C800 and 'GLOB' to read at CC00 should be perfectly symmetrical. As I said, it would be easier to see whats going on from the METAR strings, because that's what it all comes down to in SimConnect. Pete

Yes, what line? Please show me your Log. Paste it into a message. And why is LINDA starting a Console with FSUIPC log entries? Pete

Does JoyIDs show the IDs of two X-55 sticks? If so, then it's probably some spurious registry entry. See if joyIDs lets you remove one -- but take care not to remove the real one! (Not sure if there is such a facility in JoyIDs, mind). The only only thing you could try to correct that, if you feel inclined, would be to uninstall the stick -- both of them, if showing -- in the Windows Device Manager, including drivers, re-booting and reinstalling (if necessary -- Windows might pick it up anyway). Pete

FSUIPC doesn't distinguish between different devices, once identified by ID or name, they are just devices. There's nothing to stop it detecting one and not another. That's rather a shame considering your assignments and the use of Joystick Letters to differentiate devices no matter how they connect. The joysticks seem to be recognised okay. I take it the second INI file is the one after the move to Win10? Comparing this section with your original, [JoyNames]AutoAssignLetters=No0=Saitek Pro Flight Combat Rudder Pedals0.GUID={7785B0D0-F2DD-11E1-8007-444553540000}1=Saitek Pro Flight X-55 Rhino Stick1.GUID={63FB62E0-CA3A-11E3-8002-444553540000}2=Saitek Pro Flight X-55 Rhino Stick2.GUID={63FB62E0-CA3A-11E3-8001-444553540000}3=Saitek Pro Flight X-55 Rhino Throttle3.GUID={63FB62E0-CA3A-11E3-8003-444553540000} the ID assignments and the names/GUIDs are the same, so your orinial letter assignments should have worked okay. I would stick with your saved INI if I were you. If you only have one of then, then this shows a registry error, probably caused by the rather flakey and annoying Saitek installers. These seem to cause many problems. The FSUIPC LOG, show only one stick detected. This scan actually scans the hardware, not just the Registry, but it cannot get the joystick IDs that way. FSUIPC uses the same method of reading these devices as FS and P3D, the only thing difference is its reliance on the Windows-assigned ID numbers, so after restoring your INI I would try moving the throttle around, change its ID using the JoyIDs utility -- see the FAQ thread " Fixing joystick connections not seen by FSUIPC ". You can probably just change the ID to a spare one then change it back. I think this helps by fixing the Registry entries which Saitek driver installation seems to muck up quite frequently! Whilst using JoyIDs see if you can also fix the duplicate entry for the Stick. Pete

That's because it simply counts the free space. No way possible as far as I can see. Simple things like Add-In DLLs and GAUges (these are just DLLs too) can be counted, because they are loaded into memory with their own IDs associated -- which is why specific DLLs can be identified on a crash. But those are small fry. Memory that is allocated for their data isn't back-trackable to any specific owner, it has no owner ID attached but is only known by its "handle" (which is its virtual memory address). With scenery and textures and AI and the like it is worse. The system loads and discards them into allocated memory as it wishes. I very much doubt whether any add-on has a specific VAS "footprint" in any case. For instance, how much of a scenery package needs to be in memory at any one time will depend on the exact position, the current view and its zoom, the LOD radius, the complexity slider settings, etc etc. Also there is always a variable amount of use made by scenery packages of standard parts, parts installed with FS in any case, such as World/Scenery and Global/Scenery, Effects and Sounds, To get some idea of a package's VAS usage the only way really would be to test with and without it in exactly the same circumstances. but even then the amount would be conditional on all those settings. This is why Mathijs is very reluctant to even attempt to publish any such thing for Aerosoft packages. It really is an impossible request to answer in any sensible way. Pete

If Windows can't see it, neither can FSX-SE, and neither can FSUIPC. I really don't see any way I can solve it. You seem to have tried the things I would suggest assuming the problem was only that FSUIPC couldn't see it. Maybe your USB system is playing up, or the device itself, though it is very odd that is works UNTIL you run FSX. That makes no sense to me. But the fact that you say it;s intermittently detected in FSUIPC assignments would seem to point strongly to hardware, as does the implication ("recently") that this was okay and had started of its own accord. The device itself is the most strongly implicated as you appear to have two other CH devices which are presumably still working okay? Pete

Please try the attached. But use whatever format values are convenient, not necessarily FLT64. Pete FSUIPC4952.zip

Oh, hang on. I've just spotted a silly typo in my revised code. Sorry ... writes won't work at present, just writing 0 I think. I'll just fix it. It'll still be 4.952 though ... Pete

No, the new facility for any format data works both ways. It would be very remiss of me to do it asymmetrically! And surely if I did so it would say so clearly in my write-up! You can use FLT64's, but then the upper part of the offset value in 0D6C must be zero. What's "foo_value" and "foo-set"? Strange names! Pete

Okay, it's done. 4.952 will soon be available in the Download Links subforum. [LATER] Something's wrong with the Forum at present, and I don't seem to be able to change the Download Links. I'll keep trying ... but meanwhile it's attached instead. Pete Attachment revised a bit later, next day: FSUIPC4952.zip