The last few weeks have felt like a bit of a Nine Inch Nails song (more or less) – in my weekly status report it’s “finish X-Plane 10.21, get WED 1.2 out.” Another week, another few bugs fixed. Are we there yet?
First WED: 1.2 release candidate 3 (!) is now posted. You can see a list of changes here. Two changes may be of interest:
- On Windows, the control key can now be used to apply changes to every selected item in the selection-property editor. In other words, select a bunch of nodes, control-select them all to a certain edge type, they all change at once. (This has always been possible with the option or alt key on Mac/Linux, but the alt key pops focus to the menu bar on Windows.)
- Keyboard commands are now delayed until after the mouse button is released. A user discovered a case where WED could be crashed by running two commands at the same time by drag selecting and picking control-G (for group) at the same time. WED now always defers keyboard-to-after-mouse. This is a risky change, but I want to make sure we kill off all of these bugs; WED’s undo system requires that no two edits happen at the same time to avoid corrupting the document.
Anyway, please report bugs on the scenery tools bug base.
Second: we’re looking at shipping a Lua memory allocator for Windows in a bug fix release to X-Plane 10.21, rather than waiting for X-Plane 10.30.
If you haven’t been following along at home on this, the short version is:
- SASL, Gizmo, FlyLua, and other plugins use LuaJIT.
- 64-bit LuaJIT has special needs when it comes to memory allocation.
- On Mac, X-Plane provides a special allocator to plugins to keep LuaJIT fed and happy.
Originally we planned to provide allocators on Linux and Windows in 10.30, but our new thinking is that we don’t want to wait that long; we have some things for 10.30 that may require a full-length beta (e.g. at least four weeks) so rather than wait for a summer patch, we’re investigating whether we can ship Lua allocation now.
Quick question here, is the 10.22 autogen fix still planned?
To fix the warehouses swarming small towns.
Warehouses were replaced with smaller buildings in 10.21.
I was under the impression that another batch of autogen artwork was due for inclusion in a 10.22 release. See here:
//developer.x-plane.com/2013/04/a-quick-fix-for-autogen/
Is this still planned for a later release?
I don’t know when the artwork will be released. If the art isn’t ready and we have a few must-release features, we’ll do just features.
Will there or is there a way to place autogen in larger scales? I have tried the “autogen” in lib/v10 but they only freeze and crash the sim..
And also, it would sure be nice to have a function to place elements by freehand, as you would with i.e a lasso tool (polygon placement) Now there is just a huge square with adjustable 4 points.. Does not give that much precision.
Right – WED cannot currently edit autogen-string and autogen-blocks.
What are you trying to do exactly where you want to place AG strings or blocks? Those art asset types were designed for _automatic_ placement based on road-grid data.
Just tried to supplement with some autogen around an custom airport that I am designing.
Tried all the different autogen found under lib/10
Sure would have been nice to have this option to accuratly(well better than now) place out houses in the same way you would with openscenery/forest
“for _automatic_ placement based on road-grid data.”
That explains why there are so many trees on each side of the roads 🙂
The warehouses swarming small towns have been replaced with rows and rows of small gas stations?
It would be nice if we could manually edit the autogen placement and share it with the community!
hm, i’m really confused now.
Do you say there is no LUA issue on Mac? What’s e.g. with the bug reports that I sent? Who and what is going to solve those CTDs? You said you’re working with Carenado, but unfortunately nowhere does one read about upcoming solutions. There’s also nothing specific mentioned with the 2.1 updates to their planes.
just wondering…
from the crash log:
Application Specific Information:
Assertion failed: (size == VM_PAGE_CHUNK), function CALL_MMAP, file /Volumes/RAID/code/design_clean/HLutils/Plugins/glue/lua_allocator.cpp, line 353.
Doesn’t look like my Lua is too happy on my Mac ;))
Here’s the deal on the Mac:
– There is definitely a bug where, when a Lua plugin runs the sim out of Lua memory entirely, it crashes, rather than letting the Lua plugin gracefully fail. This is not good, and will be fixed in the next patch – we already have the code fix for this. (But also, if your add-on hits this case, your add-on is doing something bad.)
– Exceeding the VM page chunk size is not something X-Plane supports. That’s what that assert from above means. Plugins need to “not do that”.
– I am working with Carenado, and I am not going to comment on this blog about my direct work with them or any other third party; it is important for the third party eco-system that third parties be able to take technical issues to LR and have their technical privacy respected. You can go discuss things with Carenado directly and they may or may not respond to you.
Cheers
Ben
ok I see. Thank you. But in any case, it would be nice to at least read somewhere about whst’s going on, at least at the ‘org, where Dan is a very active contributor. Because broken down to a statement regarding the issue, this means that an update to 10.21 or even 10.30 is not necessarily a solution for the issues on Mac.
Thanks for the continued work on WED! It really makes a difference.
“On Windows, the control key can now be used to apply changes to every selected item in the selection-property editor.”
!!!! !!!!! !!!!
Cue Handel’s “Halleluiah” chorus…
Cue Beethoven’s 9th Symphony choral…
Cue my happiness!
Well done! That was a big bug squish for us Windows users.
So was your plan to move up Windows bug fix in 10.21 or Windows and Linux?
The plan is to move up Windows and Linux Lua memory management to 10.25. 10.21 is done. We’ll ship the memory manager on Linux when we do Windows – the Linux one is simpler because it’s close to the already-existing Mac one.
Every week the same, until this week; as a Windows user/Carenado fan, I am thrilled with this news!
Hi,
You mentioned a autogen drop a month or two ago ?
hi,
when will the crowd sourcing for airport building be kicker off?
haven’t seen any anouncement by LR or info on robins page.
i have done some german airstrips, just waiting…
I’m not 100% sure. We want to finalize WED but that’s almost done.
Thanks for the update Ben, much appreciated.
Being a designer by trade and having just finished my first custom airport in WED I could not help but notice the lack of a feature (or perhaps a case of eyes-half-open on my part, lol!) which I think would streamline workload in WED tremendously but here goes:
In most of the applications I use there is the ability to pan across your artwork/design using the SPACE key, and working in these programs all the time I inevitably found myself trying to pan from one end of my airport to the other using the same key, only realizing that I had to use the arrow keys instead to achieve the desired effect. This impacted significantly on my turnaround time and I was wondering how easy/difficult it would be to implement this feature into WED? As far as I can tell the SPACE key has gone completely unused and it’s in the perfect position to act as a pan tool when depressed and holding down the left mouse button.
Another thing I found myself hunting for was a right-click context menu whilst in the thick of a design. Whilst perhaps not such a ‘must-have’ feature as the ability to quickly pan from one end of a design to the next I think it is worth looking into the implementation of such a feature over the long run so as to streamline features such as ‘rotate’ and ‘reverse’ and ‘export…’ etc etc. Just a suggestion from a designer’s point of view!
Regardless I think WED is a great free tool and well done so far. Hope I didn’t step on anyone’s toes with this comment! No harm intended Ben! Take care now and thanks. 🙂
For feature requests like space-pan (which is not a bad idea 🙂 please file a bug at //dev.x-plane.com/bugbase/ and set the project to WED and severity to “feature”.
No problem Ben, thanks for pointing me in the right direction! God bless.
I pan by zooming out and in, e.g. if you want to pan to the right: put your mouse left, zoom out, move mouse right, zoom in… it’s rather quick 🙂
(scroll wheel helps)
THANK YOU! The ctrl-key fix will surely make editing airports much less painful.
I have an unrelated question. Is there already a general date for the dsf recuts?
There’s no date. Alpilotx and I are working on fixes to DSF generation and data importing, so the work is in-progress now.
Excellent reading..
I do use RC2 as we speak, and do not experience any bugs or issues..
But there is a feature I do miss and that is to scale..
When all is selected there sure would be nice to have a scale function so that one can scale to fit the airport. I guess in order for this to be done, one first has to groupe all into one object?
Thanks so much for increasing the priority of the memory management issue. I have stopped simming as all my usual planes are affected.
Kindest regards,
Ropeless
Yep, I also stopped flying due to that bug. Hopefully it will be done soon, since the 64bit stuff is a big step forward. Thanks Ben!
thanks for fixing SASL/LUAJit x64 out of memory crash! ..That will make x-plane usable and i can start flying the B777 again (and the upcoming B757 too)
now, all what we are missing is an x64 version of the Xsquawkbox 😛
(it would be good to have at least a small update about xb’s current ‘status’ if you know any about it…)
thanks
I’ve tried a few times to fly from Kolkata to Chiang Mai and everytime it’s crashed with the log ending in out of memory error for SASL. Looks like I need to stop until this bug is fixed… or fly another plane. =\