There’s a bug in the latest installer/updater: if your machine’s default language is Portugese, it will crash. I will post new installers that fix this as soon as I get back home on Monday (maybe Tuesday if the snow storm is bad enough).
For now, the sim will run, even though the updater will not.
Posted in News
by
Ben Supnik |
10.20 release candidate is out now; see the release notes for a list of changes. There are two sets of bugs that we didn’t get to:
- Some users on Windows are having sound problems; I will write more about this shortly in another post; we’ll fix this as soon as we can.
- I have a set of bug reports relating to the airplane exterior lighting; I hope to get those fixed in a 10.21 build (as well as whatever one bug gets reported the day after 10.20 goes final).
Plugin authors: if your plugin has a problem with 10.20, you should have reported it weeks ago. The 2.1.2 SDK is done, 10.20 is a release candidate, so the 64-bit SDK is ready for you and has been for a while now.
We will continue to slip additional airplane improvements and autogen into updates as we get them from our art team.
ppjoy users on Windows have been experiencing a crash on startup; this was a bug in X-Plane 10.10/10.11, induced by particular virtual HID devices that only ppjoy could make. I found the problem and it will be fixed in 10.20.
In the meantime, if you need to use ppjoy and want to work around the problem, set your hat switches to discrete directions, not analog. (X-Plane can’t use an analog hatswitch anyway; most people have this because it is a ppjoy default.)
As a side rant to ppjoy users: I was a bit horrified with the process of installing ppjoy. ppjoy is an unsigned driver so I had to turn off driver signing in Windows. ppjoy is also, as far as I can tell, not hosted anywhere official. So I had to install an unsigned driver off of a file locker onto my Windows machine with the safeties off.
To be clear, I do not think that this is the author’s fault. He is making freeware, and the only thing that would remedy these problems is money. I do not and cannot expect him to give up not only his time (to code) but also pay to solve the distribution problems of official hosting and buying a signing certificate.
Still, the process of taking off all of the safeties to put random third party binary software on my Windows box was unnerving and not something I would ever do as an end-user.
As far as I know, the ppjoy crash and the PS3 controller crash are the only two known regression bugs* with joystick hardware, and they’ll both be fixed in 10.20. (Linux users, needing to edit udev rules to use hardware is not something that we consider to be a bug – see this post.)
When will 10.20 go final? Real soon now. Plugin authors, if you aren’t already running on 10.20 betas, you should have been doing that weeks ago.
* Regression bug means: it used to work in 10.05 and stopped working in 10.10 when we rewrote the joystick code.
It’s been a slow week – I’m sick, Alex was sick, Chris is sick, Chris’s wife is sick, my wife is sick, Chris’s daughter is sick, my son is sick…basically all of New England has bubonic plague. Skype meetings sound like a 19th century sanitarium for TB patients. But we are making progress on 10.20 betas. What’s still left?
- There are a handful of new 10.20 bugs that I still hope to resolve before we go final: sound problems, Intel GPU compatibility, etc.
- The installer needs to be made 64-bit aware.
- There are a handful of authoring bugs that were present in 10.11. I may push these off to a 10.21 bug fix patch, so that we can get 10.20 out the door sooner.
Users: please stop asking your favorite third party developers when they will release a 64-bit version of their add-ons. The devs are really stuck until we finalize 10.20. If they release an add-on before 10.20 goes final and then something comes up during beta, the dev is stuck fire-drilling a quick fix of the add-on.
Thanks to everyone who offered help WRT Intel GPUs. I have been in contact with the Intel driver team and we have a potential work-around for the HD4000 GPUs crashing. We do not yet have a fix or work-around for Gen-4 (GS45 chipset) GPUs crashing.
We also do not have a work-around for black sky with Intel HD GPUs and HDR mode, but honestly if you have an Intel GPU, I recommend keeping HDR off for frame-rate reasons. (I only have the HD3000 though – it’s possible that the GPUs on the new Ivy Bridge chipsets are faster. We’ll know once the shader-compiler issue is fixed.)
EDIT: when this article was originally written, the 2.1.2 plugin SDK was not available, which caused a lot of confusion. The new SDK is now posted, and the building instructions are completely updated.
Beta 11 is out and this hopefully has the final set of SDK changes for 64-bit plugins. Besides a bunch of other fixes (see the release notes), here’s the rough state of plugins:
- 32-bit plugins should just work. If you have a plugin that worked in X-Plane 10.11 but is broken in 10.20, please report a bug – even if it’s not your own plugin! I really want to hear about any of these cases.
- 64-bit plugins should just work; if they don’t, it may be due to programmer error, so please only report a 64-bit plugin problem if you wrote the plugin.
- A new SDK (2.1.2) is cut with real frameworks for the Mac; Sandy and I spent a pile of time working on this, but I need to update the wiki instructions. Docs coming in the next 48 hours I hope.
- Name and shame is gone for linking, so the logs should be clean. If your plugin crashes, you still get named and shamed.
X-Plane 10.20 beta 9 is out and (hopefully) fixes missing library paths. Alex and I spent a good chunk of yesterday trying to clean up the tools that generate the autogen library, but it is a very complicated problem, as indicated by the 4786 distinct entries in the library.
Beta 8 and 9 introduce a change in how the rendering settings work; my suspicion is that users seeing a framerate drop in the new betas are seeing the effects of the intermediate rendering settings acting differently; the minimum and maximum for the settings should produce nearly identical results.
I’m not going to try to explain how the settings used to work – the actual results were extremely convoluted due to quirks in the engine. This change is one of several we want to make to both improve how the settings work (from a usability standpoint) and improve the look of the autogen at lower settings.
- The “objects” popup controls the amount of autogen and 3-d stuff in general. Besides adding more autogen, it adds more detail to the autogen as it appears and can even add more detail to custom scenery. (This behavior isn’t new.) In particular, if you use an a complex library element like an “AGP” scene (e.g. the control tower or FAA building) the amount of detail of that mini-scene will increase with the objects setting. The goal here is to have the objects slider control the amount of 3-d.
- The “forests” popup now strictly controls the density of all vegetation in the sim. This includes both the natural forests (.for files for DSF nerds) and the vegetation that is part of the autogen (e.g. the trees that Alex puts down on the lawns of houses). Lower forest settings tend to prioritize the rural forests over autogen trees to save framerate.
- The distance to which 3-d is drawn is controlled by “world detail distance” – this is how far anything 3-d is drawn out to. Finally with this change, this affects the forests as well as the autogen and the roads – everything runs to the same distance.
A few tuning tips:
- If you are running 32-bits, turn “world detail distance” down by at least one notch; having a shorter distance for 3-d will allow the sim to save some memory.
- If you run with full autogen, moderate forests, and highest world detail distance, you may now need to turn forests up and world detail distance down to create the equivalent of what you used to see. In older betas, the forest setting modified world detail distance in some very strange ways.
Our eventual goal is to keep the autogen base footprints even when the object count is very low; the footprints of the autogen contain views of the building tops, allowing for the equivalent of ‘orthophotos only’ for users with very low rendering capabilities. This will help avoid the ‘sea of green’ effect on lower settings. (The behavior now, where whole city blocks disappear) will eventually go away, to be replaced by the “footprint” with roofs of the city block when 3-d is turned down.
These pictures illustrate the effect of world detail distance. Note that the ground images attached to the buildings are still present even as the buildings begin to disappear with lower settings. The last picture shows the autogen with most 3-d buildings stripped away to reveal the ground tiles underneath.
As we keep working on the autogen system we’ll get more and better ground textures in place, more and better ground tiles on the autogen, and yet more buildings; the result should be a reasonably seamless urban experience at a range of rendering settings.
Some cities are “over-green” in their underlying data in the DSF – this happens when the source land class is difficult to ‘fit’ into the grid system efficiently. (Typically a little bit of vegetation or water area affects zoning and ‘greenifies’ a large area.) We will have to address this problem in DSF tile recuts. (In other words, zoning errors are a failure of accuracy compared to the source data, to be recut; adding more autogen improves plausibility by providing a wider variety of “stuff”.)
I hate to put time estimates on anything. The reason: timing is subject to change and always has a ton of uncertainty. What we internally is not a schedule. A railway has a schedule; we have a plan, a roadmap, or some goals. Betas are full of uncertainty. We don’t know what bugs are in the sim – if we did, beta would be over a lot faster.
So: this is my current thinking on the timing of the rest of the 10.20 beta, as of now. It will be obsolete within five minutes. Since most of the time schedules get screwed up by things being late (if we were ahead of schedule we could just choose to not release to be on schedule 🙂 this is post may be useful for third party developers trying to plan releases.
If things go well, I believe we will be able to build a 10.20 release candidate this year. (That’s a tighter goal than it sounds – there are only two weeks left.) I think we will not finalize that release candidate this year; more likely we’ll sit on the release candidate into a little bit of January. The release candidate will hopefully be settled enough that there are not any engineering surprises for third parties if we have to recut the release candidate.
If things go badly, we won’t be RC this year – there’s always the chance that someone could have a sick kid, a power outage, new bugs could be found, you name it. Life is full of uncertainty!
I do not know what autogen will get dropped into the beta or when. If we have autogen that is almost ready for 10.20 but misses the release deadline, we’ll drop new art assets into a 10.21 or 10.22 – it’s very easy for us to do a bug fix patch with more “stuff” in it.
If I was gambling, I’d bet that there will be a 10.21 anyway – what we found with 10.10 is that a lot of users didn’t participate in the beta, and thus we got a flood of bug reports right after 10.10 went final. This can be frustrating for us (in that it means that our beta coverage isn’t as good as we’d like in terms of hardware configurations) but it’s also good in that it means that the entire community isn’t in on the beta (something we don’t want – we don’t want to expose every X-Plane user to beta bugs!).
10.20 Beta 6 is out – this build fixes the missing paths in the library that were causing the dreaded “Could not load fac/forest/beach” error. This build also puts in some important changes to 64-bit plugis, so below I will try to point out what matters to select audiences:
Users:
If you don’t make an add-on but you are still testing 10.20, there is still a kind of testing that we need (but you may not like it): is anything broken in the 32-bit edition of 10.20 that worked in 10.11?
This kind of bug (it worked in the old version but is broken now) is called a regression bug in the tech lingo, because the sim has “regressed” – it has gone backward. This is the most important kind of bug for us to find for three reasons:
- No one wants to go backward.
- It’s easier for us to find the bugs in new features than random bugs in features we didn’t think we had changed.
- If you report a regression bug against two versions of the sim (it worked in 10.11, broken in 10.20) we have tools to see only the code changes from 10.11 to 10.20, which makes finding the bug much quicker.
So: please try the 32-bit 10.20 and if it fails at something that 10.11 did, please let us know ASAP!
Aircraft Developers
This build fixes the prop disc and airspeed indicator, and finally provides more datarefs for the anti-ice system; I suggest rechecking your airplane with these systems. At this point I think I only have two airplane issues floating around on my radar:
- The new light billboards and spill can be tricky to use, particularly when lights crash through the fuselage of an airplane.
- The manifold pressure indication is FUBAR on helicopters.
Both of these bugs were present in 10.11.
In fact, we have no regression bugs on file in the airplane system between 10.11 and 10.20 32-bit. So if you know of something broken with your airplane that is newly broken in 10.20 32-bit, please report it ASAP. (You do not need to re-report bugs that were already present in 10.11 like the manifold pressure.)
Plugin Authors
This build integrates a fix for LuaJIT on 64-bit Macs; see the release notes and plugin SDK for how to use it.
This build also strips out the symbols of libpng, libcurl, and libfreetype2 on Mac and Linux. These symbols never should have been visible in X-Plane, but they have been for years.
- If your 32-bit plugin used to work on X-Plane 10.11 but stops working on 10.20 32-bit beta 6, please file a bug and we will figure out what to do.
- If your 64-bit plugin use to work on 10.20 beta 5 but stops working on beta 6, your makefile or X-Code settings have a bug; post to the x-plane-dev mailing list to get help.
There may be future changes to 64-bit like this one; this is why I recommend not releasing while we are in beta! Our goal is to ‘get 64 bit right’ now during beta while we can try and test.
Scenery
There are no open regression bugs from 10.11 against scenery; facade textures were borked and are now fixed, and the library should be restored. So if your scenery pack worked in 10.11 and fails in 10.20, please report this ASAP!
I do have one open bug (present in all of the v10 run) that line markings are losing line segments; I hope to get that fixed by the end of beta.
(We also have a report that certain incorrect ATC/apt.dat files will hard-crash the sim – I think Chris will probably be able to get some better validation in place before beta ends.)
Two new add-ons out in the last few days:
The first is AlpilotX’s New Zealand Pro scenery. This is a recut of all of NZ using higher quality global data, the global scenery algorithms run at higher settings (no need to tone them down if the whole world doesn’t have to fit on 8 DVDs) and some custom GIS algorithms Andras came up with to handle various features.
For me it’s exciting to see what the engine can do when someone let’s it a bit off of its leash; the global scenery is always a compromise between the possible and what can be done for all users over the entire planet – it’s a compromise to make a base layer.
NZP is donation-ware. Andras* is not a Laminar Research employee – he is an X-Plane user who has gone so far with his scenery work that he works directly with us on the global scenery; we are very lucky to have his help — his contributions make X-Plane so much better, both when he works on the global scenery and on his custom work.
* Albert, who does the textures, is in this same category – they are two of a number of X-Plane users who have made outsized contributions to the sim!
Second, the McPhat ATR-72 is out. I had a chance to meet these guys in Mallorca, and see some of their work-in-progress and the stuff on their laptops was really phenomenal. I always enjoy seeing people push the envelope; it gives us an idea of where we need to provide more ‘headroom’ inside X-Plane.
On the subject of betas: I don’t know when beta six will come out – I think sometime next week but I don’t know if it will be early or late in the week. We do have a potential fix for the library problems with autogen (the 10.20b5 drop with new autogen is missing some library definitions) so that should help people using custom scenery who are getting the dreaded “could not load forest/facade/beach” message. (We changed our tools for the new autogen and accidentally lost some library paths which we are putting back.)
The old library did accidentally have a lot of library paths with the word “test” in them; I really hope no one is using them in their add-ons. As a general rule, if the word “test”, “temporary”/”temp” or “hack” is in a library path don’t use it!
Posted in News
by
Ben Supnik |
I probably should have said this earlier.
Please do not release 64-bit add-ons.
If you want to beta test your add-on in 64-bits, great! If you have gotten 64 bits working, that’s totally cool!
But, please don’t ship 64-bit code. The problem is: we are still in beta and there are still open issues with 64-bit plugins that have not been resolved. If we make changes to the plugin system during beta to make 64-bits work right and your add-on is broken, you won’t be able to react to it if it is already released.
So wait – make sure to test against the RC. Like new features and scenery file formats, while the new features is in beta, it is unstable and we’re not going to try to ‘protect’ you from change. Once we go final, things will be set in stone but we are not there yet.
(In beta 3 we changed our address space layout on Mac…that should give you an idea of how new this stuff is.)