Pete Dowson

The contiguity is not really important, but if you delete entries to which there are button or key press assignments, obviously those will not work. Then if you add more scritps and assign those, the orginal assignments will address the wrong ones. Yes. That was done to allow the internal assignment tables to be adapted for all the "new" (at the time) developments such Macros and Lua scripts without a complete re-write. Sorry, no. You'd need to edit the relevant entries, or delete them and re-assign them. There is no record in the assignments of what the original script name was, so it can't possibly do it automatically. I suppose a utility program, processing the INI file, could do the job, but I really don't have time for such luxuries at present. Pete

No, certainly not. Pete

Uninstall FSX-SE and get it reinstalled after a computer re-boot. That's been known to fix many FSX problems, so it is bound to help with a corrupted FSX-SE. Pete

I'd love that too, but it isn't my site, and whilst I can easily update the files it points to, as I do, I can't so easily get the text changed. I have to write to Enrico Schiratti, a very busy man, and wait for him to update it. If I only updated a few times a year like most products that would be fine, but with all the developments going on with P3D and requests I (perhaps foolishly) accede to from users, FSUIPC is updated much more often, even weekly recently. The best place to check for updates, and especially bug fixes and interim versions (without instller and NOT available through the Schiratti site) is the Download Links subforum here. Sometimes I wish that was the only place, but unfortunately, though a long history, the Schiratti site has become linked to from just about everywhere. I'll have to cut down on updates and only make one or two a year, even if P3D changes or bugs are discovered. Folks are used to waiting for other products, never for FSUIPC -- except when I'm on holday. ;-) Pete

No, I don't think so. I tried running your "own display" script first -- though I had to make the display rather larger to find it! 1% of my display is very small indeed on this PC as FS is just one of the Windows on screen at any time. Both displays worked fine, every time. Anyway, please update your FSUIPC to the currently supported version, 4.962. You never know, perhaps it is different in this area, and it certainly fixes things elsewhere. Pete

Use Profiles, so that FSUIPC switches automatically between different sets of settings according to the aircraft you load. That's exactly why it is for! Pete

It'll probably be the way the GPS in the aircraft works. FSUIPC asks for updated values to be sent whenever the value changes by 0.1 m/s or more. It isn't time related. 0x2B4 is updated when it changes by 0.01 m/s or more, so they'll obviously be more updates for that. Why would you want to use the GPS offsets in preference to the direct readouts from the simulation? Pete

It most certainly is. Please try my TrafficLook utility on your Client PC. That will show you! (Get it from Dlownload Links subforum, useful programs). No thanks. Use FSInterrogate to both read and display raw data. If that looks different to yours you know you are doing something wrong. I'm afraid I cannot help with C# at all. I only know ASM and C (with C++ extensions, but not OOM). However, in your code fragment i only see one place where an offset might be specified, and that is: new Offset<byte[]>(0x3840, 3840) If this sets offset 3840, then that is actually in the middle or a load of offsets containing engine data! Where are you addressing the traffic data? Doesn't C# support something like structures? Your code seems very awkward. The whole point in defining structres is for ease of data access. Pete

Okay, good. Note that 4.962 is now released, with a problem with crashes on exit fixed. Pete

Ah, that doesn't use the TextMenu facility at all. It was purely an example of a Window and was for things like RC only. Pete

Following on from my previous message, it seems that I was wrong. Provided the mask you offer features at least one processor which is also in the Process affinity mask, then it accepts and sets the new ones. Here, I added a little more logging (4.962a, which I'll put on the Download Links forum later today): 46863 ### Changed FSUIPC thread affinity mask from 15 [x0F] to 9 [x09] That was with FSX affinity set to 14, so it appears to have successfully added the first processor, x01. However, I still have doubts as to whether it actually uses it. Not sure how to check that. Pete

I've now tested on P3D 3.4.18 and 3.4.22 (as well as FSX-SE which is what I actually use in any case), and, with the current "textmenu.lua", as supplied in the current FSUIPC Documents folder, works fine with them all. Pending seeing your log with those parameters added, please do check that your Lua plug-in is correct. The only parts you'd normally need to change are the Window positions, in the three "wnd.open" lines, though you might choose a different, larger or smaller font of course. There's also a version which splits long text lines, such as the initial ProATC/X clearance, into multiple lines. Do a search in this forum if you need to use that one, else I have a different one which splits it in up to 3 lines. But, obviously, you need to get it working first. Pete

I was about to re-check the facility here, too, but I just checked back to your FSUIPC log, which shows: 218812 Running in "Lockheed Martin® Prepar3D® v3", Version: 3.4.18.19475 (SimConnect: 3.4.0.0) The latest P3D is actually 3.4.22 (since 2nd Feb). I'm going to have to go back to 3.4.18 to test this in the same version as you. Pete

The FSUIPC Installer automatically deletes those entries, which are caused by a crash on exit from P3D which you may not have noticed. This was all fixed in 4.962 which is the only currently supported version, so please update! Pete

But I suspect that FSUIPC will only be using 5. I think it won't be allowed on cores not allowed for the encompassing process. I might be able to get the actual affinity mask being used back, and log that too, just to check. I'll take a look. Pete

Okay. I can't reproduce your problem at all. I think it must be some interaction between the differrent parts of the display logic inside FS. All FSUIPC does when you execute the "Ask" is call the display function to do so. the capture of key presses is entirely separate, and later, and then each one results in a new disply call to show it again but wtith the keypress added. The characters aren't inserted into an existing disply, the system doesn't allow that. The whole thing is displayed each time. So I don't know how it's missing the first time there, but not here. I'm using FSX-SE, mind, not FSX. That may make a difference. Maybe some code works better in FSX-SE. Otherwise perhaps I need to set my situation up to be more exactly like yours. Pete

I'll try your script here later today, but meanwhile can you try it with the current version, 4.962, please? Pete

Please install the currently supported version, 4.962. Pete

Sorry, but neither of those crash reports actually identify FSUIPC as the cause. The only reason your sim crashes with FSUIPC and not without is very probably because FSUIPC is actively using parts of your sim which are corrupted. So, I think you have a problem with corruption in one or more of your FSX-SE files. The most likely is the weather being loaded. Find the .WX files in your FSX-SE Documents folder (where the flights are, and delete them -- or at least move them out of that folder, as a test. Also delete the "wxstationlist.bin" file, which you'll find in your Users\<your user name>|AppData\Roaming\Microsoft\Flight Simulator folder, near your FSX.CFG file. The sim will make a new one when you load it. The first crash you list looks like a bad AI Traffic File, so also try turning all traffic off. If that fixes it, you'd need to reinstall your traffic program, or if you are using only default traffic, repairing the FSX-SE files. Pete

Strange. I'll double check that. Thanks. But that's not the same as the one this thread is bout, which is only a delay till it is enabled. I'll shorten that in the next update. Pete

Yes. If you cannot find a way to stop it trying to change the log options, and you are still running in via WideFS, you can prevent that by adding this line to the [User] section of the WideClient.INI file: Deny=3400,4 This will be fixed anyway, soon, with a further update. The 3400 bug is in 4.959 too. It is just lucky that it doesn't cause a crash. It corrupts other data instead. I couldn't say what that woulsd result in. It may or my not be harmless. I'd like to resolve the issue with 4.962 before I release any new update, so I'd be grateful if you'd try again, but first add those logging lines as I requested in my message 6 hours ago, i.e. this part: "For more information about this in the log, add the following lines to the [General] section of your FSUIPC4.INI file. Then show me the Log after your attempt: Debug=Please LogExtra=x20" Pete

No, it isn't. That looks like simple a count of reports in different sections. You have to look at the Windows Logs - Application and scroll down to find one marked Error in red and attributed to FSX. It's also the data you see in the original on-screen report when the crash occurs if you select the more info button. Here's an example of a crash report (not one for FSX - I don't have one at present). My red highhlighting. Faulting application name: StandardCollector.Service.exe, version: 14.0.25123.0, time stamp: 0x56f2261c Faulting module name: ntdll.dll, version: 6.1.7601.23572, time stamp: 0x57fd0651 Exception code: 0xc000000d Fault offset: 0x00000000000689f2 Faulting process id: 0x2274 Faulting application start time: 0x01d28233e15aa4b9 Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\DiagnosticsHub\Collector\StandardCollector.Service.exe Faulting module path: C:\Windows\SYSTEM32\ntdll.dll Report Id: 75652d29-ee2b-11e6-ae61-74d435ed54d3 The important lines are those in red. Pete

Yes, I'd tend to agree. But I suppose if you do see that the sim was using one core much more than others, you could remove FSUIPC threads from that core -- even if their load would be hardly measurable (which I think I did say in the first place). I only added the facility because it was an easy thing to do, and I am a big softie! ;-) I suppose the same must apply to that VoxATC DLL. Pete

The text on the website isn't updated for each sub-version, and it isn't my website so I can't easily do much about it. It will catch up. The link will be pointing to the current version, depending on when you used it. Where are the crash details, please? The log is useful, and seems to indicate a corrupted weather file, but the Windows crash details are absolutely necessary. It is they that tells mev what the crash is and where. The problems with weather files (.WX files and wxstationlist.bin) is that they are binary files with no checks applied. This appears not to matter until FSUIPC starts reading the weather, one of its functions for client programs, and any corruption in the files causes SimConnect or weather.dll to crash. Pete

Sorry, that's way out of date and not supported. Please update. I've no idea what "SimA" is, but best to stop it running, or find the way of turning it's requests for extra logging off. At least until 4.92a or later is released -- then I'll have fixed the crashes caused by it. What version of P3D are you using? FSUIPC 4.958 is no way compatible with anything recent. I think it was 3.3 then. Pete