A few betas went by and I didn’t have a chance to write things up. The short version:
- 11.10b8 just went up – release notes here.
- We’re mostly down to small bug fixes – no more big flight model changes.
- The next build will probably be 11.10rc1.
- We’ll get Steam updated in the next few days – Philipp’s been traveling a lot.
There are no remaining major enhancements that have to go into this beta. Here’s how some of the big technology changes played out:
- The new manipulators are in – I’ll write up a separate post tomorrow on those. They went into beta 6 (hence all of the weirdo bugs) and are now fully working.
- All of the new weapons code is in – dataref access to weapons is restored. Jörg has a few crash bugs to nail down with networking and weapons, but that’s it.
- Audio events had to wait – I’ll write that up in a separate post. They’re something we wanted, but realistically we never had time for them in 11.10.
- The last round of performance enhancements for graphics is going to wait for the next release patch.
The bad news is: AMD users aren’t running 11.10’s fastest path due to problems with our current code and drivers. The good news is: the next round of enhancements do work with AMD cards, so we can get back to treating them normally. That code is now looking reasonably stable, but it wasn’t stable early enough to make it into 11.10. I think it will be available in beta this year though.
Finally, there was an open question of how to use glScissors in a plugin with the new UI features (e.g. floating windows, multi-monitor, 150% UI, etc). As of beta 8 this is fully possible; I just need to get the sample code to Tyler to post.
Two flight model notes for aircraft authors – the executive summary of all of these is pretty much “it should just work and you don’t have to do anything.”
Steering Gear Rate Limiting
X-Plane 11.10 has an option to rate limit how fast gear that steer can turn. This is a good thing – in the real plane you just can’t turn that tiller very fast, but if you have a $20 Microsoft Sidewinder from 2002 with the throttle tab broken off (for example) you can twist it to full deflection almost instantly. When this happens, X-Plane turns the wheels instantly, and since they’re not at a 70 degree angle to your movement path, they skid like Ken Block landing a Baron. Once the wheel is in skid it has pretty much no ability to turn the plane and you just skid.
With rate limiting, the wheel will turn a little bit, and be able to put out side force, helping the plane begin to rotate. As this happens, you can turn more and gradually angularly accelerate the aircraft into a turn.
So … rate limiting is good – you should use it! But the compatibility code in beta 7 was pretty broken – it set the minimum rate to 1.0, which is way too slow for a bunch of aircraft.
Beta 8 fixes this – the minimum rate is 0 (meaning no limiting) and this is the default for 11.05 planes.
Here’s the warning: if you saved your aircraft in an earlier beta, you’ve baked in the long gear deflect time – you’ll have to go into Plane-Maker and turn the value back down again.
Just One Turbo-Prop Model
X-Plane 11.10 had two options for free turbine turbo-prop engine models: the “v10” and “v11” models; all 11.05 planes showed “v10” when loaded in Plane-Maker.
We’ve backed this out – there’s just one model, “turbo-prop (free)” in beta 8, and if you picked the v11 model, we’ll mark it back to v10 for you. (You shouldn’t be shipping aircraft saved in a beta anyway, but we check for this in the sim itself too.)
Here’s the back-story: X-Plane models the compressor turbine speed of a free prop turbine like the PT-6 as “N1” and the prop turbine speed as “N2”. Austin has come to regret this decision, as the prop turbine is a lot more like the turbine that drives a bypass fan in a high-bypass jet engine, and the compressor turbine is a lot like the turbine that drives the core in a high-bypass jet engine.
So Austin cut a new version of the engine model with N1 as the prop and N2 as the compressor, exactly backward from 11.05.
The thing is: while the new model matches Austin’s brain, it doesn’t match any aircraft ever made, and swapping N1 and N2 in an add-on is a pretty expensive update. Realistically we’re not going to ever deprecate the old model for the new one in any time frame if this much rework is needed.
So we’re keeping the new model ‘in the lab’ and not releasing it for now, as it doesn’t have significant changes in how it models the engine itself yet. This frees Austin up to improve it on his own schedule and frees us up from having to maintain another point of version compatibility. Since the new model doesn’t have any enhancements (other than renaming N1 to N2 and vice versa) you’re not losing out as an aircraft developer here.
Is there any word on when WED 1.7 will be available? Jan’s video has lots of people interested in the new Poly taxiway markings.
No — we’ll go public beta once Michael’s ready to ship his latest features.
The poly taxiway markings can be done in WED 1.6.0 (and 1.6.1 if you can find the download!). You just have to know to pull the right-hand-side window out to find the Texture tab.
I think WED 1.7 is all about the facade preview (wooop!).
You can use the polygons in any version – but in some version (I think 1.7, but I’m not 100% sure) you get the new editor that makes it easy to pick out the UV map for the letters.
WED 1.6.0 has all the new polgon features already and that was used for Jan’s video.
WED 1.6.1 is final and accepted on the gateway now, but the only real new thing is that it allows the polygons aka ground painted signs to be submitted to the gateway.
WED 1.7.0 has no changes for polygon editing at all.
Hello Ben,
I can’t wait for 11.10 release! 🙂 Especially due to:
– Command line can be used to override desktop topology for Linux setups.
Is there any hint about syntax of this command? Will it allows us to use XPL in fullscreen mode with multiple views on multiple monitors? Thank you.
I think it refers to –monitor_bounds=l,t,w,h
Repeat multiple setes of four, e.g.
./X-Plane-x86_64 –monitor_bounds=l,t,w,h
Mind you: on Linux the Window manager has a way of screwing up our window layut .. that is BEYOND our control because the OS doesn’t provide a way to position windows where the WM doesn’t hose them. If anyone with Linux X11 experience wants to look at this, I’d be happy to share the code that does this for Linux, but right now we do not have the flexibiltiy we have on Windows to say
1. This window goes here.
2. This window has no decorations.
3. This window is on top of EVERYTHING.
Hello Ben,
thank you very much. Until now I had the problem with XPL not detecting ore than one monitor even if xrandr correctly detecting all. Therefore I was unable to setup multiview. I will try beta ASAP to test if I can force XPL to see all connected screen. Anyway I am ready to test code – I have Ubuntu 16.04.3 test rig to play on with multiple screens on single nvidia card.
Kind regards
Litin
My experience is that xrandr _sometimes_ can figure out there is a second display (and sometimes it can’t) and any time we try to change what the displays do (e.g. change res) the X config gets borked and we lose a display entirely.
The short of it is: between the low platform adoption of Linux and the relative messiness of trying to do basic tasks using the platform’s APIs, I don’t have dev time to pursue better multi-monitor support. If anyone wants to contribute a patch, I’ll be more than happy to dole out the relevant platform code – it’s all separated out and easily testable outside of X-Plane. This is how we got screensaver inhibition…a very patient Linux user wrote 700 lines of insane Linux code to implement what we get from SetThreadExecutionState on Windows.
Hello Ben,
with all regards you do not have to do “everything” in Linux from scratch. For example blocking screen saver – it would be enough to write in readme – “dear user please disable screen saver” (install caffeine for example). Same with resolution – “dear use please set your resolution manually”. Therefore I do welcome your approach of letting us set our screen topology by command line.
Just one question to your example – If I have 2x 4k monitor side by side, will it be:
./X-Plane-x86_64 –monitor_bounds=0,0,3860,2160,3860,0,3860,2160
???
Thank you.
Kind regards
Litin
,
Right – we used the README based approach until we got the code contribution for the screen saver. But this still creates a gap in experience – things that we polish and have “just work” on Win/Mac appear “broken” on Linux.
The full screen stuff is messier — for example, the Window manager putting the windows in random places is hard to defeat unless you really want to hack the crap out of your window manager.
You have the syntax right for side-by-side 4K, e.g. if you want to absolutely bury the crap out of your video card.
Hello Ben,
I did test monitor_bounds feature and:
– it spawns two windows but only in fullscreen (and I can not switch to windowed mode – even such option is missing in the config Graphic menu – first it is present on fist monitor, but second has only fullscren mode option, when you select it then windows mode is no longer present on first monitor as well – so you can not effectively switch into windowed mode at all)
– even if system is previously configured in windowed mode, using monitor_bounds will switch it to fullscreen
– it spawns both window on 0,0 positions
– it sometimes crash, but I was not able to send crash report, I will check again on different network (our company proxy?)
– my test was now performed only on my development NB with attached LCD: –monitor_bounds=0,0,1366,768,0,1366,1920,1200 (Ubuntu 16.04.03, Intel integrated card)
– I will repeat my test later today on my sim.
Kind regards
Litin
If the two windows end up in the same location (0,0) that’s us running into the lack of sane window management on Linux. 🙁
Well we can move windows (i.e. override or as you wrote “hack” window manager) to proper places, but we need XPL to set different ID of these windows tiles. 😮 Again, you do not need to program everything, just give us possibility to do it. 🙂 I would say that combinations of monitor_bounds for letting XPL know that there are multiple windows and different windows IDs will solve this problem completely once for all.
If XPL windows tiles IDs will be predictable I can write small XPL shell wrapper using for example wmctrl to move spawned windows around any desktop configuration. And yes I will share it with community as OS, although it won’t be any rocket science. 🙂
Do you think it is possible? For example take it from order of windows_bounds parameter: first screen id0, second id1, etc. Thank you.
Kind regards
Litin
I don’t think we’ll get specific window IDs for 11.10 but we may be able to do it in the future – Michael brought it up but we’re late in the beta.
Hello Ben,
thank you. I understand, that you are now going to from beta to rc. But if there will be possibility to include different X-windows naming feature (and if this do not require huge change in code) it would be nice to introduce it together with monitor_bound as complete fix needed for Linux multiview support. So I will hope for the best. 🙂 Anyway please feel free to contact me anytime later for testing or proposed wrapper integration. Thank you for you time and great work! Kind regards
Litin
Hi, Thanks for all that, planes have certainly being far easier to steer as of last few Betas, what I am hanging out for is the next bunch of lego blocks so I can get updating airports, teh new terminal kit was a huge deal, as is the ground lettering polygons. I guess when will WED 1.7 be out…
very nice, but what is about virtual reality?
That’s next after 11.10 is done.
Dear Ben,
“Finally, there was an open question of how to use glScissors in a plugin with the new UI features (e.g. floating windows, multi-monitor, 150% UI, etc). As of beta 8 this is fully possible; I just need to get the sample code to Tyler to post.”
Any web link please ?
Cheers
Stef
It’s not on the web yet.
Hello,
is it normal that ATC is dumping megabytes of logs into log.txt ? Some debug left on perhaps in the latest 11.10b8 beta ? It literally grows MB per minute which might make sending log.txt to addon makers a bit tricky.
0:10:49.312 D/ATC: ——- 0 deleted tasks —–
0:10:49.312 D/ATC: ——————————————–
0:10:49.312 D/ATC: CONTROLLER Tower 11942 (5940)
0:10:49.312 D/ATC: ——————————————–
0:10:49.312 D/ATC: Role: atc_ControllerRole_Twr
0:10:49.312 D/ATC: Voice: Resources/default scenery/default atc/voices/default/default.voc
0:10:49.312 D/ATC: Aircraft: 0
0:10:49.312 D/ATC: Transmissions: 0
0:10:49.312 D/ATC: Radio: 11942
0:10:49.312 D/ATC: Airspace: 1 shapes
0:10:49.312 D/ATC: Facility: ()
0:10:49.312 D/ATC: Cab: LSTS
0:10:49.312 D/ATC: Transition altitude: 18000
0:10:49.312 D/ATC: ——- 2 tasks —–
0:10:49.312 D/ATC: 00000202486D0F70: CheckArrivalConflicts task for all aircraft
0:10:49.312 D/ATC: 00000202486D0630: CheckDepartureConflicts task for all
Hmmm…can you send me one of these logs? It is normal to dump that much stuff when an internal failure happens, so we can triage it later. It’s not normal for those failures to hit over and over and grow the hell out of the log.
Yeah, I will try to reproduce. In my last flight it’s ok and the log is now normal 200kb but I also noticed that few flights back the log ended up at nice 320MB after the flight 🙂 but it did not occurred to me to keep it as I though it’s just some debug dump left on by mistake in the latest build. I will try the same route as before and send the resulting log as a bug report if I manage to reproduce it.
Hi, I did a pack on lit_textures for the city .ter files, these textures had edited midmaps to make the texture ligths only visible when the observer is far form the texture. This workaround works nice on 11.05 but on 11.10 beta it is not working. I don´t file a bug because I now it is a unsuported function, but maybe something had change on texture compression. is this a bug or a new rendering behavior? is there a way to add a lit texture on the far texture ( FAR 4500 17000 0.4353 /FAR_textures/city2.png )?
https://forums.x-plane.org/index.php?/files/file/36942-night-city-textures-extended-lights-lod/
sounds like a shader bug — I’ll look into it.
I can confirm there’s a bug in the shaders. I’ll try to fix it for r1.
Nice! Thank you
Thank you very much for updating the beta on steam!
Please NEVER EVER release that new engine model.
What do you mean AMD users? I just built a 16 core Ryzen Threadripper machine. X-Plane is a monster on it. Working great. If you were referring to the video card I understand. This machine is ready for the Vulcan API next year! I may update the GTX1080 as well but all is working well! Thanks
I’m referring to the video card here.
when will we get new atc
Are we still looking at getting VR this year. Or has that gone pretty much kaput.
Yes.
Awesome. So looking forward to that. I don’t play xplane right because I am so spoiled in other sims that have VR
I agree Joseph you can’t go back to 2D after you’ve played in in VR.
I am also waiting for VR support so i can get back to playing X-Plane again.
Same here! Haven’t used X-Plane since spring – waiting for it to catch up with technology. Looking forward to something soon!
I haven’t bought X-plane yet because of the lack of native VR, but the moment VR goes to public Beta I’ll be screaming “take my money!”
Not sure if Austin has being implementing his mew ATC, but I had a 737 buzzing me at 3000 ft, seemed to be trying to wok out where i was going, quiet funny watching it cross my path in front of me, near stall speed than turn and cross the other way.
Love this product! Sim flying since sublogic. So now that you mention nose wheel steering, which looks very nice on the Cessnas, when are you going to tackle the LONG STANDING issue with crosswind taxiing? Just not realistic my friends. Aircraft just don’t wind vane that much. Some of us real pilots enjoy ground operations as much as flying, and a Cessna will not pivot into the wind uncontrollably at 10 knots ground speed, while the main gear slides (no friction?) with a 15 knot crosswind.
I can hold a Diamond DA-40 on the taxiway with aileron and rudder alone at almost any ground speed, but not in XP 11….
Hi Barry,
something not right with your setup (controls, wind speeds, surface conditions etc) – I can taxi the Cessna just fine in straight 20kts crosswinds and can take-off and land at max certified x-winds (17kts) as well.
Don´t hope for a fix, do yourself a favour and check your setup. Many people set up a high wind aloft, failing to see that it will propagate unabated down to ground level. Or have icy runways without noticing.
Cheers, Jan
Wilco. Thanks for the feedback Jan. Was looking for someone to say it was working for them to reinvigorate my troubleshooting this winter… and Christmas list!
So I’ve got a lovely set of Saitek pedals, and can position them quite nicely. This new plane-scoped ‘delay’ factor seems like it really should be a joystick device attribute.
XP seems to have really good knowledge of joysticks, this would make sense to have a default per joystick, even if you keep a plane based value.
I’m not sure I buy that. If you have an aircraft where the real aircraft has an operating limit on nose wheel speed, under what condition is it a good idea to _lower_ that limit due to the joystick? Like, if you have a hardware tiller you’ll never notice the limit, so there’s no need to change it.
I guess there should be both. What you have now is a genuine model of, i guess, motor powered steering on the big planes.
But on the c172 right now, the tail reacts instantly but the nosewheel takes 10 times longer to get to the requested angle. Which means you over compensate, and fight the fudge factor along with engine torque, prop wash, and wind.
Perhaps it’s just a bug ‘c172 should not have nosewheel damping’.
Yeah, it’s a bug. We need to do a once-over on our planes now that we’re past the FM changes.
I had created a bug report (XPD-8408) some time ago regarding the C172 tendency of pulling right. Any news about that?
Marked fixed by Austin in beta 7 – looks like Jennifer missed it in the release notes. Email Austin if you think the c172 flies weird.
Can you implendet the old xplane 10 settings…..where we can set more details….the new grafik settings is terrible
No.
how about just getting some more AA settings for use with VR? their are much better shader based AA now then FXAA
also wtb AF setting slider back 16x AF is a must in VR
Yes. Ben, have you ever looked into temporal AA for X-Plane. AA becomes a high priority in VR and I think any time put in this would be well invested.
I am aware of TAA techniques!
This again??? Here, knock yourself off: https://forums.x-plane.org/index.php?/files/file/36925-rendering-options-for-xp11/ but don’t come back later whining for support…
Hi Ben:
The symbology on the default—Plane ND/EHSI/moving map is very small and hardly readable. Any chance of increasing the size to more realistic proportions?
We actually have an open bug report for this issue. It requires implementing a generic map so it has not been fixed yet. You can track this with reference number XPD-7700.
Thanks, Jennifer
Ben –
Just chiming in here as a “lurker” and a flight simulator enthusiast (and a commercial pilot, AND a software developer).
Your blog posts are amazing and incredibly informative.
It’s so refreshing to see the “openness” on the software development process on what is clearly a VERY complex piece of software.
To the whole team, keep up the good work!
Oh and make the weather system more impressive but … priorities! 🙂