Pete Dowson

No. That was the only thing that I provide which makes WideClient write to those offsets. It should work, I don't know what's changed, but now we've isolated it I will find out and fix it. Thanks for confirming. Pete

The log doesn't show much to me, either. Some weird stuff though ... There were 46 AI aircraft in the TCAS range, all of which provided only their initial positions. Of those 16 were airborne -- 30 were on the ground.. I'll have to check that logging option. Because with airborne aircraft (especially) there could be as many as 4 updates per second EACH, I probably only log the aircraft details when it first appears. I'll have to think of another way which doesn't give huge, really huge, files. Tomorrow, would you run TrafficLook instead of Radar Contact or whatever is sending slew toggle commands to the aircraft -- it seems to be doing it to most of the aircraft, and almost all at once. Weird. It only does this to 4 of the 12 airborne aircraft. But why is it doing this anyway? I'm pretty sure Radar Contact doesn't, at least when I used it (I moved to ProATC/X). To avoid this weird confusion, please only use TrafficLook for the test -- you can run it twice, selecting ground for one and airborne for the other. It will run happily on a network under WideFS if you want. It only reads TCAS traffic aircraft, so it won't send them commands. If I change the logging in a Test version, I'll add another message here with a link. Pete

With a log which shows none of the errors we are trying to debug! So what did you stop ? Were there any WideFS client programs running? I know about that one, though I've never seen it. I don't think it is related to OOM. Pete

Hmm. That's odd. Something else is writing those entries then, from a WideFS client. We'll need to do a process of elimination on whatever is running on the clients (though it could equally be something on the main sim PC -- those offsets are supposed to be for WideClient only, but anything can write there -- weith possibly the results you are getting, because they instigate calls into the sims inner code to get a display on screen). I need the log with the ipcWrites enabled please, at least the first parts where it starts happening, until it repeats. In order to get that log option going when FSUIPC starts, you'll need to enable it then restart the sim. 1579063 (the first error) - 694328 (when the sim is ready) = 884735 which is 88.4735 seconds. I think about 20-30 seconds of that will be WideServer starting up. Pete

Hmm. Stranger and stranger. I can't see how the combination is any different. But I don't think that arose in my tests. I'll have to try again. So does the ground traffic also have to be a "lot less", more than 1 or 2, like you said, or not? Sorry, I don't see that. My results agreed with yours -- no restart if the only traffic were all airborne. I'll see if I can conjure up a situation with a few aircraft on the ground as well as in the air I'm watching the TCAS tble entries using two copies of Traffic Look running side by side, one set to ground and the other to airborne, and the FS Tools facility "Traffic Explorer" for the complete list, including those out of TCAS range. Pete

For the same displays on both the Client and main FS screen? Why both on WideFS? For the latter it would be much more efficient to run VAS Monitor on the FS PC. It's late here, but I'll check this tomorrow. Do you get any of the VAS Monitor display on the P3D screen? I know there's a delay between this 694328 Advanced Weather Interface Enabled and the first error: 1579063 ***ERROR C0000005 at 58257656 ExWriteStateData(Offset=9BFC, Size=4) That's nearly 90 seconds. Is that all WideClient start up time, before it is running the Lia plug-ins? Perhaps you could enable ipc Write logging in FSUIPC's logging tab. That will show me exactly what it received up to the crash. Pete

Well, it's been running now with small numbrers of traffic, but all airborne. I've checked the code and it definitely will not restart scanning unless there is at least one airborne AI but no updates for the timeout period. I've prepared a test version which keeps the airborne counter used to test this in an offset (026C) so it can easily be monitored by a Lua plug-in. But before I supply anything to do al that, maybe you could let FSUIPC log all the AI data it is getting. This will get very large, but when you get the problem it should show exactly why, so you coud stop the sim then and only show me the last few hundred lines of the log. The way to enable this logging is as follows: Add to the [General] section in FSUIPC4.INI these lines. Debug=Please LogExtras= x10000 Pete

So, when the problem happens, are all the aircraft static on the ground and not being prepared or doing anything? In such cases SimConnect will not be sending any updates. However, I think FSUIPC only gets into the "restart" situation if there are airborne aircraft -- but I'll check this. If FSUIPC does restart scanning when there are only unchanging static aircraft, perhaps SimConnect doesn't supply the initial data. Maybe it only supplies such data when the aircraft are first added. If the problem has never happened when aircraft are actually flying, then that is a BIG clue and guides me to what and where to check. After the traffic restart, if SimConnect is not providing unchanging data then, nevertheless, it would start sending data once airborne (or active ground) aircraft are about. FSUIPC's TCAS tables, as used by applications such as Radar Contact, only have a range or max 80 nm (adjustable in the INI and, I think, the Options dialogue). So that's another factor. Programs like SuperTrafficBoard have no range limits. Let me know the answers to these things and I'll look deeper. I've been running FSX-SE for the last couple of hours in a remote part of the world where there are only a few (between 1 and 14) aircraft, but mostly airborne. It is very difficult to force a case where nothing is flying. Pete

Please, in future, at least state why you are attaching a file. It would be much better to just paste the contents into your message. I don't like just downloading files for the sake of it. It looks like you are running some program interfacing to FSUIPC and writing to offsets reserved for WideClient running a Lua plug-in using the display library to get a display on the FS screen. If bad data is written to these it is quite possible to generate Access Violations, in this case probably in the depths of the display code in the Sim or its system DLL. It is to avoid crashing the Sim altogether in such cases that FSUIPC traps such crashes in the first place, logging them instead. So, as with any reports or questions about FSUIPC or problems, more information is obviously needed. What programs are you running? Are you using WideFS? What plug-ins are you using, both in FSUIPC and the WideClients? Please always provide at least basic information. Pete

I have not been able to reproduce it yet. You persist in this misunderstanding. As I keep explaining, it is NOT restarting the scanning which breaks anything. For the restart to be triggered it is already broken. The restart occurs exactly because no traffic information is being supplied by SimConnect, even though it was requested. The restart is an attempt to force SimConnect to start supplying again. I'll continue to test here, but it is very strange. Possibly SimConnect logging would show something, but the file that would produce would be enormous and finding any relevant line there will bre a nightmare. I'll get back to you if I can find anything. From your reports it only happens when there are very few AI aircraft, is that right, or have I missed something? Pete

The version number is clearly shown in my Download Links subforum, above. That's where you find all my software and it is all clearly labelled with notes on changes and so on. I think the "download-window" you refer to is the one Enrico Schiratti has. His window has links to the latest full install -- the files are here, not there. His are only links. I have no control over the text on that page, only the files he links to. With so many frequent sub-versions (current is 4.965) the busy Mr. Schiratti really need not be disturbed. The major part ("4.96" is always shown and sometimes I can get him to update sooner. Please just take it that it always points to the latest -- but for more information, please look here, in Download Links. This Forum i can edit and control. Pete

Yes. You can have as many buttons assigned to any control of facility you like. There are no checks on how many. It's only the other way around that gets a little more complicated -- assigning two or more actions to the same button. That involves editing the settings file (FSUIPC4.INI). But what you want to do is easy -- just assign it in the same way. Pete

Each Bodnar board represents one "joystick" device, so still limited to 8 axes/sliders and 32 buttons. They are relatively cheap though, and very easy to use. Pete

FSUIPC does not include drivers for devices. It relies completely on Windows support for what are classed as "joysticks" in DirectInput, in the same way as Flight Sim and P3D do. So, does FSX see the Pokeys buttons? Does Windows Game Controllers (or whatever it's called in Win10)? If not then for FSUIPC to see it you'd need a driver or some other software to recognise it. If it is a standard HID device (Human Interface Device) on USB, then you could write an FSUIPC plug-in for it using Lua, but you really would need to be a bit of a programmer. I have heard of folks using PoKeys before. Are you sure there's not some implementations you could use around already? Have a look at some other Forums. Maybe Pokeys has a Forum or resource web site? Oh, also try using FSUIPC 4.964f, available in the Download Links subforum. It has some improvements to joystick programming. [LATER] Didn't you try searching the User Contributions subforum here? I just did and found this thread: Don't know if that's useful to you (BTW Lua script = plug-in). Pete

If you've done this recently you will find it is 4.964. That is the earliest supported version. You only buy FSUIPC4 once. All updates since it was introduced in 2005 are included in the original price, and it is best to keep it up to date. I can't support old versions. No, nothing is touched by the install except for replacing the program itself (the DLL) and updating documents and so on in your FSUIPC Documents folder. Updating is easy and only involves running the installer. You don't even have to re-enter your details. Pete

Probably because that aircraft isn't using the normal FS systems. Many sophisticated add-on aircraft use their own systems, not FS's. FSUIPC interfaces to FS, not to add-ons. You'll need to seek a solution from FSL, or just use the facilities in FSUIPC axis assignments to send specific controls when the lever moves through set regions. see the right-hand side of that tab. You can have up to 10 different positions set where flap set controls can then be assigned. You do this instead of assigning to an axis control on the left-hand side. Pete

I see no need for that. There's nothing wrong with having gaps in the numbers. They will get reused when needed. Pete

Yes, because there may still be assignments to them. better to get an error saying that a specific file is missing if you use the assignments -- you maybe have erased or move the Lua inadvertently. No, sorry. It isn't that clever. But just delete the entries you don't want. It won't renumber. If you add more later the gaps will get used -- though added at the end, so the numbers will get out of order in the list. You can sort them if you like, but don't change the numbers. The same sort of thing applies to the list of WideFS clients and the Macro file list. Pete

Well, yes, and I'll be doing some tests along those lines when I can (still tied up here). But the theory is incomplete, because I still cannot understand why restarting the scan doesn't work. SimConnect should first give me the AI current positions, even if they haven't really changed. I'll look at my code too, to see if I've somewhere imposed a minimum level of traffic before I bother! It's a possibility I suppose, though unlikely, and if so it dates back a very long time, maybe to FS9 in 2003/4. Pete

Is the G1000 a standard FSX (or is it P3D?) gauge, or is this an add-on gauge, part of the Flight1 aircraft? If it isn't a standard part of the sim it won't have any FSUIPC / SimConnect controls built in. The only G1000-dedicated FS controls are those listed starting with 'G1000'. I don't know the G1000 and don't know what they all do -- there aren't any specifically labelled for radio displays. They all see to be concerned only with the PFD and MFD aspects. So I assume the radios are really standard FS radios as in any other FS aircraft, but with only one displays for both 1 & 2. I've just looked at the Mooney Acclaim in P3D, with G1000. It has displays for NAV1/NAV2, COM1/COM2, both active and standby and you change the selectopn between 1 & 2 by clicking with the mouse just below the frequency knob. By logging I see there's no controls for that, but by logging L_Vars using the supplied Log LVars lua plug-in I see that there are L:Vars for this, as follows: L:SelectedCom2=0 for COM1 L:SelectedCom2=1 for COM2 L:SelectedNav2=0 for NAV1 L:SelectedNav2=1 for NAV2 So, if you ARE talking about the G1000 supplied with FSX/P3D then I think you will just need macros to send those LVars with parameter 0 or 1. Pete

No,, not really, not without lots of programming. But isn't that the shared cockpit facility built into FSX and, I presume, P3D? I seem to remember such a thing demonstrated by Microsoft at one of the conferences launching FSX way back in 2005/6. Or was I dreaming? I really had little interest in it so never followed it up. It might be a good idea to ask in the FSX forum over on AVSIM, re-phrased of course. Maybe it wasn't even carried over into FSX-SE, because Steam have a different idea of muliplayer etc, so ask about FSX first. Or maybe you need to move to P3D. Pete

I'm not sure why that can happen -- though the 2 with identical GUIDs could explain that I suppose (it is supposed to be impossible), but it certainly sounds like the two button boxes are indistinguishable to Windows, and when you make other changes it re-scans and re-assigns GUIDs. That really wrecks the steps FSUIPC takes to check against this. Bodnar boards used to have that problem -- they were identical -- but now they have serial numbers and are not a problem. Best to set up a configuration, get it working, and leave it be. But, then, if you keep track of the assignments (keep the previous INI when making a change to the devices connected), it would be easy enough to edit the letters assigned in the INI to put things right again. Pete

I'm afriad you'll need to go into more detail that that. See below. GUIDs are supposed to be absolutely unique. It's the guarantee for those from Microsfot for the Windows GUID assignments. The fact that you get two the same amazes me and really does sohw something is rather corrupted in your Registry. In software there is absolutely no way I can distinguish between two devices with exactly the sme names and same GUIDs! It is supposed to be impossible! I suggest that you go remove the button box(es) and go into Windows Device Manager and uninstall them completely, driver included. Then check that there are no references anywhere to them in the Registry, using Registry Editor. Then install them again. Interesting. I've never seen an "odt" file before. I double clicked it and it opened as a table in Word. How do you make one of those files? Oddly, the two with the same GUID don't seem to have the problem. I certainly don't know why the two with the different GUIDs (8013 and 8015) got mixed up -- unless perhaps they are indistinguishable (same serial numbers etc -- use HidScanner to check that) and were unplugged/disconnected/powered off, so that when Windows saw them again it assigned the wrong GUIDs. Also, i don't really understand what the second 8007 was assigned to MIP Switches, but then labelled as New, No Assignments Yet! What's that about? I'd certainly expect some problems with absolutely identical devices being detached or moved about. Windows cannot tell, just as FSUIPC cannot. But assigning two devices the same GUID is absolutely wrong and ruins the whole idea. It suggests something else, deeper, is wrong. Pete

Probably. I'd need to try it to be sure. But C won't be called till B has finished and exited in any case. I don't know off-hand whether the flag to tell it to execute the new event is carried forward till then, but I think it is very likely. It should be easy enough to check. Just use ipc.log to give a message on entry to each. Pete

It isn't really the restart that is the problem. That wouldn't occur if SimConnect was still providing traffic updates. The restart of the traffic scanning is just doing EXACTLY what FSUIPC does initially in order to get the traffic data in the first place. Even if you stopped the restart occurring there'd be no traffic updates in any case -- the restart is just an attempt to recover. I've no idea why it seems to be affecting only FSUIPC (and of course its clients). That is really a puzzle. I've no time ot investigate further today in any case. But I tend to have lots of traffic. I'm wondering if it is related to the fact that you seem to only ever have a few. Maybe I'll test with 12 or less and see what happens, though I can't think what could be causing the non-receipt of data no matter how many there are. Pete