As we move forward with the beta, we’ll write up some posts on X-Plane 11.10’s the new features – there are a lot of them, to the point where I’ve lost track of what’s actually in the release. Right now we’re in the “does it work” phase, trying to get a beta that works for everyone without crashing. (Beta 1 worked fine for everyone in the company, but often our internal machines are very similar to each other, so early betas catch things we missed.)
So what follows is a big pile of nerdy stuff…I’m going to add random images in to make the post less boring. So picture is not related.
Where Do The Bugs Go
When you file a bug with our bug report form, it goes to a shared email in-box that someone triages – usually it’s Jennifer, but sometimes it’s me or Philipp. The person triaging the bug will then forward it to our internal bug tracking system (that’s where those XPD-123 numbers come from) or possibly forward it to tech support – we do get a lot of “my sim is broken, help!” in the bug reporter.
This is why I always jump up and down and go “file a bug!”: everything in the bug reporter gets looked at, and everything that is then filed is permanently tracked. At the end of 11.10 we can check the bug list and see what hasn’t been fixed. Like all software, not all bugs will be fixed by the end of 11.10, but if the bug is tracked, this avoids us losing the bug.
Here are some ways to report a bug that are not tracked and are extremely likely to get lost:
- Posting in the blog comments section. We do not ‘scrape’ the blog for bug reports. If you write a blog comment and do nothing else, your bug will not be fixed.
- “Reporting” the bug on a public forum (x-plane.org, reddit, etc.). We don’t scrape those either, so it’s quite possible no one will see it.
- Emailing an engineer at Laminar Research directly.
The problem with direct email is that it doesn’t go through the tracking system, you might not get the right engineer, and again, you’re bypassing the mechanisms we have in place to not lose things. If you email someone organized and responsible like Tyler, he might file the bug for you. If you email someone like me, whose in-box looks like a grenade went off, there’s a very good chance I lose your report.
Jennifer tries really hard to list every item that is fixed in each beta, so that you can tell when your issue is fixed and it’s worth re-testing/re-reporting.
This system is far from perfect, and the number one request we get which is reasonable is better linkage between the internal tracking and the user reporting. I sympathize because we have the same problem of “it’s a black box” with the technology vendors we depend on (Apple, Microsoft, Intel, AMD, NVidia).
Changing How We Build
With X-Plane 11.10 we moved to cmake for our build system. Previously we would maintain separate project files for all three operating systems. That’s about 3x the amount of work it should be, so for 11.10, Sidney and Jörg moved us to cmake, which lets us manage X-Plane as a project once.
The down-side is that there have been a number of serious one-time bugs due to projection configuration problems, since using cmake meant rewriting all of the configuration info for building X-Plane. This is what caused the Linux bug in beta 1 that we required libc++ (fixed during 11.00’s beta process, it popped back up when we replaced makefiles) as well as a number of other random bugs we fixed before public beta started.
In the long term cmake is a win – having gone through the pain of the migration, it’s just quicker for us to administer X-Plane’s project files, which means more coding and less fighting with X-Code, MSVC, etc.
More Robots
In the last few months we’ve automated our build and our packaging process, as well as the amount of testing done automatically by the build system. Hopefully this will turn into bugs being caught earlier, and it makes it easier to cut new betas – getting quick betas out to fix crash bugs wasn’t time consuming. I expect the beta count to be higher for 11.10 than in the past due to the lower cost of recutting the build.
(If I had to cut five betas in a week for 11.05 I’d be pretty cranky at everyone – five betas in a week is totally doable now.)
Graphics Cards That Remember
Before X-Plane 11.10, X-Plane would set up shading for a given material by telling the graphics card about every aspect of the material. Over and over. Every time the material was used. For every single frame. For every single view in the frame.
X-Plane 11.10 now stores parts of the materials in VRAM, so they can be referred to as needed. This is part of our restructuring of the rendering engine for VR, Metal and Vulkan.
This was also the cause of the “invalid UBO” errors in beta 1 – now that we are saving materials and not just reiterating them per frame, we have to get the book keeping right. Sidney set the sim up to crash if the book keeping is done wrong. (This is a good thing – the sim is going to crash anyways if the book keeping is wrong — at least this way the auto-report explains exactly what happened, rather than us having to autopsy the resulting carnage and squint to find the root cause.)
AMD Users: this code is not working on AMD cards right now, which means you aren’t seeing some performance improvements. We’re working this week to see if we can get this going on AMD cards too – stay tuned.
I have very hard machine with AMD processor quad core 4GHZ, 16 GB RAM DDR3, ATI RADEON X 460 with 2 Mb VRAM, SSD…
With medium setings X-Plane 11.10 frame rate is 15.
Can it be fix?
Please!
You’re kiddin’…right?
No, that is true.
My point is that in the post they say to not report bugs here…and the first comment is a bug report!
Amazing…
“with 2 Mb VRAM” – is that a typo? I assume it is meant to be 2 Gb.
It is a beta version so don’t be frustrated.
It is 2GB, sorry. I hope the 11.10 would be FPS more friendly after beta…
your problem might be the 2Mb of VRAM?
This one is easy to test.
If the sim runs like a dream at really low and ugly tex res and is a choking mess at a high and preferred tex res, it’s VRAM.
Hitting a VRAM wall at a patch upgrade _can_ happen…since there are new art assets shipped with 11.10, it may be that airports that could -barely- function iwth 2 GB of VRAM now don’t. Running out of VRAM tends to be like hitting a brick wall – the performance degradation is quite sudden.
If you run the fps test and the numbers say “your sim is fine” and yet it’s not, another good reason to look at VRAM. The FPS test is designed to
1. Help us detect when we’ve made x-plane slower by accident and
2. Help driver writers detect their GPU’s relative performance.
To do so, it keeps texture resolution low so that it will run on a range of cards with varying VRAM. So if you are running on the highest VRAM settings and the FPS test is fast…could be you’re out of VRAM.
Any chance for a solution when it comes to short video examples in filing bug reports Ben, or attachment URL/embedded code (i.e. YouTube) or/links. In many cases, videos are needed to explain an issue/bug rather than asking how to reproduce or indexing what the bug is. Also, the steps to reproduce should be optional, not mandatory for filing a bug. In many cases, I just write “start x-plane” just to put something in.
The bug reporter tech is waaaaaay lower-tech than its beautiful, HTML 2.0 front-end might lead you to believe. 😉 If you want to submit a video, I think your best bet is to upload a YouTube video and just copy & paste a link for us.
Steps to reproduce is deeeeeeefinitely not going away—there are very few bugs that can reliably be reproduced just by starting X-Plane. (Crashes-on-startup during this early beta process notwithstanding, most bugs require some particular configuration at the least.)
Thank you Tyler, was not asking to remove the reproduce, just make it optional to type in. As of now, the bug cannot be filed before you enter something into this field. So in many cases, a dot has been entered, not sure how that helped. But at least someone fixed the bug anyway according to the release notes.
So yea, optional is my Christmas wish 🙂
Keep up the good work you all are doing. Loving it!
From experience as a professional bug-writer: Repro steps are super handy, and very important.
It’s not always completely clear what the bug is from a description alone, so the repro steps help Laminar fully understand what is being reported. It’s an opportunity to state the bug in a different way. Plus then they can follow the exact same steps and get the bug to happen, so they can see it themselves. Some bugs are tricky and only occur in certain circumstances. We users don’t always notice that, and the person at Laminar receiving the bug might try a different method and not see the bug.
It can also be good to include “Expected Results” and “Actual Results”. This way the person reading the bug report knows what the reporter was expecting to see, and what they actually saw. This adds further clarity to the report and is a good way to catch misunderstandings (for instance, more than once I’ve reported something that turned out to be by design. My expectations were incorrect).
This is 110% true. There’s a LOT of different ways to do things in x-plane (joystick, keyboard, mouse, UI, panel, from startup, after flying, etc.) so we prefer reproduction steps that are fairly low level and specific. Murphy’s law says that if you say “open a plane”, we will pick a different way to open a plane than you did, and we won’t see the bug.
Expected vs actual is super important too – it states clearly WHY you think there is a bug…if the actual result IS what we expect, then we know this is a case of the sim not meeting user expectations and not a bug.
Why can’t I like this comment 1000x?!? 😀
Hi Tom,
Please:
NEVER, EVER, EVER leave out the steps to reproduce.
There is no bug so obvious that hiding how you created the bug and leaving us to make up our own answer is a good idea. Bugs are hugely dependent on how you got to them, so steps are critical.
We tend to triage the bugs that have no steps to repro LAST because they take so much more work to sort out than the ones that have proper steps. Before we can even confirm that the bug exists in current code (as opposed to the last public beta) we have to use our psychic powers to guess what the reporter actually did, from a UI standpoint.
For everyone reporting bugs – yes it’s hard to write GOOD bug reports!
If it were possible, there would be a direct link to a developer who would poke prompt and tease out that vital step to reproduce the bug.
Please live with this small reporting nag, the code fixes are much harder. And IMPOSSIBLE if you cant reproduce the bug…
Suzanne!!! Keep up the good work, guys! Cheers!
Any prediction for beta 11.10 for steam?
Nice post, I’m looking forward to testing the saved graphics algo in my AMD and nVidia cards when my systems are fixed in a day or two (both are down).
We typically see a list of fixes of bugs in the Release Notes that we can’t relate to or even understand. It’d be nice to be able to inspect the bug reports even if dumped haphazardly into some machine-searchable text file in the web to reference those of interest to a particular user, who may or may not have the bug or related hardware, just to complete the circle of knowledge.
First of all: Thanks for the clear words about how you deal with bugs and bug reporting! You did that before – spreaded in pieces over several posts, but this one should be crystal clear to everyone.
This leads me to the following idea:
How about showing the current and continuously updated bug list to the public?
Users then could verify that the reported track was recognized by LR.
If a bug gets fixed, simply mark it green or something so everyone will know that a fix is coming with the next release.
This could be pushed further by marking, how often a bug has been reported so the user has an idea if he might be alone with a certain problem.
Bugs which cannot be reproduced by LR could receive some kind of public user comment field. Maybe other users experienced the same problem but have a better talent to describe what they did to get the bug. Maybe another user found a solution or workaround that helps LR to better find the problem. Also this might help to highlight, if a user specific problem outside LR’s code leads to the problem.
For example I’ve had a one year period of CTDs with XP10 that lead to tons of crash reports. Finally I figured out that after upgrading to 64GB of RAM I had to reduce the clock speed of my RAM to get a rock stable XP10! For some reason it was XP only having problems…
Well, I know that all this means extra work but it may reduce questions by the users and sometimes it may deliver the missing piece of the puzzle.
Just an idea…
Keep on your great work!
Regards,
Marc
There’s been high anticipation with respect to performance improvements in 11.10.
Personally, with that anticipation, I perceived a performance drop but actual Science™ proved no change from 11.05.
If the community is thinking anything like me, there’s an expectation that my 30fps situations will leap to 40+, and still hoping it’ll improve in the 11.10 beta run.
Do you have a story/article around the performance improvements expectations?
First: since we introduced new art assets and engine changes at the same time, it’s very difficult to measure from beta to beta the effect on net fps. If your favorite airport got a ton of new jetways on the gateway, that looks like a fps loss (hence Jennifer’s imploring everyone to look more at the sim and less at the counter).
We handle this by benchmarking the sim incrementally so we can measure across code changes without the art asset changes – the only true Apples to Apples comparison.
Second: those fps improvements only affect modern Nvidia cards on Windows where the user is CPU limited. So here’s a lot of people going “where’s the boost?”
– The user with an NV card and two 4K monitors.
– The user with an RX480.
– The user with Intel graphics. (He’s afraid to make eye contact with anyone.)
– The Mac user.
We do hope to get Windows AMD cards in on the performance improvements. The changes we made don’t help if you’re fill rate bound though – you can fix that by backing off fill or buying a bigger video card.
Ben, can you explain in a few sentences the problem with uniforms on AMD cards? In case it’s not related to OpenGL extensions, that’s something me and possibly others could learn about. Thanks.
The issue is that with the current b3 code, if we use the new UBO path, the RX480 hangs up and the driver gets reset.
The optimized branch pushes less UBO data because we are more optimal about reusing data than in b3. Besides being faster (less work = faster) the RX480 doesn’t choke on the workload. The RX480’s use of the new path is off in b3 so we could go beta without hosing AMD users.
How is linux getting in the way of the nvidia optimizations?
NV is same as Windows – NV Linux gets them, AMD Linux is held, just like AMD Windows.
Sorry for off topic comment, but I have been wondering how long does it take for new airport to be added into database after gateway request? I already have scenery for airport that’s missing ready. I have sent the request a while ago, but I still can’t submit it. Anyway I am really looking forward for new buildings to play with in wed in 11.10, although I mostly planned to make small airports some of whic are missing completele hence the question.
Looks like a few airport code requests fell through the cracks. Jennifer will be working through the backlog in the next couple days. Since you have an airport ready, you’re welcome to email her directly (her email is her first name at X-Plane.com). We definitely want to prioritize the approval of airports that have scenery waiting.
What about WED 1.7? I would like to see if WED 1.7 gives me the tools to validate my custom airports so they will run better in XP 11.10. I actually have a fps drop from about 60 to sometimes <10 when I get near one of my custom airports. I did not see these fps drops in XP 11.05.
So before I file any bug reports I would like to examine my airports and see if I can optimize them. If not I will file a bug.
WED 1.7 does not have any changes that make scenery run better/faster/different in XP (any version). Its focussed on user interface improvements w/no changes in scenery creation capabilities, except for (minor) bug fixes.
Only validation changes so far are enforcing runway names & locations that are compatible with the FMS/GPS data and avoiding some taxiway/polygons that show in WED, but at times not at all in XP.
There is some XP11.10 specific stuff in there that will help using the libraries (support new art asset naming schemes, highlight newly released art assets etc), but those new tags are not yet (as of 11.10beta3) in the XP. So nothing to see there, either.
The most important WED 1.7 novelty for users is likely the facade preview. But I’m still debugging code to get the XP10.00 format (type 2) facades all show up right. And since 90% of all interesting facades and 100% of all new in XP11.10 are type 2 ones …
The always current changelog for WED 1.7 is at //github.com/X-Plane/xptools/blob/wed_170_release/src/WEDCore/README.WorldEditor
That is sad. I hoped that the validator could help a little to confirm if I have done something totally wrong.
But I am still looking forward to see WED 1.7… So…
Keep up the good work…
You can file a performance bug. In order to do this you need to give us a _uniform_ viewing condition. One way to do this is to place the airplane at the airport (in 11.05) in a way that you have bad fps in 11.10 and good fps in 11.05. (In other words, find the “killer location” and then save an 11.05 .sit file.)
Send us the .sit, using one of our airplanes and the scenery and we can try to repro and investigate.
The .sit file has to be 11.05 so that BOtH 11.05 and 11.10 can open the scenery, so that we can compare.
I’ll see what I can do. But it’s going to take some time because my custom scenery/airports are not cleaned up. They use a lot of custom libraries, and I have to find out witch is used where before I can pack it up.
But I will try when I am not busy working.
Thanks anyway…
It’s great to see that you automated your builds and started using cmake.
I did it last year for REP and it was a great choice!
Keep up the good work, guys!
I have very hard machine with AMD processor quad core 4GHZ, 16 GB RAM DDR3, ATI RADEON RX 460 with 2 Mb VRAM DDR5, SSD…
With medium setings X-Plane 11.10 frame rate is 15. Before, with X-Plane 11.05 frame rate was 25-30.
Can it be fix?
X-Plane is unplayable for now 🙁
Please!
Thank you!
This is why it was told all the time that one has to keep the stable version 11.05. The version 11.10 is at early beta and for testing only.
If you think that there is a bug causing serious performance problems, file a bug report through the reporting system. If you would have read the intro instead of repeatedly posting this, you would not even post this.
Again: Version 11.10 is NOT released for simulation but for testing only. The idea of beta versions is to find bugs by testing. If there is a bug – betas have a lot of them – it will be fixed. But what do you think the developers could do with a simple report like “I have an older mid-range computer and the FPS performance is poor. Please get it fixed!”?
So please, get back to the very beginning of this chapter and read it.
Regards,
Marc
I sent a bug report a week ago and didn’t receive any confirmation that LR has received it. When I clicked to send the report, I saw the message “sending message” and then, after that, the page reloaded to the inicial bug report page. Is it right?
If your submission is successful, the next page with have:
“Your bug has been filed successfully.” + a summary of the report.
Unfortunately, the form is very old and has not been modernized, so if you try to attach a file that is too big for our secret file size limit, it will eat your report and you will have no way to know it. 🙁
To avoid this possibility, only upload .txt files & screenshots. For videos, large files, etc, I recommend using a sharing link in the report body.
I did not receive any message or a summary of the report. For sure, as I sent a video, that was the problem. Thanks Jennifer.
good morning when relased beta 4 ? .
Give everyone a break.
Hi.
Does 11.10b3 have all the new art assets or are there more to come? I ask because on quick look, I don’t see anything much that is going to help anyone looking to make smaller airport scenery for submission to the gateway. The Terminal Kit assets look great! Although, it would be nice to have styles to match the original Modern Terminal buildings.
Question! Umpteen caravans but not one new taxi/minibus/firetruck/stairtruck.,etc ? I guess beggars can’t be choosers.
Have you guys considered letting users submit scenery objects for inclusion in X-Plane? Or letting users submit Liveries for AI aircraft? Seems like it would be beneficial. Just a thought.
I truly hope you guys soon get to the point where someone can focus on assets for smaller scale airports. You want new airport submissions to the gateway. And we are willing, but we need you to help us help you.
Sincerely,
mark
Hi Mark,
always happy to see someone nag Laminar with me for more objects – but to keep fair, a lot of the stuff we got (round hangar, hangar with solar panels, small towers, glider trailers) are aimed very much at small airports.
Making many coloured variants of one thing is easy – thats why you get dozens of caravans and forklifts with different colours. Making some new SHAPE is hard.
Yet I second (and believe me, Laminar knows about it ;-)) request for more stuff to build with!
User submission is being discussed, I think, but not as easy to accomplish (quality, performance, legal aspects) as one would think.
Cheers, Jan
Hi Guys,
To be clear: we have no plans to crowd-source the _art assets_ of the gateway.
cheers
Ben
Hi Jan.
I live in the Bahamas, and the vast majority of the more than 50 airports in the country have very small terminal buildings. Most not much bigger than an average small home.
I guess what I’m looking for is more facades for smaller airport buildings. Hangars, terminals, warehouses etc. Everything we have now, as far as facades go, is way too big (tall) for what I want to create. And I’m not fond of plunking down an object that is not the right shape / orientation.
My comment about the umpteen caravans was made because it seems to me that there are way more useful things the artists could spend time creating. Fire trucks, stair trucks, covered walks, etc come to mind.
How about one, single story metal building facade that had as wall choices (wall, window, entry, door, roll up door, hangar door). This one facade would cover a multitude of uses! And would be a heck of a lot more useful that a bunch of caravans.
I’ve been waiting for years for something I can use. So I guess I’m frustrated because I thought “Finally!” I’ll have some new pieces to work with. No such luck.
Mark
Some random thoughts on bug processing:
What I really miss is some feed back if a bug was accepted as such (some reference number that might appear again in the Release Notes). Maybe even if the bug was not accepted as such (yet), the current system is clearly missing a mechanism to add additional information. Have you ever considered a (free) system like OTRS (//www.otrs.com/wp-content/uploads/2017/04/019-EN_Comparison_OTRS_5s.pdf) for handling (frontend) support mail? Of course you would be free to handle backend support completely differently (I like Bugzilla (//www.bugzilla.org/about/), but that’s a matter of taste…).
Some thoughts on build:
If you ever have worked on some github project, you’ll realize that immediately after you pushed your work, a build (and self-test) is automatically triggered for different platforms and compilers (plus a check for conflicts with other features (i.e.: branches). I think if you had a sililar system locally, you could catch some errors early, especially if there would be some AI or batch feature that can exercise the most common functions of X-Plane.
For now our process is totally manual and involves me reviewing every report and responding. I am starting a new process to respond to basically every bug report and providing “case numbers” (those XPD #s you’ll see in release notes) for you to track your bugs for if / when they get fixed & included. We’re discussing other ways to adjust our process for more transparency while also keeping enough privacy to work on Top Secret stuff. 😉
I wonder if it has been considering or discussed that making the white point in the simulator, complete white. What I mean, for example a white object (or like the reflection in the water from the sun), at the moment, is not “white”, its somewhere below white, more grey then white. Is this a limitation or a visual choice?
This might be viewed as a bug for some, but for me I see this question as a visual question rather then a problem/bug.
Sebastian
Some day I hope to make the entire engine “photometric”, meaning everything is in real physical units. Right now, like the non-PBR graphics that proceed it, everything is ratios.
Once we’re photometric, we can specify a white point and exposure level the way you would with a camera and get a real photo-quality result. Right now the tuning is trickier.
With that in mind, the ‘gray vs white’ thing is inevitable on an LCD monitor…we don’t have much dynamic range so we have to either use less than full brightness for white things in some conditions or over-expose more of the scene. With photometric calibration the choices will be better, but there’s sort of no win.
Thanks for the replay and the clarification. Looking forward to it!
Hello! very good job! a consultation! I have problems with envy when loading textures dds 4096×4096 and png 4096×4096 into stage buildings. I just apprehend structure and texture only gray. any suggestions
a consultation! I have problems with nvidia when loading
Just been reading on what Vulkan graphics is, where X-Plane is apparently heading in its optimization. Or did I misread something? “Vulkan is derived from and built upon components of AMD’s Mantle API” is to be read on Wikipedia. So it is a bit strange that the only ones getting the speed benefits at the moment, are Nvidia users…? Whats up? Been awhile since I flew due to lot to do at work leaving little private time, and because I am waiting for native VR Support (Once you have flown VR, you will never want to Fly 2D anymore, even with the low resolution of todays headsets and the akward opperating of the Knobs and dials – at least in the demo of “FlyInside”), so at the moment it doesn´t bother me as I am not often in the cockpit anyway. But would be nice if the issue is solved at some time for us poor AMD users.
(AMD r9 RX480 8Gb user here…)
Vulkan is based on AMD’s mantle, but we’re _not using it yet_. We’re restructuring our current engine (still all GL) and once it’s restructured enough, the port-over will be easier.
AMD isn’t faster because as of b4, the optimizations are turned off on AMD GPUs due to crashes. We hope to fix that soon.