Ray Proudfoot

ShowMultilineWindow=No SuppressSingleline=No SuppressMultilineFS=Yes Has fixed the problem. 👍 No need to delve into very old code. Thanks!

Hi Pete, Happy to do the test you suggest. I’ll report back later today. Thanks for checking this.

Pete, don't spent much time on this. It's soon sorted but it would be nice if it didn't appear at all. Shouldn't SuppressMultilineFS=Yes prevent the RC window from showing? The options in FSUIPC don't make any reference to SimConnect and like most, I'm not an expert on how these things are controlled.

Hi Pete, I use ShowText on a WideFS PC for Radar Contact. Have done for years. No extra space on that monitor for another lua script window I'm afraid. This seems to be a long-standing issue. I had the same in v4 but just lived with it. It's not a major issue but it just seems that if I select the option not to show a multiline SimConnect window for RC it should work.

Hi Pete. Doing that would also suppress the Active Sky stuff wouldn't it? I want to keep that as it's useful to know when the wx is being updated.

Hi John / Pete, Running v6.1.2 in P3D v5.2. I use Radar Contact on a separate PC/display so have no need to see the window for RC on the sim PC. I have selected Suppress Multiline in FS's Window so in theory should not see the RC window. But I do when it's first launched. I have these settings in the ini file:- ShowMultilineWindow=Yes SuppressSingleline=No SuppressMultilineFS=Yes Can you spot anything wrong with those options that would cause the RC window to be displayed?

Just an update to this. I added the AIFreezer.lua to the P3Dv5 Add-ons\FSUIPC6 folder and edited FSUIPC6.ini to call the file. A flight from LEBB over to LEBL was used to test things. Landing traffic was assigned to 07L with departures using 07R. I requested 07R in RC4 and when around 8 miles out I noticed one Ai with a status of TakeOff2 indicating he was on his take-off roll. Others were taxiing out to 07R. I lowered the gear around 4 miles and was cleared to land. Landing was fine with no go-around instruction. SUCCESS! The FSUIPC6.log indicates the lua was called and froze and then released Ai at the relevant points. Thanks for your help Pete. 😀

Hi Pete. I dunno why RC4 doesn’t handle Ai very well. Maybe it’s the increased number of them with AIG injecting far more than back then. But the lua file you mention looks like it will do the job. I’ll investigate, thanks.

He’s too busy walking the dog and watching the snooker! 🤣 It’s okay John, it was more a request to see if it was doable and it sounds like someone with LUA skills could help out. With the RC author haven given up many years ago working out why it no longer works is a non-starter.

Hi John. I would imagine the guilty aircraft would be one of the 96. My LUA skills are fairly rudimentary sadly. I do use Ai Companion and that offers the facility to delete Ai aircraft but you’ll appreciate switching attention to another screen whilst manually flying the final approach is not ideal. As a former RC user Pete might have some thoughts about how best to manage this. If I’m really lucky he might even knock together a script for me. 😀 Something that every RC user would appreciate.

Hi John, hope you're keeping well in these difficult times. I wonder if you could help with an Ai problem in P3D which impacts on Radar Contact instructions. When I'm around 3-4 miles out it's too far to see if Ai are lining up to depart on my landing runway. Even if I could see them I suspect Traffic Zapper would not work that far out. What then happens is the Ai lines up and with 2 miles to run Radar Contact detects the Ai and issues me with a Go-Around. Very frustrating when the rest of the flight has gone well. Would it be possible for FSUIPC to monitor Ai assigned to my landing runway and as soon as the status changes to TakeOff1 to kill them? That status is activated when the Ai start to move onto the runway from the hold-short point. Is that doable? Radar Contact used to freeze Ai when the user's aircraft was on finals but it doesn't appear to work any more.

Hi Luke, the only indication mine were disconnecting and reconnecting almost immediately in flight was the USB disconnect / reconnect sound being played. If you’re not hearing that (confirmed by entries in the FSUIPC.log then it’s not the problem I was having. Certainly keeping devices plugged in to the same ports is essential to avoid these problems. Good luck!

Hi Pete, that’s why I removed my comment as I noticed he was plugging the yoke in only when the sim was running. But if Devices are disconnecting and reconnecting during flight then it sounds like the problem I had.

Please ignore. Misread the problem.

Agreed Pete. Most seemed to be the taxiway link joining on the runway. Just a tiny segment of an otherwise normal path. Odd really because ADE is very good.

Pete, I've been deleting the broken links and recreating them but for some unknown reason ADE v1.78 still sees them as broken. It probably needs reporting to the author. For now there doesn't seem to be any point in trying to correct them. Hopefully the t5.csv I supplied will help you.

Sadly not. It's a manual job to do that. There are 13 broken taxi links in EDDB_AFX_OP01-BER.BGL. I've attached the report generated by ADE. I'm not sure how much impact this has on Ai. They seem to behave okay despite the ADE warning they may not. But it make have an impact elsewhere. EDDB_ADEP4_RAY_faultList.csv

Hi Pete, Have you tried running the Fault Finder in ADE and see what it reports? There may be multiple broken links. ADEs are pretty near the bottom when it comes to airport design.

@agutz, any chance you could provide that file to Pete please and perhaps also to me. I'll send you my email address privately. Thanks!

Thanks Pete. I guessed you hosted it without unzipping. I’ll write to the developer.

Gents, I've tried to use this utility for the first time. One problem. There is no executable in the zip. Just 3 txt files and a CPP file. Has anyone got this working and if so, how?

I'll raise it on AvSim although Aerosoft would be the more logical site. But given you can never speak to the developer that is probably a waste of time. If others confirm the problem with v4.5 but then say it doesn't occur with v5 that's food for thought. Malaga or Bilbao to Madrid are also short hops. Malaga with northerly winds or Bilbao with southerly. Try to get some flying time in Pete inbetween the updates! 😁

When I land at Aerosoft Madrid Professional the instant the wheels touch the ground there is the most appalling series of stutters. It’s been like this for a while but I decided I’d had enough and investigated. CPU1 is close to 100% so I loaded the LEMD utility and turned off all settings. All of them. Reloaded the flight 10 miles out and again, the same stutters on touch-down. CPU1 was still in the high 90s. To cut a long story short only by turning off DL in P3D did the stutters cease. But this is in daytime with no DL options enabled at Madrid. There must be some code that is called on touchdown that is causing this. Crazy it has such an impact on performance. Does the same happen in v5 in daytime flights with DL enabled in P3D. If it’s fixed it might be worth considering a switch. The alternative is not to have any taxi and landing lights illuminating the ground which takes away a degree of realism. Madrid seems alone in this problem. Maybe the airport is coded differently to other Mega Airports.

Not in v4.5. 😁 They give it realism. I don't spend enough time at airports to think about building shadows.

I conducted some tests earlier with AA at various settings to gauge the impact on GPU rather than fps as that is adjusted back to 30 by removing Ai in FSUIPC. I was more concerned about trying to reduce the load on my 1080Ti. I’ll check shadows but this seems like one of those things where you could spend a lot of time tweaking to find the perfect settings. You’ll have far more leeway than I Pete. Cloud shadows are worthwhile but not sure about building ones. Vehicles certainly not. LOD has only been an issue with Concorde in v3 but I had to keep than low for VAS purposes.