Pete Dowson

I think when you ask Windows for such information, it has to go into a loop adding up the memory for each individual block, and also remembering the largest. If may even concatenate adjacent free ones at the same time, but I'm not sure about that. I might consider putting the OOMcheck facility into a separate thread. I'm not sure that will help, though, because I suspect Windows has to freeze memory allocation (and freeing) while it counts up, and that probably freezes the whole process. Pete

Okay. Yes, it most definitely is a bug in L-M. Not sure why it affects the sorts of METAR strings you are sending and not those that FSUIPC and programs like Active Sky send successfully, but I think it must be due to something not abiding by the "rules" for the strings set out in the SimConnect SDK documentation. I'll report it to them saying if the string is in error then the erroneous parts should be ignored or signalled in the log, but should never cause a crash. Meanwhile, I think it would be a good idea to examine your METAR strings in relation to the documentation. It may just be that whereas FSX is lax in checking, ignoring errors, P3D is checking -- but then going wrong when it finds an error. Of course it shouldn't crash, that's a bug, but if you want to find a solution meanwhile, check against the documentated allowed formats. I might try to do this too. Pete

Ah, 10 seconds is a good clue. There's nothing requested from SimConnect which is that long an interval. Try disabling the OOM checking. That asks Windows to supply the free memory and the maximum free block every 10 seconds. You can change that using the "OOMcheckInterval" parameter (it's in seconds), or disable it altogether using "OOMcheck=No". The only other one is the broadcasts by WindeServer to tell clients it is there. You can turn that off in the [WideServer] options with "AdvertiseService=No". If you don't use WideFS that won't be happening anyway (and your default INI won't have it enabled in any case). Pete

Ah, I forgot you said it was okay in FSX. So that does indicate that it may be a P3D bug. I'll use your strings here and what response I get. If it looks like a P3D bug I'll report it to L-M. Pete

First of all please update to the currently supported version, 4.96. What do you mean "many before the write"£. What do you do with the strings that you don't write? This makes no sense to me. Anyway, I don't think your strings are in the correct format for sending to SimConnect. It doesn't use standard METAR notation, but a variation of it. You need to refer to the SimConnect SDK details for the correct formatting. I'll try to help when I have some time. Maybe I can correct one of your examples for you. But another way would be to examine the SimConnect log file with a working weather program running, or just when using FSUIPC's own NWI weather interface, which does the conversions into the correct format for you. If you use the FSUIPC facilities the Weather Logging in FSUIPC's Logging options will show what it is writing, (and reading) in the FSUIPC log file. Note that the SimConnect reading and writing formats aren't quite the same. They are very different for upper wind and temperature layers, for instance. Pete

What are you using FSUIPC for? What is does depends on what it is asked to do. What is the frequency of these "longer frames"? (Sorry, I can't read the data on your pictures. Why didn't you simply cut and paste the text?) FSUIPC is receiving changes to the data is provides to applications every time it changes, and the timing of that is up to whatever changes the data. Obviously things like the time changes every second, so that's one data item per second. When flying many things are changing much more, many at least every frame. FSUIPC asks SimConnect to send data when it has changed by a certain amount, or more (the "delta" in order to cut down -- after all many values aren't needed on every miniscule change. This has been finely tuned over the years to give the best results in terms of both performance and smoothness. To discover if it is SimConnect supplying data which is worrying you, try enabling SimCcnnect logging and see if the log timings match your occasional longer frames. Take care, a verbose SimConnect log gets very very big! The only other things done would bt button and joystick axis scanning, but with a default settings file that won't be happening as there will be no assignments. BTW whenever you submit a question or problem I need to know the VERSION numbers of both FSUIPC and FS! Pete

As I said, I never had success over wireless either, though they did connect, with difficulty. The problem is that WideFS needs continuous connection and you often just don't get that with wireless. It's okay for most ordinary data access. It isn't the capacity which is the problem, just the continuity. Did you ever test it with a wired connection instead? Pete

No, not possible. FSUIPC4 is a 32-bit DLL and cannot be run as it is in a 64-bit program. The possibility of a 64-bit version, a NEW product which would be called FSUIPC5 and require new registration codes, is being considered, but there will be no decision for some time, and certainly not until after any 64-bit version of P3D is released, if ever. (And probably well after, as it would not be a trivial development). Pete

I don't know. FSUIPC does the same thing in both cases -- the code isn't different between the two. Maybe you've found another bug in P3D. What version of FSUIPC are you using? Can you show me the string you write to B000? Maybe I can try it here. If it is a P3D bug it needs reporting to L-M, but let me verify that first. Pete

Sorry, they were not attached. And in any case I don't know what the problem really was as you haven't explained in in this thread so far. I assume this part: is saying you had assignments to those keypress sequences combinations (s+c means Shift+Ctrl, I assume, not s then o then v or C, which is also possible), but I've no idea what this part is about: Pete

You must mean 32FA, which is the trigger. Writing to 3380 does nothing except set the text to be written. Pete

Thank you very much for the kind words. It is very much appreciated! Pete

Please update FSUIPC to 4.96 in any case. It fixes a lot more and works better. Pete

How then would it know what number to limit it too? Isn't it clear in the write up that it's the actual limit, with only 0 turning the limiter off? I'm not sure what you thought it could do without having something to aim at? Pete

88? No, PM has hundreds! Where are you looking? Just the offsets status list? Those 88 are in the FS98 area. There are loads of reserved offsets in the extended area (FS98 only had 8192 altogether). many of which are specifically for PM. I don't document 3rd party offsets, sorry. I forgot to mention. You need the PM offsets document. (The same applies to most of those offsets assigned to 3rd parties -- the document them themselves. Ah, I just looked. you can only view the PM documents on their site ( www.projectmagenta.com) if you register and log in. sorry. Let me see ... ... yes, 5400-5FFF all appears to be reserved by PM. Not sure how much they actually used. Pete

Oh dear. You have TrafficLimit=1 that says no more than 1 AI aircraft!!! I use 200 or 250. Why do you want it set to 1? Pete

Please try version 4.96, just released. It works fine here. Incidentally, no problem with the Limiter removing ALL traffic was ever reported, so I'm not sure what you mean by "still broken". The problem in several interim releases was that it said it was deleting traffic, but in fact wasn't, it was only counting deletions which didn't actually happen. That was fixed in one of the interim releases (the final test version sent to those reporting problems was 4.959v, so you can see that a lot of different tests and reports occurred since 4.959n). And what do you mean by "my settings"? I've been adjusting them a lot since my early postings. The proper documentation now just advises adjusting to your specific needs, experiment! Pete

Two other points: 1. [Window ...] sections in the INI are only written once when the Window is started, and once when it is closed, which is only at the end of the complete FS session. When it appears to be closed during the session, it is only made invisible. 2. The title is set when the Window is first created, when you do the first multi-line write to 3380 / 32FA. It is never re-created until the next session, and the title is never changed once set. This is actually stated in the documentation for 6D60. Loading a new flight will neither re-create the Window nor change the title. I just noticed this. Do you mean FSUIPC4.INI? There's no CFG files used, and FSUIPC.INI would be for the FSUIPC3 version, in FS2004 or before. If you are using FS2004 I'm afraid I can't really test what you are doing again as I don't have that 14-year old sim any more (and not for years). FSUIPC3 stopped development quite a while ago, though it did have a long overlapping period with FSUIPC4 (which has itself been going now for 12 years!) Pete

There's no !1=], !2=] etc text in FSUIPC. It looks like you are setting 06D0 every time and with a different string. Have you made sure there's a zero at then end of your title string? The ! prefix is usually attached to a line in the INI file when it isn't a valid line for a Windows Profile file (INIs and CFGs), so it might be just the n=] which is originally written, and the ] on its own is invalid. I need know the version of FSUIPC, please (ALWAYS needed), and it might help if you showed me the fragment(s) of your program which write to 6D60 and 3380. What sort of things are you writing to 3380? Pete

Yes, but was that also true in FS2004? Maybe. I'm afraid I no longer have an FS2004 installation to check. Pete

No, it isn't. There's nothing in FSUIPC which knows or can detect which files supply AI Traffic. You might get a way of doing it over in the MyTraffic forum, or else on AVSIM's FS forums. Pete

If you are not using Project Magenta, then the offsets reserved for it would be usable. Pete

Ouch. Sorry. The link needs editing -- it doesn't say "q", that's only the text shown. You could have copied the link to your browser where it would show the full path and there edited yje p to a q. but never mind, I'm up to 'u' now. See my email response to yours. Pete

With a default aircraft? It's odd that the log does log the sending of the Arm controls, but not their receipt. It is most defitinely and indication that they are being trapped somewhere -- the PMDG code, most likely. Have you tested with the same assignments in FSX? BTW even if the Arm set had been set, it would soon have been cancelled by an immediate further input from the spoiler axis.. Look 35896 [Buttons.PMDG 737-800NGX PMDG House Winglets] 13=P1,20,C66066,0 35896 FS Control Sent: Ctrl=66066, Param=0 35959 *** AXIS: Cntrl= 65786 (0x000100fa), Param= 0 (0x00000000) SPOILERS_SET Also, the fact that the button was relessed within 2 seconds of being oressed seems odd if it truly is a toggle, as you say: 37893 Button changed: bRef=0, Joy=1, Btn=20, Released 37893 [Buttons.PMDG 737-800NGX PMDG House Winglets] 14=U1,20,C66067,0 37893 FS Control Sent: Ctrl=66067, Param=0 Don't the spoilers work with that aircraft if you calibrate them in FSUIPC? If they do I suggest you try to calibrate the arm region (the two centre values), then, even if that doesn't work, it shouldn't interfere with the Arm control settings, if they could ever get through. Also it would be worth investigating whether the PMDG aircraft has its own dedicated "custom controls" for spoilers. Have you looked? The controls will be listed in the NGX SDK folders .h type file. [LATER] I just found an old copy I had long ago of the .h file i mentioned ("PMDG_NGX_SDK.h"). It does list appropriate controls: #define EVT_CONTROL_STAND_SPEED_BRAKE_LEVER (THIRD_PARTY_EVENT_ID_MIN + 679) #define EVT_CONTROL_STAND_SPEED_BRAKE_LEVER_DOWN (THIRD_PARTY_EVENT_ID_MIN + 6791) #define EVT_CONTROL_STAND_SPEED_BRAKE_LEVER_ARM (THIRD_PARTY_EVENT_ID_MIN + 6792) #define EVT_CONTROL_STAND_SPEED_BRAKE_LEVER_50PCT (THIRD_PARTY_EVENT_ID_MIN + 6793) #define EVT_CONTROL_STAND_SPEED_BRAKE_LEVER_FLT_DET (THIRD_PARTY_EVENT_ID_MIN + 6794) #define EVT_CONTROL_STAND_SPEED_BRAKE_LEVER_UP (THIRD_PARTY_EVENT_ID_MIN + 6795) These are pretty obvious in their purpose too. The ARM one probably takes a 0 oarameter for off and maybe 1 for on. But some of the PMDG stuff uses mouse click codes, also defined in that document. I would guess the first (LEVER) sets a defined value, provided by parameter, but it may be by mouse codes.. Note that in practice, though, the speed brakes is normally either down, or in flight mode or fully deflected for landing. Pete

Try just one thing for me, please, just in case. You might have noticed that I had "\n" as the new line code in my last effort. Can you try "\r" again instead, please? I think either should do, but it's a "just in case". What I certainly don't understand is why you get two copies of each line. I don't think that's my code, It looks to be seeing two copies. If my splitting code isn't working you'd only get the one unsplit line. Pete