X-Plane 10.10r3 came out this weekend – go use it! This is my expectation over the next week:
- Barring a truly horrific bug, we’ll probably declare 10.10r3 to be the final build of 10.10 and make it live to everyone.
- We will probably cut a 10.11 bug fix patch within the next week.
Why do I expect 10.11 so soon? Because there is always one bug that we don’t find out about until we make the rc live to everyone – inevitably one hour after the build goes live, someone reports something that no one saw in development, no one saw in the company, no one saw in beta, that we want to fix. Murphy’s law is irrefutable.
In the case of 10.10, the rate of bugs coming in on 10.10 has slowed down a lot, so if we continue to fix bugs in rc, we’ll be fixing bugs at a very low rate without moving on to the next thing. Thus it’s likely we’ll “kick it out the door”, get our one late bug, and cut a quick patch. We may also get additional localization into 10.11, depending on what we get from our translators.
It looks like the next sim patch after 10.1x (e.g. 10.10 plus any bug fixes) will focus on finishing and shipping 64-bit, hopefully with more autogen coming along for the ride.
As always, please report bugs to the bug reporter, not the blog, and not email; link is on the right.
(A quick side note/rant: my email server kind of exploded a week or two ago – lots of emails bounced, lots of emails were lost. This is one reason why I do not want bugs by email! I am always threatening “if you don’t file a bug, it might be lost.” Well, if you sent me a bug by email, for all I know it was lost. Please use the bug reporter!!!)
Awesome news for what’s next
I have been using all rc’s heavily and for me each release was smooth. I’ve been playing with the road and autogen settings for hours, it’s all very solid and predictable now in terms of FPS, and that I think is a good sign. Talking about roads, which for me are, aesthetically, the heart of XPX, I noticed you changed how the “sliders” effect the level of detail here. I think for the future, I would really like one additional setting for road detail, to make it independent of the objects amount setting. This way, we could have full road detail while having the amount of objects at “a lot” (minimum for street lights at night) – a perfect setting for dusk/dawn/night scenarios where full autogen is not needed (or will fry your ram). As I said, everything is smooth, but it is a pity street signs are gone with “a lot” objects, just because my machine can’t handle more autogen. I am aware of the hostility of the team against more settings options, but I think the roads truly deserve that in X-Plane 10!
Well, it’s not that we changed the sliders – we put in new art assets, and they are affected _differently_ by the sliders.
Here’s a key detail: the “number of objects” setting in x-plane controls more than just “buildings” – it can actually add and remove objects from facades (which affects airports) and roads.
Our goal is to refactor the sliders as follows:
– World LOD will affect the distance of all 3-d (not just some).
– Forests will control the DENSITY of all vegetation but not the distance (that’ll be LOD like everything else).
– Objects will affect the number of non-vegetation models across ALL parts of the sim (more 3-d models vs less).
– Roads and airports will be a detail control for roads in general and airport taxiways in general – they’re sort of catch-alls.
There’s another idea that goes along with the above refactoring that we want to get to: in the future, when you turn down the obj density, the _footprints_ of the autogen will remain – they’re cheap and having them on the ground is necessary to avoid the golf-course look. In fact, when Alex and I first designed the v10 autogen system, our intention was always to keep footprints and ground detail _even_ if 3-d wasn’t available.
In otherwords, our idea is that hw has arrived to the point where we can build ‘virtual orthophotos’ from multiple layers of pure green ground, roads, and building lot-footprints all stacked up. That’s how we get realistic looking terrain in cities _and_ real world road grids.
Sounds very good! I have noticed that the current LOD setting does not affect night lighting, is that correct? When I jump from “low” to “very high”, visibility of the highways seems to stay the same. Which is very good. Or is the visibility of the highway lights connected to LOD and I haven’t noticed? It just seems at night performance is a lot better, so why not have maximum visibility for highways.
When are you planning to refactor the “sliders”, 10.20? Until then, which setting is required to get highway signs back. I suppose it’s “mega tons” and it means 32-bit exodus for me… 🙂
After 10.20 – we’re really trying to keep the next patch down to more art assets and 64-bits to keep it from becoming an ordeal.
Lights do have their own LOD rules, but even though they are fast, there’s a real cost to having them go on ‘forever’…
I thought about this recently, but maybe that is something for XP11… a dynamic LOD system depending on your actual altitude. Giving you “too many” objects and trees in a “low” range while you’re at 500ft and chasing the highway, and spare them out but very high LOD radius when cruising at 8000ft…. dynamically adjusting while you climb. While it would probably take a new loading system and a lot of memory, it should be possible to accomplish. After all, it would be nice to have settings that adjust to your situation, instead of the user hopping into the menus during flight. Add it to the 128bit list, maybe…
Way to go guys! I’m truly looking forward to 64bit! I just bought the new Dreamliner and the only way to run it smoothly is with basic rendering. But thats fine for the mo while i get to grips with it! It’s stunning!
keep up the good work!
Since revision 10.05r1 I am booked for beta updates. I am now at 10.10rc4, experienced a few crashes which can be now automatically sent. Fine so far and very convenient. With the rest of the bugs to report – and which you are stressing to do so – I have my doubts so far because there is NONE response from your side, although following all the rules to file a report. We voluntary beta tester trying to use all the new features available back and forth, but …. What is with the old stuff? Checking the log.txt file after each flight there are still the old error messages like errors in the apt.dat, aircraft which are incomplete or reveal loading errors of missing files, parameter errors, and the voice pack has still missing .wav files, the ATC is announcing “Don’t send me co-located points” although there are none: it’s a bug which cannot handle taxiway routes going from ramp-start locations to an all connecting taxiway, etc.
I completely understand that it is of minor interest for a developer to fix these old stuff, rather looking into the future and create some new features or fullfilling wishes of experienced users.
Amazingly, the simulator runs very well, even with these minor glitches. But for the sake of completeness Austin and his crew should take some effort and fix this in a new version.
Regards Lutz / Cape Town
I know the M.O. right now is to submit bugs and not expect a response, but it might be a good idea to have someone do general follow-up on some of these things. A response makes people feel like they are not being ignored, regardless of whether they are (or are not) being ignored. It can go a long way in ensuring users stay happy, even when things are not perfect. It doesn’t even have to be communication between the devs and end users, it can be some sort of intermediary.
So another thing… right now there’s no way to follow-up on a bug. There’s no help desk system, automated email, or anything else that might indicate the status of a ticket. The other day I found that I had more information on a previously submitted bug, but had no way to attach it to that ticket, forcing me to submit a brand new ticket.
Lastly, do we have a method of submitting feature requests? (e.g. preview of liveries in Open Aircraft screen. ;])
I don’t have a good answer for this right now — it is something we have discussed internally. I will try to comment this in more detail in another blog post. The flip side of this is: a lot of junk comes through the bug reporter, and the current system is annoying to anyone who submits a high quality bug report because the system is designed to allow us to not be killed by the huge amount of noise that also comes over the bug reporter.
And if you are reading this comment, you are probably not the source of the noise. The bug reporter says two very basic things up top: 1. it is not tech support and 2. please give us a log. You’d be amazed how many bug reports ignore this, making us think that many submitters don’t read any instructions we give them.
Anyway, I’d describe the setup we have now as a work-in-progress. The automatic crash reporting was a big help in that it removed crashes from the bug stream. (Or put another way, the bug reporter isn’t a required source of info about crashes because the auto-crash-report system gets us so much data.)