Pete Dowson

On my system, with no complex aircraft but a large amount of AI Traffic and very busy airports like Heathrow, FSX-SE is a clearly better performer. But probably not the original FSX-ACC -- I found FSX-SE far better than FSX and switched pretty quickly. However, P3D is better looking and CAN be smoother if set correctly. I've recently made some substantial changes to my system and will be doing the comparisons again. with the 200 degree FOV screen I now have (by NatVis), the superiority of the P3D visuals is very desirable. Pete

Thanks for helping Paul. Just a couple of clarifications: First the offset for the ipc.readSW is wrong. it is NOT 366 (decimal, but 0x366 (i.e hexadecimal. ALL offsets are documented in hex. If you want to use decimal then it would be 870. Your code, Paul, is otherwise good but it would be a little simpler with the "else if gnd == 0" as a simple "else". Though since the standard convention for boolean variables is that any non-zero is 'true', whilst 0 is 'false', so the test should be for 0 first, then just "else" for all other cases. That's the 'safe' way. Sorry it isn't specific in the docs, but a delay of 0 is the same as omitting it -- it means no delay is applied, the message stays on display till replaced or cleared by a null string. Yes, you used the wrong offset. See above. Pete

I understand the reasons for an autosave. I was thevfirst to implement such a facility a long long time ago. But I don't think it is a good idea for some of these aircraft which do freeze simulation in order to take copies of all the information to create the files. The larger number of files also is a factor, especially if you don't use fast SSDs or have a crowded disk. I hate having to do that too. I maintain both FSX-SE and P3D systems with many addons, and I dread ever having to do a complete re-install. Worse still is having to reinstall all of Windows. I bought a new PC last November and it took me well over a week just to get it fully set up the way I liked things with my utilities and support and diagnostic programs, even before starting on FSX-SE and P3D. This is why I put off upgrading machines for years after they are well superseded by better and faster tech -- and unfortunately I demand more and more performance! Pete

I can only suggest you use the L-M P3 support forum. The control is provided, maybe they have not yet implemented its mechanism. If it is usable I'm sure they will describe how to use it -- unless it is for their internal use only, which seems unlikely. Pete

I can only think that there are additional optional parameters which can be entered to give each group an ID. Either that, or the viewgroup names are equated to ID numbers somewhere, like the main views were in FSX. I have you looked all this up in the L-M documentation on-line? Maybe that file is defined in full somewhere in the SDK? Pete

Hmm. Well, in that case you can really only try uninstalling and reinstalling P3D and (presumably) the FSX-type SimConnect's that the add-on programs may need. Pete

No, it cannot. If there's no such line FSUIPC sets 1. 20 is the maximum I think. If you didn't change it then somethnig else you have run did. With a stall time of 20 then FSUIPC won't reconnect to SimConnect until it has received no updates for 20 seconds. That's a mighty long time! Okay. That sounds better. So it must be something else, maybe something ProATC/X is doing? I've never used its AutoSave. There's no point in my case because I fly a cockpit with loads of other drivers, and you just can't start a flight in the air. I almost always start from cold and dark. The nearest to flight I can start with is on the runway ready for takoff, but it's so complicated to get that set that it simply isn't worth it. Anyway, a lot of the fun is in the pre from cold and dark, taxiing and so on. Especially at the sort of busy airports I like. I use ProSim for my cockpit and, like you ProATC for ATC. No complex aircraft cockpit with its own systems though, of course. Sorry, but I really can't help much further. The SimConnect restarting WILL be adding to the time you are seeing, but it means it has already been 20 seconds with the sim frozen. I can't really do much about that -- my software isn't involved. Pete

Final message from me for now. Hope you read the previous two as well. There was one other logging option which does log EVERY update received from SimConnect. I only just re-found it (there's a lot of technical debugging options which have been added over the (many) years, and never removed). The one I gave you earlier was just logging newly added aircraft. The one for ALL changes received is: Debug=Please LogExtras=x40000 Be warned though. This will produce HUGE logs. Best not to enable it till you get well away from busy airports but are still getting a few update. To enable it in the Sim, leave the "Debug=Please" set in the INI file, but not the LogExtras= line. Then, to turn it on, go to FSUIPC options, Logging tab, and enter 262144 in the Extras edit box, near bottom left. (262144 is the same as x40000 but in decimal because that edit box won't accept hex). Disable it after the problem makes itself obvious by changing that back to 0. I won't have updates for FSUIPC or TrafficLook to provide the range of the nearest Ground & Airborne aircraft till near the weekend, but this is okay for you because you said you'd have no time before then. Pete

FSUIPC is timing out the connection to SimConnect because the AutoSave is taking so long. When using sophisticated aircraft like PMDG and FSX, whenever a flight is saved they effectively freeze the sim whilst they collect and save the state of every system and gauge. Even if SimConnect didn't time-out, there would certainly be a very noticeable pause. Most folks advice against using an AutoSave of any sort when using these aircraft. the fact that SimConnect connections timeout will certainly make the pauses longer, because FSUIPC then has to completely reinitialise. You can make FSUIPC more tolerant by increasing the SimConnectStallTime parameter in the FSUIPC4.INI file. The default of 1 second is normally much more thasn adequate because it should be receiving updates every single FS frame! Now you say about autosave that "it has been working flawlessly". So what have you changed? Have you only just started using these aircraft? The files are what the A320 and PrtoATC/X are using/saving/loading, whatever. FSUIPC isn't involved. Maybe your disk is becoming full or needs a thorough defragmentation. That would certainly slow file read/writes down. Pete

I reproduce this from your first report in this thread because that certainly is very different from your later reports, such as Noe, what is it you think is the airport "reality bubble"? Since the airport is only relevant for ground traffic, the TCAS limit is 6 miles, but that isn't the same. And then there was this: So, what range would the various airports around the route have been from you? The FS "bubble" in which scenery and AI are generated is about 80 nm. The "airport reality bubble" you mentioned may be the visualisation range, which I don't know by I think is something between 10 and 20 miles. Any airport within 80 nm capable of having MyTraffic aircraft should be getting them populated, though with your traffic settings set low I suppose that might not be so. I did have the FS traffic slider set to 100% for airlines, but only 16% for GA. After I modify TrafficLook, I'm going to try your test "flights" (test slews here) once more but with both set to 30%, as I think you said yours were? Pete

By the time I got there you are right -- no traffic in the TCAS tables. But I checked, and that was simply because the 100 odd AI traffic I had (counted an displayed by the VAS Display plug-in) were all further away than my TCAS range which I had left on the default of 40nm). I actually had no ground traffic for quite a while -- since not so meany miles from Melbourne. Slewing backwards to where I started all the traffic gradually reappeared, so this in just a case of out of TCAS range. I'll increase it to 80 nm. The ground traffic range for inclusion in the TCAS tables is much lower though -- 6 miles when your aircraft is airborne, 3 miles when you are on the ground (actually I think the latter limit applies to airborne traffic too). So I'd need to be within 6 miles of a populated airport to see ground traffic in the FSUIPC tables. One thing this shows me is that there are no airports which are likely to have any traffic within 6nm of your chosen destination, so i assume you have some small addon one which houses a few AI traffic usually? I then tried the second route to see if that would generate what you found to be the 'critical' condition -- some airborne AND a very few Ground AI. Same again. by the time I got to your destination position there are 25 aircraft in total being tracked, of which 17 were near enough and aircraft to still be in the TCAS tables and still being updated. No ground traffic within 6 nm. So, I looked at the FSX map and saw that the nearest default airport was YCRG on a heading of about 135, so I changed headings for that. When I got near enough, at last! Hurrah! One ground aircraft appeared. A GA planned to go from YCRG to YDPO. I passed over the airport and was still receiving both airborne (by now down to 11) and ground updates (the one and only till 6 miles passed). Conclusion I cannot find anything wrong. I certainly can't reproduce what you say occurs. I didn't fly, but I did restrict the slewing speed to 160 near start and end and a max of 400 in between (to speed the tests up). I suspect what you are seeing is just TCAS table limits on distance, but in that case traffic should start to be reported again when there are some in range. So that would be a puzzle. To deal with the former I might add the distance to the nearest actual detected aircraft on ground or in air, as received from SimConnect, to the title bar of TrafficLook. That would show even if none were in rage and so in the TCAS tables. Whether it shows the nearest Ground or the nearest Airborne one would depend on the mode you run TrafficLook in. If it is indeed a problem with SimConnect unilaterally ending supply of AI Traffic data to FSUIPC (but not other of its Clients), then I can only think that it is either some corrupted function of your specific FS installation, or some sort of problem resulting only from your specific combination of add-ons. If so I don't see how I can really fix it, or even get to the bottom of it unless you can find it by a process of elimination or reinstallation. One thing you could try which I hadn't suggested before is to toggle the traffic off and back on -- there's an FSUIPC control you can assign to button or keypress Pete

You absolutely CANNOT have two files in any folder with exactly the same name. There's no way it can be done -- Windows simply doesn't allow it. One of those files is NOT the used INI file, but a file with a different name. Yes, FSUIPC reads your INI file, annotates the assignments section with descriptions of what they do, and adds its version number, FS's version number and SimConnect's version number to the [General] section (for better diagnosis of problems when folks send the files to me), updates the [JoyNames] section to reflect current reality, then writes it back. It doesn't change any of your settings. You "original" INI is not named FSUIPC4.INI file then. The so-called "freshly generated" INI is the same INI as it read on previous loading with the changes I just mentioned. Going back to what you said at the beginning: You did the wrong thing there in any case. Installing an update does not touch ANY files in the Modules folder except the FSUIPC4.DLL and the documents etc in the FSUIPC Documents folder. If you re-register it will also make a new FSUIPC4.KEY file. Absolutely nothing else. It will load with all your settings exactly as before. I suspect your backup folder is not truly named FSUIPC4.INI and this is what is confusing you. Pete

In the end it wasn't quite what I thought. The program checks for only ASCII alphanumeric characters, and removes invalid characters from the end backwards. Unfortunately my stupid mistake was not stopping once they were none left, so the count (size) became negative with bad bad results! Really it should have crashed every time. The fixed version is up. You would now get no names for those two COM stations. Pete

Better to put " around the pathnames, especially if they have spaces, like so: RUN1=READY,CLOSE,"D:\Program Files (x86)\FlyingWSimulation\SuperTrafficBoard for Prepar3D V3\TrafficBoardFrontEnd.exe" RUN2=READY,CLOSE,"C:\OpusFSI_v5\FSISERVER.exe" RUN3=READY,CLOSE,"C:\Lockheed Martin\Prepar3D v3\MADDOG2008\MDCP.exe" RUN4=READY,CLOSE,"C:\IVAO\IvAp v2\ivap_dllhost.exe C:\IVAO\IvAp v2\ivap_fsx.dll" The IVAP entry is NOT for a program at all! You have given the name of a DLL. DLL's are libraries which are USED by programs. You need the name of the EXE there, the program you can actually run to start IVAP. Pete

Sorting it out today. Looks easy. This is the result I got in the Log (Runways.txt): COM: Type=6 (TOWER), Freq=128.50, Name="ÀçîâñêàÿÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ̤Ñ��ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ‘luB=" COM: Type=3 (UNICOM), Freq=22.00, Name="ÐÑÁÍñêàÿÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ̸Ñ� and this in the F5.csv: USCU,0,0,"Uprun" USCU,3,22.00,,"ÐÑÁÍñêàÿÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ" USCU,6,128.50,"ÀçîâñêàÿÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ" Note that the odd string is actually limited in length for the F5 file, but not for the log which shows what it actually read plus what was in the PC memory following it What is happening is due to the bad COM entry, with a non-ASCII string which is not properly terminated by a zero. So the string in memory effectively carres on until a zero is seen. If this is within the bounds of what is allowed (maybe 256 characters), no crash, else it might crash by overwriting something it shouldn't when moved for printing / writing to file. All I need to do, as I should have in the first place, is put a zero terminator in myself when the limit is reached. That will stop the crash, but it won't stop the weird strings -- like the one you got before you got the crash instead. I'm afraid that can only be fixed in the BGL. The frequency of 22 is wrong in any case, so I reckon you really do have a corrupted file there. You said the odd characters were supposed to be Cyrillic. Do they show up intelligibly anywhere? Pete

Well, you've actually managed to answer none of the questions I posed in my previous reply. Perhaps you could read it again? But just glancing at the INI file, I see you have 4 devices connected and known to FSUIPC, numbered 0-3 by Windows. You have not bothered to assigned letters to them, or let FSUIPC autoassign letters, so on any change of operating system or reconnection after unplugging, they are likely to change. The INI file, for most Profiles there are assignments to devices 2, 3, and 4. Device 4 doesn't now exist! Your reconfiguration has changed the joystick ID assignments, the EXACT thing the joystick lettering facility is designed to cope with! To be more specific (and you could see this yourself, just looking at the file which is, after all, heavily annotated for just that purpose): Twin Otter (most assignments): -- Buttons assigned on1 (Pkg Brk only), 2 and the non-existent 4 -- Axes assigned on 0 (throttle1, props 1&2, mix 1&2) with more, including duplications, on 1 and 2 BE200 only axes, and assigned on 1 (mix 1 only), 2,3,4 SR22 only axes, and assigned on 2,3,4 DC3 -- Buttons (2 of them) assigned on the non-existent 4 -- Axes on 2, 3, 4. To me it looks like a bit of a mess, and in fact you are better off starting again. Didn't you look to see what the levers and buttons you were using were assigned to? I think there's really not enough there in any case to bother preserving. For a file with 4 devices and 4 profiles it is quite short. So, not too much to re-do now it's rather mixed up and inapplicable. But do use the joystick lettering in case you have another reinstall or have further need to unplug things. Pete

Both received, thanks. I'll get to in within the next few days and let you know, here. I'm really really busy right now! Okay. In that case it looks as if something serious different or amiss in that layer which is causing memory corruption in MakeRwys. That can change depending on previous memory contents. I assume the scenery it deals with displays okay in the sim? I'll need to at least protect MakeRwys from whatever is different or wrong -- I don't like crashing, for sure. Pete

Okay, thanks! Might be tomorrow now, though (Monday). Committed to other stuff today. Pete

Ah ... the problem I had is that those messages: are only ever output to "Runways.txt" as part of the log. Something seems to be corrupt in your file, somehow getting bits of the other. I will certainly try your BGL here, but the file handles are separate, assigned by Windows, and I'm not sure how they could get crossed. Perhaps, as well as the BGL, you could ZIP up the Runways.txt file and send that too. It will be very large but being text is zips quite well. I'll let you know what I find. Pete

Those are merely logging the commands for those in the BGL! Most good scenery addons delete previous stuff relating to their airport before adding their own. The deletes are done before the additions. If you look at the log again you will see that there's another entry afterwards for the same file/airport adding the stuff it wants, to replace the stuff deleted! The "Runways.txt" file is a LOG of what the program is doing! No amount of changes there will change any of the files it produces! MakeRunways doesn't read that file, it merely produces it to tell you exactly what it is doing! If previous versions of the airport, etc, are not removed before another layer for that airport is added there would be problems. That is why sceneries do it! Well, it is mentioned all over the place. If it won't attach here (most file types will once zipped), by all means send to petedowson@btconnect.com. But there's really no point if you are simply misunderstanding the log file as some sort of control file. Pete

Actually, I'm really not sure how you propose doing this (i.e. from another program, via assignments, or what), but whichever way I think it is a lot easier than you propose. All the switch states are indicated and controlled by the values in offset 0D0C. There are values for the10 different lights. Each has its own controlling "bit", bits 0-9. For assignments to switches you can simply asign to "offset word togglebits", "offset word setbits" or "offset word clrbits" (depending on whether you want to toggle, switch on, or switch off the light) with the offset set to xD0C and the parameter set to 1, 2, 4, 8, 16 ... 512, according to which you want to change. For bit numbers to decimal values, and more about computer numbers, see the FAQ thread about bits and numbers. Similar considerations apply to Lua pluguns, and of course FSUIPC applications. Pete

Sorry, exactly how are the Profiles not working? And what do you mean by "a new user profile"? Presumably you are not talking about FSUIPC there -- didn't you use the same FSUIPC4.INI after you fixed Windows, or if not, why? Inoperative in what way? Once you've assigned axes for a Profile you cannot undo that by clicking to remove the setting. It would be too confusing, because in the Buttons and Keys assignments you can select whether to see and edit the generic non-profile settings or the profile for the currently loaded aircraft. Both are operative at the same time, with the profile settings merely overriding the generic ones. That would be bad for axis assignments because axes are being read all the time, unlike buttons and keys, which only do anything when pressed. To remove a profile assignment section, just delete it in the INI file. Where do they show in FSUIPC? In the Axis assignments tab? If they are changing there AND assigned to the control you want, then they WILL be sending it -- for "Direct to FSUIPC calibration" mode they get sent there. For the FS control mode they do go direct to the sim. Maybe you are using the direct mode but the calibrations aren't enabled. Without more information, I can't really help. Make sure you are using an up to date supported version of FSUIPC (current is 4.965), and if you have a problem, show me the settings, the FSUIPC4.INI file, and also the FSUIPC4.LOG file for a session in which you get a stated problem. Pete

But you don't say what you haven't seen before! Not upset at all, don't worry. I just wondered what it was about. I still am! ;-) Pete

Sorry, but I don't really understand what the problem is. What "hold" are you talking about in the thread title? What are you ticking? What does "until is pressed" -- there seems to be a word missing? There's really no "reload all assignments", only individual reloads for each assignment tab -- axes, buttons and keys. Don't forget that for buttons or keys you need to make you INI edits in the right place. If you make changes to buttons in the general [Buttons] section and those are also assigned in your Profile, the Profile ones will override the general ones. The reload buttons most definitely always clear the assignments for that section inside the memory and load them afresh. There's no way that cannot work, really. Pete

I'll have a look if you Zip up the responsible BGL and send it to me, but there's probably no way I can make it deal with all BGL oddities. But have you checked in the sim about that 22 frequency? Does the Sim read it as 22 or 122? I really don't see how MakeRunways could have logged it incorrectly. it just outputs what it reads, with a bit of formatting. If the sim reads it that way then so should MakeRunways. (Also the names -- does the sim show Cyrillic? Maybe only in a Cyrillic version of Windows? Pete