Josh

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. 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:

Don't hijack threads.

dx = pick.position.x - camera.position.x dy = pick.position.y - camera.position.y dz = pick.position.z - camera.position.z d = sqrt(dx*dx+dy*dy+dz*dz)

File Name: BMXFrontEnd File Submitter: Josh File Submitted: 30 Apr 2011 File Updated: 03 May 2011 File Category: Tools ABOUT A handy tool for building applications and modules. Enjoy! USAGE You must have mingw installed to compile modules. If you have BlitzMax installed somewhere other than C:/Program Files/BlitzMax, you need to set the BlitzMax path in the configuration file. 1. If the file "BMKFrontend.cfg" does not exist, create it. 2. Add this line to the file: BlitzMaxPath=(your path here) Compiling DLLs requires you to have some stuff installed: DEF files can be generated automatically by exporting any function in your source code with "win32" declared at the end. Make sure the first line of any exported function is GCEnter(). LICENSE Released under the GNU General Public License: http://www.gnu.org/licenses/gpl-3.0.txt ACKNOWLEDGEMENTS Thanks to Seb Hollington for his help with the treeview checkboxes. I ripped the MakeDEF code off the forum, somewhere. Click here to download this file

Now this is interesting. Why would this not detect the debugger connecting? An almost identical BlitzMax program works fine: if (enet_initialize()!=0) { Print("Failed to initialize enet."); } else { ENetAddress address; ENetEvent enetevent; address.host = ENET_HOST_ANY; address.port = 7776; InterpreterDebugHost = enet_host_create(&address,64,0,0); if (InterpreterDebugHost==NULL) { Print("Failed to create host on port "+String(address.port)); } else { Print("Checking for events loop..."); bool exitloop = false; int time = Millisecs(); while (true) { int result = enet_host_service(InterpreterDebugHost,&enetevent,0); if (result>0) { switch (enetevent.type) { case ENET_EVENT_TYPE_CONNECT: Print("Connect"); exitloop=true; break; case ENET_EVENT_TYPE_DISCONNECT: Print("Disconnect"); break; case ENET_EVENT_TYPE_RECEIVE: Print("Receive"); break; case ENET_EVENT_TYPE_NONE: Print("No event"); break; } } else { if (result<0) Print("enet_host_service failed."); } if (Millisecs()-time>10000) exitloop = true; if (exitloop) break; } Print("Done with events loop"); } } }

Ah, I needed these: ws2_32.lib winmm.lib

Yes Unknown. It will partly be determined by exactly how much I can get done for the initial release.

Why? It's so difficult to keep all those additional directories straight. Now I am getting all these linker errors:

Got it sorted, thanks.

I am using Enet to set up a Lua debugger. I compiled the Enet library from the MSVC project in the download. I placed the resulting enet.lib file in "Microsoft Visual Studio 9.0\VC\lib". In my project properties, in "Configuration Properties > Linker > Input > Additional Dependencies" I added "enet.lib". When I use any enet functions or classes the compiler doesn't recognize them. What else do I have to do to use it?

Yes, that's correct. You could always give the DLL the Leadwerks function pointer.

DrawText()?

If you are using calcvelocity any time, multiply the force you add by the body's mass. However...why not just make the mass of the first and last bodies 0, so they are static? Or if you want them attached to something, make a joint between the end and the body it's attached to. I'm not sure why you need to reposition the first body each frame.

Coronas work by performing an occlusion query to see whether they are visible or not. This allows them to shine through a masked texture, like a chain link fence, with per-pixel occlusion. No geometry tests are performed.

I don't know if it's possible to call debug.trace once an exception has been thrown, before lua_pcall returns, but it is possible to make my own RuntimeError() function which first performs a debug.trace if it is being called from a Lua state.

Ahhhhh, it makes sense now.

That would mean if you were behind a building or something, you would see the corona right through it.

Vegetation is very, very fast to render large amounts of. You would never be able to render the same amount of foliage with individual entities. The memory requirements alone would take gigabytes.

That's not what's supposed to happen. LuaBind is supposed to throw a LuaBind exception my catch statement would catch. I don't want to parse the error log and guess which messages might be exceptions.

I created a new C++ function: void RuntimeError(const std::string& error) { throw std::exception(error.c_str()); } Here is the Lua script that calls it: print("Creating an error...") RuntimeError("An error has occurred!") Here is the code that runs the script: bool Interpreter::Invoke(const int& in, const int& out) { try { if (lua_pcall(L,in,out,0)==0) { return true; } else { //If you throw an exception, it gets displayed here, which isn't what we want: HandleError(); } } //Exceptions should be getting caught here: catch(luabind::error& e) { Print("Caught the exception!"); exit(1); } return false; } Instead of catching an exception, the Lua error log just prints out "std-exception: 'An error has occurred!'"

That doesn't do anything. No matter what, if I throw an exception in a C++ function Lua calls, it just prints the exception in the Lua error log, and doesn't actually throw anything for my catch statement to catch. I added that thing rasterbar said to in the main function and it has no effect. #ifdef _MSC_VER _set_se_translator(straight_to_debugger); #endif

If that's just a limitation of the OS I can live with it.

I found if I call debug.traceback in the C++ function before the error is caused, I can show the call stack of the Lua program. However, Luabind is "eating" my exceptions so they never come back to the main program. The code on Rasterbar's site for MSVC has no effect.

I created a project that runs a Lua script and creates an error: In "le3.cpp" the GenerateError() function will try to call a function with a null pointer: void GenerateError() { Interpreter* i = NULL; i->GetStackSize(); } The GenerateError() function is exposed via LuaBind and is called by "test.lua". I want to be able to tell what line the script was executing when the program crashes, and to be able to get all the variables and call stack within Lua for debugging purposes. The Lua script is run in the Interpreter::ExecuteFile() function, which calls Interpreter::Invoke(): bool Interpreter::ExecuteFile(const std::string& path) { bool result = false; int errorhandler = 0; int size = GetStackSize(); if (luaL_loadfile(L,path.c_str())==0) { result = Invoke(0,0); } else { HandleError(); } SetStackSize(size); return result; } bool Interpreter::Invoke(const int& in, const int& out) { try { if (lua_pcall(L,in,out,0)==0) { return true; } else { HandleError(); } } //catch (luabind::error& e) catch(...) { HandleException(); } return false; } If anyone has experience doing this with C++ any advice is appreciated. I had try/catch working with Lua and BlitzMax, but this is a bit different. I'm going to use the debug info to construct a nice debug interface in the script editor, so you can click around and see everything that's going on in the script program.