Behavior Context changes in Lumberyard 1.8 - Steps for a smooth upgrade

With the upcoming Lumberyard Beta 1.8, we’re continuing to respond to customer feedback by making some important changes to the Behavior Context. Significant improvements to the Lumberyard Editor include replacing the existing script context with a new, easier to use reflection context. This change paves the way for exciting future development around TrackView and our new visual and Lua scripting interfaces. Outlined below are some important steps to help you prepare for this migration. As always, we are here to assist you with any questions.

Below is a detailed preview of the steps required for Lumberyard 1.8 migration.
Step 1. Update your engine build

The initial step involves updating the Lumberyard engine as you normally would. Please follow the documented instructions before proceeding.

Step 2. Convert your C++ code from Script Context to BehaviorContext

If you have created any event buses that expose functionality to Lua using the script context, you will need to convert those. There are two parts to this:

  1. Any EBUS senders you created need to be converted to BehaviorContext handlers.
  2. Expose the EBUS handlers to Lua using the BehaviorContext in your component’s Reflect method and remove the old AZ_SCRIPTABLE_EBUS macro calls.
    Instructions for migrating your event buses will be released with Beta 1.8

Step 3. Convert your LUA script syntax

There are several improvements to Lua syntax that provide better flexibility and more similarity to C++ syntax.

  1. Instead of senders in Lua you send an event as you would in C++ using Event or Broadcast, depending on which delivery mechanism you want.

-- The old way,using the script context syntax:
self.uiCanvasLuaBusSender = UiCanvasLuaBusSender(self.canvasEntityId)
local entityWithFader = self.uiCanvasLuaBusSender:FindElementById(2)
-- The new and improved Behavior Context syntax:
local entityWithFader = UiCanvasLuaBus.Event.FindElementById(self.canvasEntityId,2)

2.The syntax for handlers now uses a Connect method similar to C++.–The old way, using the script context syntax:

self.uiCanvasNotificationHandler = UiCanvasNotificationLuaBusHandler(self, canvasEntityId)
-- The new and improved Behavior Context syntax:
self.uiCanvasNotificationHandler = UiCanvasNotificationLuaBus.Connect(self, canvasEntityId)

-- Also new: if you do not want to connect immediately: self.uiCanvasNotificationHandler = UiCanvasNotificationLuaBus.CreateHandler(self)
-- then later:
self.uiCanvasNotificationHandler:Connect(canvasEntityId)
  1. You now create a local instance of your script component and return it at the end of the file.
-- MyScriptFile.lua, old school script context way:
myscriptfile = {} -- This table used to have to be named exactly the same thing as the file name
-- MyScriptFile.lua,new and Improved Way:
local ScriptName = {} -- Name this table whatever you find appropriate
...Your Lua Script Code...
return ScriptName -- The table you return here is the one used by the engine
  1. Entity references are treated the same as any other property and no longer use a special syntax
-- Old School Script Context Way:
myscriptfile = {
Properties = {
Property = { entity = '' },
}
}
--New and Improved Way:
local ScriptName = {
Properties = {
Property = { default = EntityId() },
AltProp = EntityId(), -- Also works
}
}
return ScriptName

Detailed instructions for migrating Lua scripts will be released with Beta 1.8

We hope this helps you prepare for upgrading your projects to Lumberyard Beta 1.8 as smoothly as possible. Please post an questions, concerns, or comments in this thread and we’ll prioritize providing answers.

Very like the new syntax especially that I don’t need to write handler and sender every time, but now expect that ide suggest me the Event and Connect words so tham are not just two other different words to type manually.

I haven’t figured out what replaces the AZ_SCRIPTABLE_EBUS macro reflection like sintax?

Would track view be able to animate any script exposed variable or something similar?

Does 1.8 comes with more of the engine exposed to script?

material and post processing access and custom animation events with their location in space are especially missing from lua or at least not obviously accessible from script component.

As always thanks for the awesome work.

No worries, not giving out a date is exactly the way to go. I’ll probably shorten it and put it out there.

Glad you guys don’t give up on lua. It’s such a neat scripting language. Keep it up!

Hah. I just had a tutorial about lua in the making. With the new changes this tutorial is useless (should’ve taken the hint when the docs on AZ_SCRIPTABLE_EBUS went offline). Anyway I know you can’t name a precise date, but would it still be worth to release my tutorial?

Also: Nice!

If you have it done or almost done, I’d say release it. I think it would be beneficial for the time being and be good practice at making tutorials. I’d love to see it. I wish I could give a 1.8 date but it’s not 100% at this moment and we try not to give moving dates. I’ll let you know as soon as I can.

Never tired of hearing about pain points for you all. I whispered through a megaphone. :wink:

Thank you very much for he heads up @Binky_LY. Very much appreciated.

I know you don’t want to hear about this anymore but can you whisper in the right ears up there about C++ API doc ?

Thanks for the hardwork :wink:

Cheers;

@TAN You’ll see something very, very soon. :wink:

I mean VERY soon…

As soon as February 27?!? :stuck_out_tongue:

Soo… it has been very calm around here. Any news on 1.8 ? :wink:

I can sleep happily now. Thanks :slight_smile:

Maybe even sooner…

FYI: https://forums.awsgametech.com/t/lumberyard-beta-1-8-release-notes-february-2017/2307/1