Josh

You only need to call sync once, and thereafter it is automatic: Entity::Sync(Server* server); Then you can do whatever you want, even delete the entity, and it will be automatically updated in regular intervals.

The yellow one is the recursive bounding box of the top-most entity.

Position, material, color, keys, etc. One way to sync info would be using entity keys. As far as syncing entire classes, the best bet is to send a raw data packet.

To make an entity appear on all clients, you would call this: entity->Sync(server) That entity will be sent to all clients, and whatever happens on the server is reflected on all clients. Entities within maps get a little tricky. You'll have stuff like a door you put in the scene you will want the server to control. I am thinking we'll have a checkbox that makes an entity in a map networked when checked. Partial syncing of a single entity isn't possible; the server controls synced entities, and a given entity is either synced or it isn't.

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!'"