Neil Hewitt

Cockpit lighting only works during night hours (or more specifically, when the sim decides it's dark enough to enable emissive textures). There's a threshold for morning and night when it moves from 'night hours' to 'day hours' and emissive textures no longer work when you switch on the cockpit lights, so you get no interior lights as they are all based on emissive textures in this model. It's probably the biggest single problem with the model for the E-Jets right now IMHO, and I'd love to see a fix, but I imagine it's a big job to do. If you're not getting cockpit lighting when it's dark, that's a different issue. Obviously the lights only work if the DC battery power (at least) is on.

Sorry, missed the notification for your reply... Lots of people have reported that the E-jets are very heavy on the VRAM - there are other threads in this forum on that. But I've not seen anyone reporting VRAM-related crashes just loading the aircraft. I use the E170 every day and I don't see that. The GTX1080 has 8GB VRAM. That should certainly be enough to load the aircraft. Try setting all the sim settings to minimum apart from the texture settings (leave those at 2K) and see if the same crash occurs. If it does, then I don't think VRAM is actually the problem. If not, then it would seem that VRAM is the problem, but in P3D v5.2 HF1 at 2K, you should not get a VRAM crash at high settings. LM has eliminated most of the crashes. But to answer the wider question, there is no general problem with the E-jets crashing the sim on load that I am aware of, or that I have experienced.

What level have you got textures set at in the sim? If 4K, I would drop to 2K or even 1K and see if that helps. There have been a few efforts to re-size the texture set for various models of the E-jets. Search the forum for these, some of the file sets are available to download and I think the 195 might be among then. This helps because even if the sim is set to a lower texture number, the texture itself still gets read into RAM before being re-mapped. For example, sitting in the E170 at ORBX EGHI (which is not the most demanding airport, admittedly) with 2K textures set in the sim and the actual aircraft textures downsized to 2K, I've got 5GB VRAM used with two views open. Sitting in the VC I've seen it as low as 2.5GB. At the end of the day, though, a GPU upgrade is really the way to fix this. All the new stuff in P3Dv5 consumes VRAM, modern scenery consumes lots of VRAM, and complex aircraft do too; and while 5.2 has definitely improved the handling of it it's still DX12 which does not hold the programmers hand the way that DX11 did. I know that's easier said than done right now, as buying GPUs is... hard (!), but going to 12GB VRAM would really help you. I know a lot of simmers have gone all the way to the RTX3090 with 24GB VRAM. I think that's slightly overkill now, but in a couple of years, who knows? I just paid way too much for a 3080TI (which is basically the same as a 3090 in performance terms but with 12GB VRAM) and while I'm not happy about how much I spent, I'm happy about the increased stability.

I get what @scoobflight is saying. Companies by and large don't announce product dates until they are certain they will happen, which in this business usually means just before or at release time. But it would be helpful to get confirmation that the acknowledged issues that people have reported with v3 are being worked on, and which issues (broad brush) are being tackled. There's just so much cynicism out there in the P3D community now that they are being dumped (or at least downgraded) by developers in favour of MSFS, and having no idea if products will ever get updated just fuels that cynicism. A few words of acknowledgement could fix that without committing anyone to a timeframe. Of course that won't stop people asking when, but that's just par for the course.

One way - get Spad.NeXT. This will let you take complete control of your devices. You can bind any control you like on the Honeycomb and have it generate a keypress, which can be picked up by the EMB via the config tool. That's the only way I know of to do it without directly manipulating LVARs or FSUIPC mouse macros. Either of which would work too, if you have a registered copy of FSUIPC.

The workaround works, but I'd love it if the modification could be modelled in a future release of the 170/190 (I don't think the 175/195 operate at EGLC?).

I've got it syncing about 30 LVARs now and it's performing fine... in fact, the 'P3D stuck on startup' issue I mentioned has gone away since I tidied up my thread handling a bit (Web devs should really not try their hands at concurrent programming). The app is working out quite well. I've got conditions being evaluated as C# scripts which lets me do complex conditionals (ie only set an LVAR value if the conditions are met) and I'm adding support for offsets as well. Since offsets can be backed by a wide range of values and types, that got very complex very quickly, so I'm only supporting 2/4/8 byte integers, 4/8 byte floating point, strings, and everything else is a byte array. This may evolve into a wider 'sim sync' program; given that offsets can be read and written very quickly, it's practical to sync up various sim parameters that, for example, Wideview doesn't do. I shall see where the rabbit hole goes 🙂 Anyway, thanks for your help, and for your DLL, without which (and FSUIPC itself, of course) I would have got precisely nowhere since I loathe SimConnect with a passion I can barely put into words!

Compared to reading offsets, yes. Every LVAR read or write takes one Process() call. Usually around of 10ms. Whereas you can read many offsets in a single process call. Is that just an inherent limitation of FSUIPC, or is it the sim itself? SPAD.neXt seems to be faster - I did look at the LVAR bridge that ships with it to see if I could use it, but it's a private library and it's not documented, so while I might be able to bind to the entry points I wouldn't know what I was doing. Plus... COM interop 😞. Going via FSUPIC via your library has a much lower barrier to entry for someone who hasn't used anything other than C# for probably 20 years. 500ms (50 x 10ms) is not the end of the world, though. In fact, for my purposes, I could probably get away with polling at longer intervals to reduce any FPS impact. I need the LVAR sync to be quick but not instant. And I only need about 20 LVARs for my current purpose. But this will be a programmable system that I might make available to the community more generally, so I can't vouch for every use case. But the faster it is, the better. I've got a prototype working now and it's fine so far, bar the issue I mentioned. But I can use the Ready to Fly offset to fix that. Fun for tomorrow! Really enjoying using the library so far. I like the ambient context approach of just using static classes to handle the communication.

Hi Paul. Is reading / writing an LVAR a particularly performance-intensive operation? Would reading one or more LVAR values regularly (ie as often per second as possible) be a costly process? The reason I ask is that I'm writing a small utility to monitor the values of specific LVARs and then, if they change, trigger an event that I can subscribe to so that I can send a message to a client program on another PC to set the value of the same LVAR on another instance of P3D. What I've noticed is that if I have a thread constantly polling the values, it does seem to have an impact on FPS in-sim (not huge, but visible) and more particularly, if I start reading (or trying to read) LVAR values while the sim is starting (currently my utility connects and starts polling as soon as FSUIPC is available and a connection opens), it seems to stop the sim from actually getting to the scenario screen, almost as if somehow calling FSUIPC continuously is blocking the main thread. If I close my utility down and stop the polling, the sim will then finish starting within about 2 seconds, so it's clearly being blocked. I can't see any way programmatically to find out when the sim has 'properly' started vs when FSUIPC starts accepting connections. Are you aware of an offset, perhaps, that changes once the sim has started? I want this utility to be able to start at PC start-up, remain resident in the systray, and connect and disconnect across multiple P3D sessions if need be. So I do need to be able to run while the sim is starting. Unless I can find a signal to start/stop polling for LVAR values at the right times (other than just 'can I connect to FSUIPC?'), I'm having a hard time seeing how I can make this work.

Great stuff, Paul, and thanks!

Hi Paul. I'm using the current stable version of the Nuget package with a .NET 5 WinForms app (using TFM net5.0-windows, so it's Windows-only, of course). It works fine (so far) but I get constant warnings about the Nuget package being restored for .NET Framework 4.8 or lower. Any possibility of getting a version compiled for netstandard2.1 or net5.0-windows? As people start to migrate it's becoming more painful being constrained to .NET Framework projects as .NET 5 has some significant improvements derived from the .NET Core side of the family. Just thought I'd ask 🙂

For the record, I see the same. Light leakage at points where there are joins in the model. I'm assuming this is down to the same P3Dv5 changes that made exterior lights on some aircraft models leak into the cockpit. From what I understand, it's a question of updating the model itself, so I guess that's a job for Aeroplane Heaven for v3? I appreciate you wouldn't want to make promises or give a schedule, obviously, but is there any likelihood that we might see an updated version of the aircraft that is officially supported on v5 and fixes the most reported issues at any point in 2021?

A quick reply to summarise my further findings: the reason why there is so much more data in the 5.11 output vs the 4.84 is because (according to the log in runways.txt) 4.84 doesn't actually find any taxiways (or indeed anything else other than two closed runways) at UK2000 EGLC. All the taxiway data for EGLC output by 4.84 is from the default P3D EGLC. 5.11 does enumerate the taxiway and other data for UK2000 EGLC as well as the default EGLC, hence all the 'extra' data I mentioned at the start of the thread. Pro-ATC/X somehow gets confused with this output. As to exactly why, I don't know yet. Still running tests. But a potential solution to my problem seems to be to just disable UK2000 EGLC and run 5.11 over the default scenery, then re-enable before flying again. I shall try that and see if it's a simple shortcut. Now I'm going to see if I can figure out Pro-ATC/X's database format so I can just visualise the data it imports directly rather than having to fire up the sim each time. Should I find anything else of potential interest to Pro-ATC/X + MakeRwys users, I'll post it here.

+1 for this - it's what I ended up doing. I have a fairly unholy mixture of key binds via the FeelThere config app, mouse macros, and a few LVARS to get the jet working with my MCP, switch panel etc. There's a huge set of LVARS for the E-Jets - I could probably switch a lot of my key bindings to LVAR control, and I might well do so in future. Setting an LVAR from Spad.NeXt is easy - but it's easy from FSUIPC too. This is actually one of the more cockpit-builder friendly aircraft I have in my hangar.

Right there with you on that. I often find myself looking at code I wrote a few years back and thinking 'how the hell did I ever understand how this worked?' 🙂

Hi Pete. If I were certain that that's the root cause, that would be a great option. On the previous thread, though, you did produce a build of MakeRwys 4.892 with a similar command line option (/oldnodraw), which I downloaded and ran, and that data set did not work in Pro-ATC/X, so I suspect the problem is more fundamental on the Pro-ATC/X side. I do appreciate the offer, but I don't want to make extra work for you if it isn't going to help solve the problem.

Understood, and thanks for your help. Much appreciated. If I do find a solution that works, I'll post it here in case it helps other Pro-ATC/X users.

If I run 4.8.4 against my P3Dv5 install it scans through the BGLs in the scenery areas listed in the scenery.cfg, but it only finds 1 airport and 2 runways. I've not been able to make it work correctly on any of my P3Dv5 installs (which is all of my actual sim machines). It also doesn't appear to invoke the LorbySceneryExport.exe which is in the same folder; if I run that separately, rename the output to MakeRwys_scenery.cfg and then run MakeRwys with the /ssng option, it will read the add-on scenery but it still only sees 2 airports and 2 runways on my clean-install-plus-UK2000-EGLC build. And it doesn't see any runways at EGLC. T5.csv (as with most of the other output files) is empty. Should this version work against P3Dv5? I'm running it as administrator and it definitely doesn't work for me on multiple machines, but perhaps I'm doing something wrong or I have a bad config?

OK, thanks Pete, appreciate the response. I will get into ADE and see if I can work out what the data *ought* to look like. Is it possible to download the intermediate versions of MakeRwys anywhere? Just binaries. It would be useful for me to be able to run the test using a 4.9.x build, for example, and a 5.0.x build.

Hi. I mentioned in a thread over at Avsim that I was putting together some data on a problem I've been having with Pro-ATC/X no longer recognising or announcing taxiways on some airports (for this post I'll be looking at UK2000's EGLC specifically) after importing data generated with MakeRwys 5. There was a previous thread about this issue which Pete Dowson diagnosed as being probably down to Pro-ATC/X interpreting the taxiway data incorrectly after changes were made to MakeRwys to fix an issue with hold short points being given the wrong type. For reference, the previous thread is here: MakeRwys potential bug. - FSUIPC Support Pete Dowson Modules - The simFlight Network Forums What I've found is that if you import a data set created with MakeRwys <= 4.8.4 into Pro-ATC/X, you get taxiways at EGLC announced; with a data set created with MakeRwys 5.1.1, you do not. So I decided to compare the taxiway data created by each version specifically for EGLC. To do this, I installed fresh versions of P3Dv4.5 and P3Dv5.1 on a development machine, and installed only UK2000 EGLC as an add-on to each. Otherwise, the installs were completely stock. I ran MakeRwys 4.8.4 and MakeRwys 5.1.1 in turn against the P3Dv4 installation and collected the taxiway CSV file t5.csv from each. I also ran MakeRwys 5.1.1 against the P3Dv5 installation and did the same. Then I extracted just those rows for EGLC out of each of the three files. The data from 5.1.1 for P3Dv4 and v5 were identical (as you would expect) so I discarded the P3Dv5 version of the file. This left me with two sets of CSV data for UK2000 EGLC, created with MakeRwys 4.8.4 and 5.1.1 respectively. What I notice immediately is that 5.1.1 creates significantly more data. It has multiple entries for each taxiway. I don't know if this is expected or not; the data is not repeated in each entry, it is different. To give an example, this is the data from 5.1.1 for taxiway A: EGLC,A,10,51.505363,0.044498,7,10,51.505268,0.044437,1,10,51.505146,0.044419,1,10,51.504978,0.044474,1,10,51.504826,0.044653,1,0 EGLC,A,10,51.504829,0.044257,1,10,51.504887,0.04442,1,10,51.504978,0.044474,1,0 EGLC,A,10,51.505383,0.044529,1,10,51.505249,0.044427,1,10,51.5051,0.044426,7,10,51.50502,0.044457,1,10,51.50489,0.044425,1,0 EGLC,A,10,51.504818,0.044656,1,10,51.50502,0.044457,1,0 And this is the data from 4.8.4 for taxiway A: EGLC,A,24.38,51.505558,0.044747,1,24.38,51.505211,0.044733,2,24.38,51.504745,0.044715,1,0 This is repeated for all the data, but it's not the case that there are x entries in 5.1.1 for every y entries in 4.8.4, it varies; for example, for taxiway L there is only one entry in each file, as follows: 5.1.1 : EGLC,L,0,51.504105,0.064505,1,0,51.504158,0.064728,1,1,51.504269,0.064934,1,10,51.504364,0.065102,7,10,51.504543,0.065426,1,0 4.8.4 : EGLC,L,21.34,51.504196,0.063287,1,21.34,51.504143,0.06509,1,21.34,51.504101,0.066414,1,0 It looks to me like 5.1.1 is interpreting the scenery very differently between versions, and it's this difference that's causing the import to Pro-ATC/X to fail. It is the case that, as mentioned in the previous thread, 5.1.1 adds 'no-draw hold-short' points correctly as type 7, whereas in 4.8.4 they are added as (I think) type 1 or 2, but as the data sets are so different I can't reasonably draw the conclusion that this is the issue with Pro-ATC/X not reading the data properly because I don't understand the reasons why the data is different in other respects. Of course that's just my theory, based on the data I've generated. I'd appreciate it if you could take a look at this and let me know a) if you think the 5.1.1 output is correct given the exact same scenery input as the 4.8.4 set, and if so, why there are multiple entries per taxiway in 5.1.1 where before there was only one; and b) if not, what could it be about the scenery that is problematic other than the already-established use of no-draw hold-short points? My ultimate goal here is to develop a tool that will adjust the t5.csv (and possibly t5.bin, I don't know which Pro-ATC/X actually uses for import) so that an export from the current version of MakeRwys will work with Pro-ATC/X until they fix the issues on their side (which might now happen; there's apparently a beta version of a point update available to beta testers, after years of silence). I can't attach the complete versions of both t5.csv files to this post as the best zipped version I can create is still larger than the max attachment size allowed, but a zip with both files can be downloaded here: https://1drv.ms/u/s!AlANnlscyRN4hMlJOw46AOx1ZSnR6g?e=m5a2Eo Thanks in advance and apologies for the lengthy post! NH

That's interesting, because on my system using the GSX fuel truck does not change the fuel amount in the E-Jets no matter what value I choose. I have to use the P3D fuel dialog or else I cannot change the fuel levels at all. EDIT: Ignore me! I just realised I was attempting to set a lower fuel level than I already had. GSX will only *add* fuel, not take it away. Doh.

Quick update on the above - as I should have realised, all the emissive textures in the sim turn on and off at the same time (which is when a certain darkness / lightness threshold is reached). So basically the lights in the cockpit, being emissive textures, turn off when the sim thinks it's daytime. And turn on when it thinks it's night-time. EDIT: remove the info about tweaks I had originally posted. It's now become clear these settings don't work in P3D 5.1 HF1. Not sure about v4.x. The real solution to this issue is actual dynamic lights in the cockpit and custom effects for the backlights, as far as I can see, so it will only happen if FeelThere / Aeroplane Heaven re-implements the lighting. Though I know some people are using FS Labs Spotlights successfully - if anyone knows of a way to bind a key to turn Spotlights on and off, I'd be very greatful to hear about it, as this is the main thing stopping me from using it.

I can only speak for the E170 in P3Dv5.x (currently 5.1 HF1 but I've seen it on multiple versions since SP2 came out).

I used to get a massive FPS drop when turning on the taxi lights on the E170. I was tearing my hair out over it. Eventually I tried dropping my AA settings from 8xSSAA to 4xMSAA, and the FPS returned to normal. Higher than 4xMSAA, and the problem comes back. No idea why the taxi light effect would cause this - I had run my sim at 8xSSAA for years with zero problems, my GPU is (well, was) top-end and had no problem coping, but the lighting on this particular aircraft model broke it. Interestingly, this is with a GTX 1080Ti. The RTX 2080 SUPER I have in my other machine does not have this problem and has no FPS drops from any of the lights.

From pulling the aircraft apart, the cockpit lighting including backlighting is done using emissive textures. You'll note that in the dark when you turn the lights on, the textures reload - that's because it's pulling in the 'lit-up' textures from the disk. There's no actual dynamic light in the cockpit that I can find. As to why they turn off when they do - I can't find a reason for it in any of the stuff I could inspect. It happens at a fixed time relative to local sunrise, from what I can see, but changing the sim's night / day settings to keep lights on longer into the morning doesn't stop it from happening. Of course, the textures would not look realistic in full daylight which is probably why the devs chose this method. But IMHO all lights should be available at all times regardless - they are in the real aircraft - as they would be needed in dark conditions / IMC etc. EA in V5 makes it worse because HDR can make the cockpit interior look shadowy and dark even at midday. Unfortunately, fixing this properly would probably mean re-doing the lights entirely and moving to dynamic lighting. Obviously we don't know what FT's priorities and workload are - and I wouldn't expect any business to tell us what they were doing in such detail - but it would be nice to know if this problem is being looked at in the internal V5 build they've mentioned they have. P3D V5 is getting pretty short shrift in many case due to the 'MSFS effect', and I don't blame developers for going where the money is, but MSFS is largely useless for cockpit builders and advanced users who need multi-monitor support or may have advanced display configurations and advanced hardware interfacing needs, and it looks like it will be for quite some time. Meantime we're left out in the cold 😞