Josh

It appears the BlitzMax multithread GC is badly slowing down the syntax highlighting. I also noticed the debug output update was slow when stepping, but thought it was due to the C++ program retrieving the Lua stack. I'm going to try building a single-threaded version of the script editor and see how different the speed is.

Be aware that the terrain doesn't get "swept" as it's editing, so if you move it too much, objects can fall through it.

It doesn't need a domain at all, I can just go to the ip address of the server.

I'm planning to make the editor launch an external process. The whole editing a live script session thing doesn't work out very well in rl. It'll still be seamless but I think the needs to be a division between the editor and the live game. Besides, this allows c++ programs and lua programs to be run with the same method, so there isn't a branch in the user experience depending on language. The level editor will have options to run and publish games, with a much better defined workflow.

Internally, it's a word value (2 bytes). The real height is the terrain scale y component times the internal value, divided by 2^16. The GPU has a setting to treat the word as a 16-bit float.

What do you mean? This is what it looks like right now:

Awesome, I can make it step a line of code, step in to the next function call, or step out to when the function returns.

It's not ready yet. You have to open a file and do things in a certain order, or it will crash. Just due to unfinished parts.

We've transferred the site data to a dedicated server hosted with wiredtree. I've filed a ticket with invision power services to configure the new server. When that is confirmed to be working I'll retransfer the database to make sure all posts are saved and change the domain nameservers and A record. I also have an update for the site skin that is supposed to fix most of the issues reported, but I want to make sure things are working right before installing it. Then we'll get back to works on docs and other stuff. Stay tuned.

I've got it stepping through code now. I had to run the debugger in a separate thread from the GUI script program, so it will continually update and keep the network connection alive. It was kind of difficult, but it seems to work well.

You're more likely to get an answer if you post the file in question.

Well, I think it will work. I love Lua because you can use it without installing any third party compilers and SDKs. It would nice to have the tools good enough that it feels like a lightweight version of VS.

It looks like this might do it: http://pgl.yoyo.org/luai/i/lua_sethook

I don't know if there is any way to do that. Can you make Lua call a function for every line of code it executes?

C# is not "officially" supported.

You can download a test with the lua debugger here: http://leadwerks.com/werkspace/topic/3193-le3-lua-debugger/

I thought some of the Lua enthusiasts might want to play with this. When you run "Debugger.exe" it will launch "LE3.exe", which will load and run the "test.lua" program. The program will stop on a call to DebugStop() or RuntimeError() and display the entire contents of the program in the debugger. The programs connect on port 1234, so make sure they aren't blocked from communicating. You can modify the lua code and run it again to see the results. It's pretty interesting to see what all the built-in tables for the different lua libraries look like. luadebugger.rar

Schools can obtain a discount for multiple licenses by emailing support at leadwerks dot com. There is no student discount available.

It's hard to judge the motion when we're looking at gray milk. I'll add a water shader to it and see what the result is. From an analytic standpoint it meets our needs because it has waves traveling in two opposite direction, and it's seamless and looping. Those were not simple qualities to obtain. If it needs improvement, I'll see what can be adjusted. If the technique doesn't work, I'll try something else.

Something like that. Right now it is like this: Message* Client::Update(const int& timeout=0) But a callback might be added, or you can add your own and run this command on a separate thread.

It should appear in a message, where the message ID is something like MESSAGE_CREATEENTITY and an extra parameter gives you the entity that was created.

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.