EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

X-Plane 11.30 Release Candidate 1 is out – we fixed a lot of bugs!

As you can tell by the release name, we’re getting ready to kick this thing out the door.  Most of the team is no longer working on 11.30, and those of us who are are trying to make very small, tactical changes to not further screw things up. I wouldn’t bet against an RC2 (we’ve needed more than one try for all of the “really big” patches we’ve done in the last decade) but at this point if you haven’t tested your add-on against 11.30, you’re really late to the party.

Auto Toe Brakes

Flight simulators sometimes have to deal with unrealistic problems specific to being simulators and not real airplanes. One category of these “unrealistic problems” is dealing with user input hardware that is less complex than the real control inputs of the airplane. You might have a single throttle lever on your joystick, and not the 4 throttles with reversers of the 747. You might not have a twist axis or rudder pedals. You might be flying with a mouse!

Automatic toe brakes are a feature where X-Plane automatically applies differential toe brakes at times that we think might be useful if you don’t have toe brake hardware and no plugin is controlling the toe brakes. For example, an aircraft with a free-castering nose-wheel might be impossible to steer at low speeds without toe brakes. (You can’t turn the nose wheel directly, and the rudder will lack authority at low speed.) X-Plane can apply the left toe brake for you when you apply a lot of left rudder to help you turn.

In previous versions of X-Plane, this automatic toe-brake behavior was automatically applied based on some rules that Austin coded into X-Plane. When they worked, they really helped (and we know they sometimes worked because when we removed some of them in 11.30 we got bug reports), but at other times they weren’t tuned properly for a particular aircraft.

Starting in X-Plane 11.30 release candidate 1, aircraft authors can now explicitly control whether toe brakes are auto-applied for users without hardware, and if so, how aggressively. This control is auto-populated for older aircraft with the choices X-Plane 11.26 and earlier would have made, so you shouldn’t see a change in older aircraft behavior. The aircraft updating guide has the full details.

I believe that changes to these automatic rules may have been responsible for changes in third party aircraft ground handling in late 11.30 betas; hopefully with the new code, we should see complete compatibility.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

46 comments on “X-Plane 11.30 Release Candidate 1 and Toe Brakes”

  1. Seeing a few extra bugs added to this release. First, when taxiing in my BD-5J via the trackpad on my MacOS laptop, dragging my finger left and right on the trackpad no longer steers. The BD-5J steers by differential braking, so that’s probably what’s broken. Also, turning on the battery no longer activates the cockpit’s integral lighting. Another less critical issue is the heat shimmer just outside the BD-5J’s output nozzle is barely noticeable, whereas it was quite obviously present in 11.26 and felt more realistic. Yes, I’ll write up some bug reports so you can file them away.

  2. Hi Ben,
    XPD-7011 (swinging/blinking water reflections) has been around since XP11.00, but I haven’t seen it mentioned in the known Laminar bugs (nor in the fixed bugs).
    It is something that is understood but complicated to fix and therefore put on a side track, or do you need more data about it ?
    Thanks!
    Didier

  3. On the one side I’m glad to read the this (for me most annoying) “feature” got some attention. But I am assuming that I will not like the changed behavior too. I am using no pedals. But I don’t like when “someone” (X-Plane or any 3rd party author) forces me to use such “help”. It is no help for me. I’m using a script for simulating progressive toe braking. So it should be my decision what I want to use as “help” in X-Plane. For me the better solution would be to make it an option which I can enable (or disable) w/o modifying the plane itself (now). Which will be a big problem for models with an automatic updater. Because I have then the only option of disabling the updater with the release of X-Plane 11.30. Not a good solution.

    I’m hoping I can overwrite the behavior from a script via a data reference as before. As it was a fixed build-in feature. Otherwise it will be much more annoying then before.

    1. There’s a dataref that lets plugins control toe brakes. If the toe brakes in the airplane are -not- plugin controlled, you can write your own script to do whatever behavior you want.

      If the aircraft has plugin controlled toe brakes, your script is going to fight with theirs…this case isn’t the kind of thing we should have options for.

      1. Thanks for your answer. Yes, models with plane-specific plugins (like old Thranda models and earlier REP versions) are a different topic. SimCoders has “fixed” it (by detecting the script). And Thranda is not using their custom code for brakes in their newer planes. So these models are not a problem or at least no longer a problem. I do not use models which have such custom logic (like the latest version of the vFlyteAir Arrow). Because they are similar annoying for me as the old default behavior of X-Plane.

        For me it would be important that the script (not mine btw) can still overwrite the X-Plane specific behavior of “auto brake” if it is not controlled by “external” custom code. Regardless if it is in X-Plane itself (old) or if it is plane-specific (new). Without the need of changing the plane itself. But when I understand you correctly then this option will not change. I will test the script later in the latest 11.30 version.

        1. This behavior (plugin can override X-Plane’s behavior it might be) has been and remains possible – it was possible in 11.26 and is possible in all versions of 11.30, including RC1.

    2. Yes, it’s a good question whether automatic toe brakes should be configured at the aircraft level (as opposed to the equipment level) that late in 10.30 development.
      Especially with the new “curves” for joystick axes it seems like a smart idea to overly a brake curve to the z-axis. Then you’d have it all: With joystick settings being plane-dependent recently, you can add toe brakes where you like.
      Also a few words on “automatic” would be appropriate (IMHO): AFAIK automatik toe brakes used to engage when you exceed some degree of z-axis input, independent of the speed. In a few previous versions the left/right brake configuration option was gone, but in the meantime they are back (I have two buttons on my stick reserved for them)..
      I must admit that I’m doing “power slides” on the runway occasionally (while the simulation still permits; I’d expect the tyres to “peel off” for most planes in reality) 😉

  4. so the fact that the Stinson is no longer usable by the AI mean you guys finally realize something is wrong with tailgear aircraft?

  5. Well…. I’ll say something good!

    Everything seems to be working as designed when using your default aircraft or third party aircraft that have been adjusted to meet the new requirements by their designer/s.

    I am happy with your work and your constant efforts to make things better.

    1. Positive comments are strictly forbidden on this blog. This is your first warning—next time, it’ll be a ban.

      😉 😉 😉

      In all seriousness, glad to hear things are looking good for you! 🙂

  6. Seems something went wrong with HDR in VR. The TBM900s interior lights are not lighting up the cockpit anymote. This is only visible in VR. In normal flat screen the lights do light up the interior.

    1. I’m experiencing some problems with HDR in VR with landing + taxi lights on Zibo 737 and taxi lights on IXEG 737. Lights are shining inside the cockpit. Very annoying. Maybe A/C needs some kind of update for 11.30 or maybe it is a bug (bug report filled anyway). I have made a short video about the problem: https://youtu.be/AMxn6pYSYU8 .

      1. Quick question: Is the pilot flash light only for HDR? Cause this doesn’t work either in VR and could mean it’s not a plane dev related problem but one in xplane devs ballpark.

      2. Same problem here, not only with the Zibo, it happens with other planes as well. Something is wrong with the internal lights. Only in release candidate. Hopefully it gets fixed when next version rolls out!

  7. Hi Ben/team – I have a quick question on performance differences between MacOS and Windows 10 64bit. Running the following hardware i7 6700K, AMD Vega 64 with identical settings in both environments (4k resolution) I’m seeing much better performance (about double fps) in MacOS – is there any underlying reason that may be the case or something I can change to improve the W10 performance?

    1. The difference is the CPU overhead in the AMD driver – it’s a lot lower in the Mac driver. There’s nothing you can do about that on Win-10; we’re hoping it will be better with Vulkan, as we’ve found no way to improve Win-AMD perf with OpenGL through code mods of our own. The perf benefits on Windows for 11.30 really helped NV and not AMD.

      1. Thanks for taking the time to respond. It’s interesting that this would be the case. I always had the impression that Windows drivers would be more mature and fundamentally better but you learn something everyday! That really puts me in a dilemma when it comes to W10 only add-ons!

    2. Recently I had reported this issue also comparing Windows 7 and Linux, where Linux is significantly faster (MacOS is also Linux-like). Surprised as Windows seems to be the “bread and butter” platform for (almost) everyone…

  8. Glad to see 11.30 getting close to a final release. I’m curious what the implementation of the new particle system means for the future of xplane. I recall talk about waiting for particles for the new snow system to be implemented so we can have actual acumulation. I’m currently working on a scenery project which lies in an area with seasonal snow and would love to know if this is something that is being worked on or if it is a long way out still, in which case I’ll look into seasonal ortho stuff.

    Great work with the new particle system by the way

    1. xEnviro already has snow accumulation working. Check their videos on youtube. Very impressive. It looks like the release is planned for Q1 2019. They also have true “noise based” clouds, which move with the wind. It’s looking incredible. LR should consider buying it and shipping it by default… or some other similar technology like TruSKY 🙂
      Cheers.

      1. No point in throwing the cream at the cake, when you’re still mixing the batter.

        Point is, Laminar are quite clearly re-modernizing the engine to allow for the overhead to do things like this. But we are not going to get there if we don’t sort out the basics.

        Vulkan first, then even before clouds, we need to talk about the oddities in the way Laminar renders/executes things. Then we get to the cool stuff.

      2. xEnviro may look impressive with v1.10, but the version paying customers are using right now is a broken mess which the devs refused to fix. I paid a lot of money for that addon and it’s practically unusable because of the bugs. I fear v1.10 may end up just as buggy and broken as before.

        I hope LR will incorporate TruSKY in XP12, as it would be a great headline feature that will help them sell more copies. TruSKY + ActiveSky would be a fantastic combination.

  9. Ben, any word on the sun and cloud shadows flashing? It seems these may be related as it appears to be an “atmospherics” problem. The sun itself is not flashing, but the sky around it flashes from “sun-light haze” (a term I’m coining!) to solid blue sky and back. The cloud shadows can be so bad I feel like it’s going to trigger an epileptic seizure… and I’m not epileptic!

    2. Yes, this is a well known bug and is worse in VR, but unfortunately a fix is not coming for v11.30. I know several people (including myself) who have continually reported it during the past few RC periods, but no word on any kind of a fix or when it will even be addressed.

      -Cheers

    3. The _sun_-related halos in the sky flashing is fixed for RC2. While a lot of people “discussed” this around the interwebs, I did not see a useful filed bug for this until RC1 came out.

      Flicker in the cloud shadows on the ground (which is worse in VR because head motion is noisier) is a separate, unrelated, long-standing bug that will not be fixed in 11.30.

      2. The fact that the cloud shadow bug is apparently on your radar is at least encouraging, Ben. Dare I ask, but is it safe to hope that it will at least be fixed before too many more versions pass us by, or is this something that really needs Vulkan to be in place before it’s safe to fix?

  10. Found another shadow-related bug. In my BD-5J, I pay attention to XP’s world_render_type and use a custom dataref to control when the pilot’s head is rendered. I want it always considered during shadow and reflection rendering. At other times it may be visible or invisible, depending on the user’s viewpoint position. This worked well in 11.26 and is broken in 11.30r1. I have send in a detailed bug report with screen captures so you hopefully address it. Thanks.

  11. well done as usual to the XPLANE team, I always feel your approach to releases is very good despite often the surprise of negative comments. When you download a ‘BETA’ version of software you must or should be aware that you are basically trying out a combination of new items , upgraded items and bug-fixes. Yes sometimes these things do not quite work correct , well yes you should report these in a constructive way giving the conditions how the error has happened, yet many decide to report errors in a negative approach saying this is broken or that it does not work . Yet if you are patient and report the error properly when the time comes for a proper release i.e. the RELEASE CANDIDATE version , hopefully and this can never be 100% guaranteed to be perfect the download you take then will have many things fixed. I prefer this approach that XPLANE team have adopted rather than just bring out a release version and then wait for many errors to be reported and have many hot-fixes or patches until the next release. XPLANE have the best system testers in the world for checking new software before it has an official release and it the customers who have decided that it is ok to help by using the BETA versions that come out.
    Many thanks again to AUSTIN , BEN and all the team at XPLANE for sticking with and enhancing the best flight simulation software there is.

  12. Well, a couple of things that a have seen on steam RC1.

    – the “reverse thrust at maximum” is not working for me in the default 737. I’m using a saitek x55, and I has been using the throttle button number 24 (sliding one) until 11.26 without problem. I have filed a bug, but forget to say which airplane was.

    – when the objects setting is set on max, al factories have trucks, pallets, etc… but when is set on high, all that furniture diassapear (as well as autogen tiles). It’s happening me in European scenery. I don’t know if it’s a bug or it’s the way it works. And I don’t know if the US autogen work the same way (have to look at it today)

    Thanks! By now, I didn’t see any other bug. Great work!

  13. Hi. VR question:
    When will we be able to see landing and taxi lights shining outside of the cockpit from inside the cockpit? It’s DARK out there on the tarmac. 🙂

    1. I do not have this issue. I fly in VR almost exclusively and am able to see my way around the taxiways/tarmac/runways just fine using landing/taxi lights. You may need to check that your settings have HDR turned on in the slider setting.

      1. Stephen,

        Thanks for the reply. Moving my Visual Effects to HDR setting DID fix this! I don’t recall this being factor in earlier X-Plane builds, however thank you for pointing out the solution.

  14. Hi Ben,
    thanks for your awesome work. X-Plane gets better and better with every release!

    I have a really small feature request for flying in VR:
    Could you just add an command where the yoke input is centered?

    The idea behind this: If one releases the yoke it does not automatically fall back in his center position and the plane often flies anywhere but not as straight as before. By hitting a simple command one could reset the yoke to its center position and trim out the plane with the trim wheels.

    Thanks and best regards
    Stephan

  15. Hello Ben,

    I see your optimisations now noticably take away load from the CPU and so, in general, performance with 11.30 is better and really smoother.

    But, are you aware of, that the new engine exhaust effects (which look very good), really can bring down FPS a lot, especially in 4k and in cockpit forward view?

    For example, default C172 standing on runway, cockpit forward view, GTX1050ti, 4k fullscreen.
    Turning the engine on adds about 0.02 sec GPU time. (E.g. from 0.0250 to 0.0450, with vsnyc that’s from 30 FPS down to 20.)
    For testing I had deleted aircraft_system.pss and then, engine on/off did not make any difference.

    I have read many complains about performance (ok, quite normal with every beta… ; ), but some users also reported that FPS went down with more throttle and up with less. Looks like that is caused by the exhaust particles too.

    (Also someone said that performance now would be better with bigger FOV. Might be also the, then smaller, particles.)

    So, I would kindly ask you to consider decreasing the number of exhaust particles (maybe increasing alpha to compensate).

    Cheers, Jörn

      1. Many thanks!

        I had just tried XP on 4k with my 1050ti for fun, after buying a 4k monitor for graphics work.
        Surprisingly it works quite well. (I have to admit, with no SSAA and -ahem- an auto-LOD script. But, believe it or not, even with world objects on max. As long as I stay away from too many cloud layers and from NY city, I usually get 30FPS with default C172.)
        And surely, you can live very good without 4k and many say it’s not neccessary. But once tried, I don’t want to go back. : )

        1. That’s not bad considering it’s a 1050. The problem is: as soon as you dial in anything GPU-centric like AA or trying to get to 60, it’s going to run out of gas.

          My personal view is that 2K with good AA is a better investment in GPU power than 4K – the underlying textures aren’t built at such a res that there’s a lot of detail out there, so you’re basically paying for smooth lines in the most expensive way possible.

    1. Oh @#$@#$@.

      So…there was a reported bug in r1 that’s fixed for r2 (which is in the final test process now) where heat particles could appear inside the cockpit as long as they were not physically blocked by geometry. So if the heat stream made it _into_ the passenger cabin (and particles do not collide with OBJs right now) you’d see them. That’s why the throttle quadrant in the 172 is blurry.

      I put some code in for r2 to occlude heat particles in the cabin just like we do billboard particles – e.g. even if ‘in 3-d’ the particle _is_ in the cabin, we still nuke it on the grounds that the real cabin is sealed and the particle stream shouldn’t be in there.

      Now…what’s scary about what you showed in that pic is: that’s the forward no hud view…and it’s virtually impossible for us to EVER make the forward-no-hud view work the way people want. What should you be seeing in this view? The airplane interior has been _intentionally removed_ and you are seeing the space where it would have been. Should you see smoke emerging from where the tail-pipe was? How about prop discs? If the smoke is partly occluded by the cabin, do we ‘cut’ just that smoke?

      My experience with forward-no-HUD has been that it’s heavily used for external visuals and there is no consensus about what should and should not be visible in this view. I expect effects to be in the same category: if we leave them in we’ll get “this is a bug, this isn’t visible out the window” and if we remove them we’ll get “what about this thing you can see out the window”?

      Anyway, I consider this to be a SEPARATE bug than the blurry throttle handle, which _is_ fixed for r2. With the blurry throttle handle, X-Plane knows enough about the 3-d cockpit to not have the bug, and r2 does this right. With forward-no-HUD, we have no sane way of knowing what to do, except for _specific_ customization of the aircraft to meet one user’s needs.

  17. Very interesting as normal Ben, regarding the inside cabin I noticed today that I get rain or snow through the cabin.
    Has this been logged as a bug or will the above fix resolve it?

    All the very best for 2019
    Dave

Comments are closed.