2.3 Sync

[Josh]

An update is available if you rerun the update tool. The version is still 2.3. The Lua design needs to be talked about.

 

You will notice the class scripts are an object-oriented single state system. It is possible for you to mess up the Lua state with a bad class script or a script you run in the integrated script editor. For example, if you do not free a class it will remain in memory and may interact in unexpected ways. If you follow the design of the template.lua script, you will be okay. Just contain per-class variables within the class object as I did in the examples. Whenever you load or create a new scene, the Lua state is recreated, so you start with a clean state.

 

The class scripts syntax is as follows: An "object" in lua is the analog to the model instance in the engine. I decided to call the variable "object" instead of "entity" to avoid confusion with engine entities. The object is just a Lua table associated with a model in the engine. The object "Kill" method is renamed to "Free" because the OO design allows redundant function names (thus, object:Free won't clash with class:Free).

 

A class is the table associated with an engine ModelReference object. This is a Lua table that is used to create all the objects. The class has a reference to the model reference, and has an instances table where all objects of the class are inserted into. So on the engine side you have a ModelReference with an instances list where all the models of that type are stored. On the Lua side you have the class table, which has an instances table (like a list) where all the objects of that class are stored.

 

A function renaming trick in class.lua (the replacement to base.lua) makes it so you can call the base class' original functions in extended class functions:

function object:Free()
--do some stuff
self.super:Free()
end

 

When you open or write a script in the integrated script editor, the Lua state is not recreated after the script runs. This allows you to modify internal values or set variables, but the editor will not clean up any damage you do. Conversely, when the "Switch to Game" mode is enabled, the editor reloads the scene from memory and creates a clean new Lua state when the you switch back to the editor.

 

Whenever the lua state is created (at startup or with a new scene) all scripts in the "Scripts/start" folder are run in no particular order. Remember, these script are using the same lua state as the class scripts, so you can access information defined in the startup scripts.

 

Finally, the single lua state allows class scripts to access each others' data. This allows for much deeper interactions between classes.

 

This design is final. I'm sorry for the misstep in development, but I think you will agree this design will give the best results.

 

 

Have fun and be safe. I am happily now going to focus on tutorials and examples for a few weeks.

[Niosop]

You rock Josh!

[Josh]

This community rocks.

[Rick]

Very nice. I'm excited to dive in. Thank you!

[Rick]

So what are all the "callback" methods we have?

 

Free()

SetKey()

GetKey()

Reset()??

Render()?? (I assume this took the place of Update()?)

 

Am I missing anything?

 

Also, what is the ... in the CreateClass() mean?

 

 

Also, is there a difference in variable scope for something like:

 

class.sound that is outside the class:CreateObject()

vs

object.sound that is inside the class:CreateObject()

[cassius]

I don't get it. What do I enter in script to replace

dofile("Scripts/base.lua") so I can get into an objects properties?

[Josh]

Copy the template.lua script:

require("scripts/class")

local class=CreateClass(...)

[Josh]

All the old class functions are supported. Update() and UpdatePhysics() work a little differently now. They will be called once per model, when the world that model is in is updated or has a physics step. This was found to be the best approach. So it's a per-instance function; You don't have to loop through all the instances of a class or anything like that.

 

There are also a few functions the engine will automatically call at certain points if they exist in the lua state:

UpdateWorldHook( world ) --when the world is updated

UpdatePhysicsHook( world ) --called for each physics step

FlipHook() --can be used for drawing

 

These are global functions not attached to a model. You can set up your own Lua hook system inside these functions, make them general functions for updating various things, or don't use them at all. You will notice the road_node script includes the "hooks" script, and calls AddHook() to add the road updating function. Now this is a hook system written entirely in lua. If you look in loop.lua, you can see this declares the UpdateWorldHook() function and uses the Lua hook system to call any Lua hooks the user added, including the road update function we added. Note that when the road class is freed (all instances of the model are freed) the lua hook is removed. It's actually not as complicated as it sounds, and it allows updating during the game loop on both a global and per-entity basis.

 

One additional object method was added, Render(). This will only be called right before a model is rendered. This is useful for things like flickering lights, where you have a constant update but you don't want to clog up the engine performing a bunch of updates on objects that aren't even onscreen.

[Rick]

I find it odd the template doesn't seem to have Update() or Render() in it.

[Josh]

Just add this code and uncomment as needed:

	--[[
function object:Update()

end
]]--

--[[
function object:UpdatePhysics()

end
]]--

--[[
function object:Render()

end
]]--

[Rick]

Question about the framewerk. I can't seem to use fw.main.camera in my object scripts. I also look at the game scripts like driver.lua and I see it's using fw.main.camera but I can't tell why it can use it but my object script can't from inside the object:Update() method. Shouldn't fw be global to the lua state?

[Josh]

Yes. The environment_atmosphere script uses it.

[VicToMeyeZR]

example 2 lua file.

 

fw=CreateFramewerk()

 

not sure fw is already set in framewerks.lua why you are setting fw to create a new framewerk class?

 

either way that is bugged.

[macklebee]

Just add this code and uncomment as needed:

	--[[
function object:Update()

end
]]--

--[[
function object:UpdatePhysics()

end
]]--

--[[
function object:Render()

end
]]--

 

where does this go? in the class.lua? just wondering because I get an error whenever I put a waterplane into the editor... fails at this line:

self:Update()

inside the function object:UpdateMatrix()... the error is 'attempt to call method Update (a nil value)'

[Josh]

What would commented-out code you add to template.lua have to do with the waterplane script?

[macklebee]

What would commented-out code you add to template.lua have to do with the waterplane script?

 

ok... thought it might have something to do with it since it was failing at self.Update()... and i assumed i would have to uncomment the Update

 

 

so whats the fix to the error then?

[macklebee]

ok... i noticed that the error occurred not when I placed the waterplane object in the scene, but if I tried to move it afterwards...

 

then i noticed that if i moved the position by the properties selection, no error occurred.

 

So replace this line in the function object:UpdateMatrix():

self:Update()

with this:

self:Refresh()

 

and it seems to have resolved the issue...

[Josh]

Ah, you are right. I uploaded your fix to the server.

 

You can probably guess what happened. I used to call the Refresh() function Update(), but then changed it because I didn't want it called each frame.

[Nilium]

Can anyone point out where StripAll is? 'Cause the class script is using it, but it certainly does not exist. Undecided about filing it as a bug.

[Josh]

FileSystem.lua

[macklebee]

Ah, you are right. I uploaded your fix to the server.

 

You can probably guess what happened. I used to call the Refresh() function Update(), but then changed it because I didn't want it called each frame.

 

hey i got something right! yay!

 

just doing some initial testing with the single state lua with bmax... and came across some other things...

with the firepit in a scene loaded from bmax, i now get a 'Unhandled exception:GL_INVALID_VALUE'

with the locker in a scene loaded from bmax, i see in the log:

Lua error: ...op/myleprojects/models/props/locker/props_locker.lua:24: attempt to index field 'joint' (a nil value)

Deleting mesh reference "c:/users/macklebee/desktop/myleprojects/models/props/locker/props_locker_door.gmf"

 

and its about 50/50 whether or not the door is there... and if it is there and my controller touches the door, it goes flying across the map... what do i need to do to get the 'joint' to be recognized?

[Josh]

I don't have any such errors with those objects, and Lua is much less prone to hardware differences than graphics are.

[Nilium]

FileSystem.lua

Seems the update didn't work all too well first time around. Oh well, working (in a sense, anyway) now.

[macklebee]

hmmm... weird. if i take out the skybox it seems to load the firepit without the error, but the fire and heathaze are missing and the fire sound only plays one loop. If I have a skybox then I get the error.

 

ok... must have been an issue with my update... I performed a clean install and the firepit loads with the skybox now. I still do not have heathaze or fire, but I assume I will have to edit the firepit.lua to perform a GetGlobalObject for the transparency world...

[macklebee]

yes... adding this to the 'function class:CreateObject(model)' inside firepit.lua allows me to see the heathaze and fire now in a bmax program.

--Create emitters
if world_transparency==nil then 
world_transparency=GetGlobalObject("world_transparency")
end
if world_main ==nil then
world_main=GetGlobalObject("world_main")
end

 

as before this still requires that the worlds be set as globals inside the bmax program.

SetGlobalObject("world_main", fw.Main.world)
SetGlobalObject("world_transparency", fw.transparency.world)