Lumberyard Beta 1.11 Known Issues

Hi all, we wanted to share some known issues with Lumberyard Beta 1.11.

  • Installing a clean install of Lumberyard on a machine without Visual Studio will generate an error. Clicking OK will keep the installer running without further issue.
  • If you are using a machine with Window 8.1 and VS 2013, you will get an error dialog window the first time you run Beta 1.11. Closing this window will allow you to use the editor as intended and you should not see the error message on subsequent launches.
  • The Lumberyard GitHub Repo has not been updated. We are targeting early next week for the GetHub update.
    We are working to get a patch out for these issues in the coming week.

Hi @Binky_LMBR thanks for these notes. I have been working on installing for a couple days and was wondering - my first machine I attempted to install on did not have Visual Studio, and when I the installer failed, I clicked OK and it closed. I launched it again and started the install all over, but that failed also, and indicated I was running a second installer instance - I assume it was running in the background even though it appeared to close. I could never get it to work at all on this machine even though it is has redistributables installed but not Visual Studio.

I did get it to partially install on another machine (same EXACT machine build, though this one has VS installed), and this is where I currently am:

Also, not sure if this is a bug, but Setup Assistant says I’m missing some VS2015 components but I have the 2013 and 2015 redistributables installed and am running VS 2017 Community - are the redistributables for 2015 enough or do I have to install 2015 Community? (assuming that’s still available)


Hey @Worldbuilder - much apologies for the troubles. Let me get you some assistance on this topic from the team :smiley:

Hey @Worldbuilder, wanted to check in on this – did you select Microsoft Foundation Classes for C++ when you ran the installer for VS?

UX P3/4:

The console’s scroll bars (right side, bottom) occasionally load into the wrong part of the view window when resizing/moving the console window.

Workaround: issue resolves itself when the console receives new input

UX P2-ish:

Sometimes console stops automatically scrolling to latest - this is extremely annoying when working on lua scripts. There seems to be no way to configure/fix this once it stops working.

P1/2 - can’t remove items from the asset browser; if you have a broken asset, you have to remove it from the filesystem manually.

Noted - thanks for capturing these bugs @awgr! I’ve added these to our list for further action. Also, welcome to the Lumberyard Community! :smiley:

I recently noticed that Project Configurator will crash due to a parsing error in a gem.json file. It ends up displaying an “Error loading Gems” window telling me what file it was unable to parse and after clicking Ok Windows 7 gives me a “Lumberyard Project Configurator has stopped working” window with an option to Close the program or debug. The parsing error was a simple Copy/Paste error on my part where I left a comma after the last Gem dependency entry. While easily fixable on my part I wouldn’t expect Project Configurator to actually crash after this type of error.

I also found another bug in Project Configurator that led to a different crash after renaming some of my Gems and keeping the same Uuid’s. Since I was having compile errors that only said “[WARN] Unable to determine any required Gems ()” I tried to click the Advanced Settings button for the project I just successfully enabled my renamed Gems for . This all occurred after I fixed my above issue and after I went into the Enable Gems section, selected all my Gems which included the renamed ones which were labelled correctly and saved the changes. With a little digging I noticed in the gems.json file of my project that the “Path” for all those renamed Gems still pointed to the old Gem locations(that don’t exist now) even though the _comment for them was updated to the new Gem names. Manually changing the “Path” to the new Gem names fixed the problem but I wouldn’t expect Project Configurator to let me save an enabled Gem with an invalid Path without throwing some sort of error, especially after it still managed to update the “_comment” associated with it.