Pete Dowson

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

Yes, FSUIPC3 for FS9 and before is a different version to FSUIPC4. Please NEVER publish your Key, or else it will have to be made invalid. Pete

Your choice. In FSX (but not before) the rudder and tiller are separate. FSUIPC's specific tiller control (assigned in the "direct FSUIPC" mode) is a control added by FSUIPC way back before FSX came out with an actual steering tiller control. You can use the FSX version if you wish, and you can assign it in FSUIPC's FS control lists. FSUIPC's one actually use the FS rudder control "under the hood" The special arrangement in FSUIPC's, when both its tiller and the rudder are assigned and calibrated, is that the tiller has 100% control at 0 knots whilst the rudder has 100% at a set ground speed ("MaxSteerSpeed") which defaults to 60 knots. Between 0 and that speed one becomes gradually less effective and the other more effective. The intention here is to simulate more closely the change in the real effectiveness of these two controls, where the pilot actually uses only tiller at slow ground speeds, but on the take-off roll gradually needs to be using rudder. This is all documented in the FSUIPC User Guide, page 40 -- the boxed section. Pete

Well if they are all 8 bit then you would be able to read 64 of them in one go. Mind you, do check for performance impact on FS. The requests to the Gauges system have to be made in the main thread. Or did you mean that they all need 8-byte (64 bit) floating point accuracy? Surely not. The two you showed earlier were for a switch position, no? Anyway, I'll put it in when I'm home -- Monday or Tuesday. It'll be in interim update 4.952. Pete

It was the way you asked, which was not nice at all, and pretty much guaranteed to get an adverse reaction. If you peruse the messages here I try my best to help every one who asks. I will help if you would like to ask specific questions about things you don't understand, but I cannot explain someone else's program anyway. Just tell me what specifically about it is giving you problems. Maybe I can fathom it out, maybe not. It's just that I didn't write that program, I did assume, because it had been used by many others without my help, that it was explained in its thread. Did you look through the thread itself? Maybe your questions were already answered? Pete

FSUIPC can only offer those controls which are implemented. They are FS controls. You could try writing to the relevant FSUIPC offsets instead, using the Offset controls FSUIPC provides.. Pete

Well, a single read before the Process. Ah, you can't. It will only work on the user-assigned offsets, 6C00-6CFF, so 64 bytes.BUT it would be dead easy for me to add a facility to read/write values or different sizes and types, doing the double float conversion internally. For instance, if you know a value is an integer then provide it or ask for it as such. I can use the high word of the offset value for this in 0D6C. So, use the offset 0x0nnnn as now for the full 8-byte double, or: 0x1nnnn for 32-bit float 0x2nnnn for 32-bit signed integer (SD) 0x3nnnn for 32-bit unsigned integer (UD) 0x4nnnn for 16-bit signed integer (SW) 0x5nnnn for 16-bit unsigned integer (UW) 0x6nnnn for 8-bit signed integer (SB) 0x7nnnn for 8-bit unsigned integer (UB) Then you could fit up to 64 values in, depending on their types. Pete

Sounds about right. Process switch, queuing on FS's message list, forwarding to a thread in FSUIPC, message to the gauges system in FS to get the variable ID and then another to get the value. No reason why you shouldn't do multiple write write read sequences before the process, just use separate offsets each time. Didn't you try that? Would save multiple process swiches. As documented, the read is processed before continuing, it's not asynchronous. Pete