Josh

That seems quite low for 332 entities, but i can't tell anything else without examining the actual file in question,

I know you like the idea of programming with a visual designer, and it's a cool idea, but I don't think the outcome would be as good for my users. I think complex behaviors should be programmed and then combined and linked visually. I'm sure we'll learn more as time goes on and we see these systems in action.

It might be possible to make Lua automatically execute all outputs when a certain function is called. Otherwise, you'll just have something like this at the end of the Open() function: CallOutputs("Open") This can be extended in the future to take function arguments. The flowgraph isn't really about programming though, it's about connecting objects to make events occur.

Honestly, if you have to ask, you probably won't be able to write your own header file for a new language. You're much better off going with an officially supported language like Lua or C++.

That's fine to use, it's what the engine's copybuffer command uses internally: Function CopyBuffer(src:TBuffer,dst:TBuffer,flags=BUFFER_DEPTH|BUFFER_COLOR0|BUFFER_COLOR1|BUFFER_COLOR2|BUFFER_COLOR3) 'If src=BackBuffer() Return If src=dst Return Local buffer:TBuffer=GetBuffer() Local filter=GL_NEAREST Local temp:Int If src.width()<>dst.width() Or src.height()<>dst.height() filter=GL_LINEAR EndIf If (BUFFER_DEPTH & flags) If src.depthbuffer<>Null And (dst.depthbuffer<>Null Or dst=BackBuffer()) And (src.depthbuffer<>dst.depthbuffer) If dst=BackBuffer() Or glGetVendor()=VENDOR_ATI SetBuffer dst If Not Shader_DepthBlit Shader_DepthBlit=LoadShader("abstract::postfilter.vert","abstract::DepthBlit.frag") If Not Shader_DepthBlit AppLog "Failed to load shader.",APPLOG_ERROR Local shader:TShader=GetShader() ClearBuffer BUFFER_DEPTH SetShader Shader_DepthBlit glEnable GL_DEPTH_TEST glDepthMask True glColorMask False,False,False,False DrawImage src.depthbuffer,0,dst.height(),dst.width(),-dst.height() glDepthMask False glColorMask True,True,True,True glDisable GL_DEPTH_TEST SetShader shader SetBuffer Buffer BindTexture Null,0 Else glBindFramebufferEXT GL_READ_FRAMEBUFFER_EXT,src.framebuffer glBindFramebufferEXT GL_DRAW_FRAMEBUFFER_EXT,dst.framebuffer glBlitFramebufferEXT 0,0,src.width(),src.height(),0,0,dst.width(),dst.height(),GL_DEPTH_BUFFER_BIT,GL_NEAREST EndIf EndIf EndIf If (BUFFER_COLOR0 & flags) 'glReadBuffer GL_COLOR_ATTACHMENT0_EXT If dst=BackBuffer() If src.colorbuffer[0]<>Null SetBuffer(dst) Local shader:TShader=GetShader() SetShader Null temp=src.colorbuffer[0].reference.filter If filter=GL_LINEAR src.colorbuffer[0].reference.filter=TEXFILTER_SMOOTH Else src.colorbuffer[0].reference.filter=TEXFILTER_PIXEL DrawImage src.colorbuffer[0],0,dst.height(),dst.width(),-dst.height() SetShader shader src.colorbuffer[0].reference.filter=temp 'SetBuffer src 'glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT,0) 'glDrawBuffer(GL_BACK) 'SetBuffer Buffer EndIf Else If src=BackBuffer() And dst.colorbuffer[0]<>Null And (src.colorbuffer[0]<>dst.colorbuffer[0]) glBindFramebufferEXT GL_READ_FRAMEBUFFER_EXT,0 glBindFramebufferEXT GL_DRAW_FRAMEBUFFER_EXT,dst.framebuffer glReadBuffer GL_BACK glDrawBuffer GL_COLOR_ATTACHMENT0_EXT glBlitFramebufferEXT 0,0,src.width(),src.height(),0,0,dst.width(),dst.height(),GL_COLOR_BUFFER_BIT,filter ElseIf src.colorbuffer[0]<>Null And dst.colorbuffer[0]<>Null And (src.colorbuffer[0]<>dst.colorbuffer[0]) glBindFramebufferEXT GL_READ_FRAMEBUFFER_EXT,src.framebuffer glBindFramebufferEXT GL_DRAW_FRAMEBUFFER_EXT,dst.framebuffer glReadBuffer GL_COLOR_ATTACHMENT0_EXT glDrawBuffer GL_COLOR_ATTACHMENT0_EXT glBlitFramebufferEXT 0,0,src.width(),src.height(),0,0,dst.width(),dst.height(),GL_COLOR_BUFFER_BIT,filter EndIf EndIf EndIf If src<>BackBuffer() And dst<>BackBuffer() If (BUFFER_COLOR1 & flags) If dst=BackBuffer() Return If src.colorbuffer[1]<>Null And dst.colorbuffer[1]<>Null And (src.colorbuffer[1]<>dst.colorbuffer[1]) glBindFramebufferEXT GL_READ_FRAMEBUFFER_EXT,src.framebuffer glBindFramebufferEXT GL_DRAW_FRAMEBUFFER_EXT,dst.framebuffer glReadBuffer GL_COLOR_ATTACHMENT1_EXT glDrawBuffer GL_COLOR_ATTACHMENT1_EXT glBlitFramebufferEXT 0,0,src.width(),src.height(),0,0,dst.width(),dst.height(),GL_COLOR_BUFFER_BIT,filter EndIf EndIf If (BUFFER_COLOR2 & flags) If dst=BackBuffer() Return If src.colorbuffer[2]<>Null And dst.colorbuffer[2]<>Null And (src.colorbuffer[2]<>dst.colorbuffer[2]) glBindFramebufferEXT GL_READ_FRAMEBUFFER_EXT,src.framebuffer glBindFramebufferEXT GL_DRAW_FRAMEBUFFER_EXT,dst.framebuffer glReadBuffer GL_COLOR_ATTACHMENT2_EXT glDrawBuffer GL_COLOR_ATTACHMENT2_EXT glBlitFramebufferEXT 0,0,src.width(),src.height(),0,0,dst.width(),dst.height(),GL_COLOR_BUFFER_BIT,filter EndIf EndIf If (BUFFER_COLOR3 & flags) If dst=BackBuffer() Return If src.colorbuffer[3]<>Null And dst.colorbuffer[3]<>Null And (src.colorbuffer[3]<>dst.colorbuffer[3]) glBindFramebufferEXT GL_READ_FRAMEBUFFER_EXT,src.framebuffer glBindFramebufferEXT GL_DRAW_FRAMEBUFFER_EXT,dst.framebuffer glReadBuffer GL_COLOR_ATTACHMENT3_EXT glDrawBuffer GL_COLOR_ATTACHMENT3_EXT glBlitFramebufferEXT 0,0,src.width(),src.height(),0,0,dst.width(),dst.height(),GL_COLOR_BUFFER_BIT,filter EndIf EndIf EndIf SetBuffer(buffer) EndFunction

You could call Open() and Close() from other scripts, or from a C++ program (something like entity->CallActor("Open")) but I think we've found none of those approaches really make game interactions very easy. You generally don't know what functions other script objects have, and making generic "Activate" and "Enable" functions for each one doesn't seem to yield very good results, either. My primary concern for Leadwerks Engine 3 is that historically, with every 3D engine or game creation system, only about 10% of the users can successfully create game interactions with them. Then there are ones that make it easy to do a few pre-programmed interactions, but very few can make anything of their own and most end up with very few changes to the original. This is a huge problem. So keeping that in mind, the main way to access the script functions of an entity is through the flowgraph, which I will show as it develops. You script your behavior, attach it to an entity, and then you can control the way things interact visually. There's no guessing what the door's functions are, or checking the script, because it appears right in the flowgraph editor, so it's obvious. So you have a scripted button, and this scripted door, and they can be combined without even looking at the scripts. So right off the bat, a non-programmer can control interactions in a way that's beyond what most programmers currently do, including myself. It's not like it's hard to program that specific behavior, but without a general interactions system, it's just so much trouble that you generally don't bother to do it. The idea in LE2 was that the script function for SetEntityKey() could be used for this kind of functionality, but I think without a visual display of everything you have access to, it's not much fun. This also opens up Leadwerks Engine to a new category of users: designers. They can take place objects in a scene, attach scripts, and set up their interactions without looking at one line of code. This is actually pretty efficient because a script programmer can design different behaviors, and then give them to the designer to produce a level. I think this will also facilitate code sharing. Sure, I can program my own stuff, but it would be cool to just download a useful script and play with it, knowing I'm not going to have a bunch of incompatibilities or requirements. I plan on providing some generic "mover" scripts that handle movement interpolation. You just set a few values in the editor the script handles the rest.

In Leadwerks Engine 3, you can load a script and attach it to any entity. You can attach multiple scripts to any entity, and they will be called in the order they were attached. Right now, I am calling the script-side table "actor" because it is a little more descriptive than "object" but I'm not sure about all the syntax yet. Below is a sample script for a sliding door. When you attach this to a model, the script will control its behavior: ----------------------------- -- Sliding door script ----------------------------- --Attach this to any entity to turn it into a sliding door. --You can make the door move in any direction by adjusting the movement vector. --When the door opens or closes, a one-shot noise will play, along with looping --sound that will continue until the door comes to rest. --expose Sound opennoise --expose Sound closenoise --expose Sound movenoise --expose Sound stopnoise --expose Vec3 movement --expose function Open --expose function Close function actor:Start() if self.movement~=nil then self.openposition = self.entity.position + movement self.closeposition = self.entity.position end end function actor:Open() if self.openstate==0 then self.movestate=1 --Play one-shot noise, if it is set if self.opennoise~=nil then self.entity:EmitSound(self.opennoise) end --Play looping move noise if it is set if self.movenoise~=nil self.movesource = self.entity:EmitSound(self.movenoise,true) end end end function actor:Close() if self.openstate==1 then self.movestate=-1 --Play one-shot noise, if it is set if self.closenoise~=nil then self.entity:EmitSound(self.closenoise) end --Play looping move noise if it is set if self.movenoise~=nil self.movesource = self.entity:EmitSound(self.movenoise,true) end end end function actor:Update() local d local l if self.movestate~=0 --Calculate the difference between where we are and where we should be if self.openstate==1 d = self.openposition - self.entity.position else d = self.closeposition - self.entity.position end --Check to see if there is any difference l=d:Length() if l>0 then --Limit the difference if it is greater than the move speed of the door l = d:Length() if l>self.movespeed d = d:Normalize() * l end self.entity:Move(d,false) else self.movestate=0 --Disable looping noise source if it exists if self.movesource~=nil then self.movesource:Stop() --Play one-shot stop noise if it exists if self.stopnoise~=nil then self.entity:Emit(self.stopnoise) end end end Lua is pretty flexible, so I can make it work pretty much any way we want. When designing stuff like this, I find it's best to start with what the end user wants, and then work your way backwards to make it happen. What do you think?

If you move it just a little each frame, it may push the objects up as it moves. Or you could check objects within the edited are and maybe adjust their height.

Whoops, that was my fault. The syntax highlighter had some bad code that was updating every line each time a character was pressed. Looks like it will be my first BMX multithreaded app. Nice to make use of that. It was always too slow for any intensive applications.

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/