I tried to rush through X-Plane 10.50 beta 2 over Friday and Saturday, in an attempt to get past a number of high profile crash bugs and installer errors quickly, despite having our Q/A person out of the office.
This didn’t work too well – beta 2 introduced a new stupid bug (the airplane lights are always on), and of course there are still plenty of other bugs.
So my plan now is to slow down a little bit and try to take time to verify beta 3 a bit before releasing it, which means it won’t make it out until mid next week. There are bugs we’ve found in beta 2 that are not quick fixes that are still quite severe, so it’s time to measure twice, cut once, not take two steps forward and one step back.
In the meantime:
- To everyone who has reported bugs via the bug reporter, thank you! We’ve gotten a lot of bug reports, which is great – it gives us a rapid picture of what’s working and what’s not.
- To everyone who has also posted their bug report in the comments section, please stop doing that! I have deleted a number of recent comments that were either “I also posted this bug to the bug reporter, but (bug report goes here)” or “this is not a bug report but (“bug report goes here”). We really need the bug reports in a single place where we can carefully track them. That place is not the blog comment section.
Tall Buildings and Data
I believe that X-Plane 10.50 beta 2 fixed the bug where the tall autogen was missing from the installer. Unfortunately this means that if you still don’t see tall buildings, it’s because the DSF doesn’t contain tall building information. A good check is to go to New York City – if it’s tall with max autogen, it’s the underlying DSF data, not the autogen.
The tall building height data that is in the global scenery DSFs now came from a mix of FAA data and user collected data from a very long time ago. Therefore tall buildings are very likely to be missing or in the wrong place outside of the US. Our future plan (which alpilotx has already made progress on; I need to examine some of the files he sent me) is to use OSM for the height data too, which should be a huge improvement.
While we do plan to use OSM data to provide DSF height data, that is not going to happen soon, and is not going to happen for X-Plane 10.50.
In the meantime, I will try to post soon the DSF information on how the height data is encoded. This will at least give third party developers the option to create DSFs that take advantage of the new autogen.
Just wanted to say I downloaded the Beta last night and it looks great!!! XP was already on another level and then you guys go ahead and raise the bar again, lol.
Keep up the good work.
Not a bug, but my 7 year old CPU and 4 year old crossfire amd video cards are only running that game at 20fps in 2560×1440 resolution. Will this be addressed in beta 3?
2560 x 1440 at 20 fps for an old machine? That’s awesome! A great deal of newer machines out there can’t even do that. Especially surprising since it’s an AMD card. I am impressed. If you don’t like it, you can always lower the rendering settings.
I think the answer basically resides in your very question. A 7-year-old CPU is not optimal for such CPU-intensive applications, and especially if it does not include a fair amount of cores (X-Plane does take advantage of multi-core machines). I have a 4 year old CPU (Core i7 3770) and a quite recent GPU (Nvidia GeForce GTX 980 Ti), but I obviously struggle a bit in the situations where a strong CPU is needed. Remember that there are some graphics settings that severely impact the CPU side, for example the car traffic density on the roads. If you think you have a weak CPU (and a 7 years old CPU should be considered such in my opinion), you should avoid pushing the CPU-intensive graphics features too much.
A last word on the crossfire feature: as far as I know X-Plane does “tolerate” it, in the sense that XP is not affected negatively by it (unlike other sims that perform worse with SLI/Crossfire enabled) but does not benefit from it, either. Therefore having a SLI/crossfire configuration won’t do miracles, especially if the weak link is already in the CPU (if the GPUs are fed slowly and spend most of their time waiting for the CPU to tell them what to do, you may have as many of them as you like but the framerate will stay the same).
Regards,
Filippo
I don’t know what can be addressed, Michael. Hardware limitations and software bugs are two different things.
But for the age of your hardware, and at that resolution, 20 fps ain’t bad. But as @Chris and @Filippo said, you must consider you rendering options, as well as hardware bottlenecks.
Keep on flying!
– Joe
Here is a tip for gui usability Ben..
When users are to revert back to the official release, i.e. from 10.50b2 due to crashes and bugs, you should have a checkbox that says something like this
” Click yes to apply to all the following selections”
Is was no fun manually clicking every “overwrite previous file” message that comes up, there is a lot of dsf files to overwrite he he.. So yea, a “remember my choice” would be fine 🙂
Waiting for a working 10.50 back in 10.45
Good luck
The current installer tech does not have a way to -safely- roll back a beta. It’s a fundamental problem with the way that installs are built.
Simply saying “auto-overwrite” is not great – that check is designed to prevent data loss, so I am loathe to remove it or bypass it.
I am with Tom on this. I do not plan on going backwards this time, but being that it is easy to update and somewhat easy to go backwards, it would be nice to have a button to “Overwrite ALL” like it does in the upgrade process. If you allow us to take risks in the Beta, I see no difference in the risks going backwards. They are both on us as the user who choose to go that route. Normally I would use my no production folder to test the Betas, but sometimes I find it easier and more convenient to just use my production version. Thanks.
I fully understand what Ben is coming from, but as an end user we like simplicity. But I am content as it is, first time rolling back, so this is just an “whish have” feature for me based upon my experience.
I do, as the beta test instructions recommend, a full copy of the installation directory and then upgrade that new directory (only) to the beta.
So going back is as easy as starting XP from the old directory … even deleting the new directory is optional 🙂
Great work Ben.
I now run extreme objects with very high LOD (the way it’s meant to be…) at a locked 30fps (sans hickups / microstutters) even in NYC, LAX ect., something that wasn’t possible in earlier versions, PLUS it looks so much better now due to the new art assets. A real treat.
Only very few airports seem to support static AC as of now though, but I am quite sure this will be addressed by the authors soon.
My experience is that lots of airports have statics but very few have -a lot- of statics because authors are still sometimes only putting 4 or 5 ramp starts into the airport. I am hoping authors will start being more thorough about ramp starts; putting only a few ramp starts in dates back to v9 when the ramp start UI didn’t scroll. Not only is this fixed, but at FSConn we showed Tyler’s next-gen ramp start picker, which gives you a visual map of the airport. With the visual map, you can have 100 ramp starts without a problem.
Hi Ben,
Someday, after the fire fighting, could you publish a bit the development process of XP ?
I know how much it is difficult to maintain a huge code base and I’m wondering which tools you use to build your own CI/CD pipeline.
I can post someday, but the tool chain is mostly built out of coffee and whiskey. 🙂
There is no whiskey for the pipeline but I know what you mean for the coffee. 😉
Maybe it’s time to enhance the pipeline to limit the regression and then to lower the consumption of whiskey 😉
Anyway, keep up the good work!
please read: “There is no whiskey for the pipeline [I use at the office]”
Maybe you could stop most people from posting bug reports here by adding a notice and link to the report form next to the “Post Comment” button? Should be possible by just adding a short HTML snippet to one of the WordPress theme’s files (not sure which one it was).
Am i right in Thinking the new Autogen system , is currently only providing tall building information for the United States ?
Yeah I think Ben mentioned this, the current DSF height data is not based off of OSM but from a patch work of other sources that are quite old. I think the plan is to utilize OSM height data in the future.
On several of your earlier blog posts, you mentioned “per airport flattening” as a feature planned for X-Plane 10.50. I don’t see any mention of it in the release notes and I see that the “runways follow terrain” box is still present in the rendering options menu.
Is per airport flattening still planned as a feature in 10.50?
It is planned – but you need 10.50 to access it.
EDIT: 10.50b2 has the support on the x-plane side, but without 10.50 you can’t access it.
I’m assuming that you meant to say that without WED 1.5 we can’t access it? Or did you mean that this feature won’t become active until 10.50 goes final?
Oops – that should read: you’ll need WED 1.5 to create your own static aircraft-capable ramp starts in 10.50. The 10.50 code is enabled now.
Do you have any idea when WED 1.5 will be released?
“Soon”.
Should be “Soon™”
Are you mean WED1.5?
Ben…This is a great update, a new level for xplane!
Keep up the excellent work, no rush except for the rushes associated with excessive coffee and whisky lol…and sooner or later xplane 1050 will be final for all.
It looks great ! You guys are doing a great job, so much better than the competition. Yea a few bugs but I am sure you will work them out. Keep up the great work !
I’ll add to everyone else, the new 10.5 looks stunning. Great job.
I’m on steam, so I’m currently running the beta via the demo.
Could I ask if any of the art assets like building night lighting etc work outside of the USA?, or, like building heights, is this currently USA only?
Only if there is data – my impression is that there isn’t much height data outside of the US.
Hi Ben
I have been looking at the release notes, haven’t found any comment regards lights. ie. beacon light looking way too big and powerful. Is this being targeted for 10.50?
thanks!
They’re just broken in beta 2.
You posted on Sunday last that Beta 3 will be out “mid next week”. I write this on Wednesday evening, 22 June. By “next week”, did you at that time mean the week following that Sunday, that is this week, or what is now next week?
(I hope you can see I am not pushing you for a release date!)
That “mid next week” estimate was too optimistic. Jennifer is back and is testing the product, but two things moved beta three back:
1. It became clear that she has a LOT to test and we’ll all be better off doing it right and
2. Additional bugs have come in since Sunday.
At this point I do expect to have beta 3 posted, possibly Friday, possibly Saturday. Possibly neither of those days – these things are highly unpredictable.
Cheers Ben. Your hard work and Jennifer’s are very highly appreciated by all of us.
Even with all beta bugs, 10.50 is looking awesome and will only get better as it matures.
Thanks Ben, Laminar!
Yep, fix the beacon Ben lights and call it RC 🙂
I see we are in Beta 4 now.
Hi, confirm the fix of lights and a very well fps with 10.50, unfortunately continue to be unusable with airports in zones with photoscenery, I notice ubnormal use of memory (in my case use all 16gb during asynchronous). However I’ve send a bug report