Louie, Lua
Entry posted by Josh ·
4,120 views
Below is raw output from the Lua debugger. It displays all variables, tables, and functions in the Lua script call stack. This will be displayed in a nice treeview interface that looks much better, but I found this terribly exciting.
You'll notice that tables don't get expanded, even though I have the ability to display all the values in a table. The reason they don't get expanded is because tables can contain tables, including tables that might be found elsewhere in the program. This can easily cause an infinite loop of tables leading to tables leading to tables. This is why the Lua debugger must be a networked program that talks to the running process. When the user opens a treeview node to view the contents of that table, the main program will return all the values in the table so you can view them, but not before.
>Starting interpreter...>Script is running...
>An error has occurred!
>[Level 0]
>{
>source: @test.lua
>short_src: test.lua
>linedefined: 0
>lastlinedefined: 0
>what: main
>currentline: 22
>namewhat:
>nups: 0
>locals:
>a = 2
>b = 3
>mytable = {}
>[Level 1]
>{
>source: @test.lua
>short_src: test.lua
>linedefined: 15
>lastlinedefined: 20
>what: Lua
>currentline: 19
>name: dostuff
>namewhat: global
>nups: 0
>locals:
>test = dog
>[Level 2]
>{
>source: =[C]
>short_src: [C]
>linedefined: -1
>lastlinedefined: -1
>what: C
>currentline: -1
>name: RuntimeError
>namewhat: global
>nups: 2
>locals:
>}
>}
>}
>Globals:
>string = {}
>package = {}
>os = {}
>io = {}
>someglobaltable = {}
>someglobalvalue = hello!
>debug = {}
>math = {}
>table = {}
>coroutine = {}
>_G = {}
>_VERSION = Lua 5.1
Here's what the Lua script looks like:
print("Script is running...")
local a = 2
local b = 3
someglobalvalue = "hello!"
someglobaltable = {}
local mytable={}
mytable.color = "red"
mytable.mood = "happy"
mytable.subtable = {}
mytable.subtable.n = 9
function dostuff()
local test = "dog"
RuntimeError("An error has occurred!")
end
dostuff()
This will allow you to examine the entire contents of the virtual machine of any Leadwerks Engine 3 program built with debugging enabled, regardless of what language the main loop is coded in. The Lua implementation in Leadwerks Engine 2 was well-received, but we found in advanced programs we needed better tools to debug and analyze scripts. The script debugger in Leadwerks Engine 3 will make everything perfectly transparent so you can easily identity and fix problems. It also gave me a start on networking, because networking commands were needed to set this up.
My plan for the networking API is to have commands for sending raw data with a message id:
bool Send(const int& message, Bank* data=NULL, const int& channel=0, const int& flags=MESSAGE_SEQUENCED)
As well as a few game-oriented commands to easily set up basic behavior:
bool Say(const std::string& text) bool TeamSay(const std::string& text) bool Join(const int& team)
The real magic is the entity syncing, which handles networked physics and makes it so any command you call on the server affects the corresponding entities on all clients. If you call entity->SetColor(1,0,0) to make an object red, it will turn red on all clients. I've tested an earlier prototype of this, and it worked well, even across continents. This makes network programming fairly easy, and a lot of fun.
I'd really like to have a simple open-source tournament shooter game the whole community can play around with. Only by building a good networking base with a high-level entity syncing system does this become convenient and easy to modify.
http://www.youtube.com/watch?v=7Vae_AkLb4Q
---------------------------------------------------------------------------------------
And here's the debug output displayed in a tree view. The tables each get one blank child node, and when the user expands the table, the debugger will send a request for that table's data:
15 Comments
Recommended Comments