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?' 🙂