Rick

I like that solution. This stuff always makes me think of Metal Gear. One of those games had a mini game where you had to navigate your way around some complex room with moving guards and cameras and not be seen. You tap on the wall and the guards says "huh?!?" and comes looking. If he finds nothing over a given amount of time he goes back to where he was and what he was doing. I so want to make a mini game like that! It was so much fun back in the day.

I would say yes. This is sort of what I was aiming at with my Thingoids although I was trying to be even more general and give basic building block scripts that the user joins together to make entities. But you could just hardcode all the entity game logic in the models themselves. It just becomes 100% specific to your current game. What Josh is aiming towards in LE 3 is all possible today it doesn't work as easily and look as pretty as the way LE 3 is going to work. My youtube id is rpiller and in there I have a video of thingoids where I did this in a very basic "game" in the editor. I talk about all the model scripts and how I joined them to make some gameplay. I'm at work so can't link to the direct video but I think it worked out pretty well myself

Well I guess something that could happen is a player runs through some door that closes behind him and now the AI have to get to the player another way. That would be sort of like what you showed in your video except you just went through the wall instead. Basically it adds an element of the AI chasing the player, running into an obstacle and just picking a direction to get to the last known point of the player and sticking with that direction unless they see the player again to make them change.

Tower Defense! One of the most basic and probably first things indie people make One thing about what you were showing to make the AI "smarter". When you went behind the wall they all picked a direction around it, but when you moved closer to one side they all changed and found the shortest path, however they would never have "seen" you do that because you were behind a wall so would be more realistic if they only changed directions from "seeing" you and knowing to change directions. May setup some variable with the "followers" that indicates only changing direction when they "see" you and if they don't see you they either patrol randomly or go back to what they were doing? Just a thought.

I think this is a misconception on your part. This is most likely a rabbit hole. "If I could only program the gameplay". Then if you get that: "If I only didn't have to do pathfinding". Then if you get that: "If I only didn't have to program this inventory system", etc. The gameplay features you are wanting and seem to accept you have to code are much harder than having to code your own int main() function and come up with a game framework like you do now and like how you say is hard now. It won't get easier once you get into gameplay. I'm not a math guy either which is why I like LE. Unity requires some math to even move a character but not LE! In LE I can just use the UpdateController function of MoveEntity and pass a number. So I think you are in the right place given that "requirement" you have, but just have to get into programming a little more

Yeah see I'm not a fan of CEGUI anymore. To me it's an example of everything wrong with open source because of dependency hell like you say.

I'm going to say just use images based on what little I know about you (I assume you don't have much programming exp and getting into drawing buttons and such might be a pain for you). I would say buy some game programming book and read it cover to cover. Most will handle things like this. I can't think of one off the top of my head but I'm sure some others will help or just do an Amazon search and read the reviews.

Here would be one quick and dirty way showMenu = false function ShowMenu() -- draw your menu here end if KeyHit(KEY_ESCAPE) == 1 then showMenu = true; end SetBlend(1) ShowMenu() SetBlend(0) Flip(0) That's pretty basic. What I do with stuff like this is create states. A simple state could have an Update() and Draw() function. More complex can have transition methods, but in Lua I do something like: function MainMenuUpdate() -- example might be looking for the mouse click over a button and set currentState variable to a different state which will route it into that states functions that you create end function MainMenuDraw() end currentState = "main.menu" -- create the table and store functions for each state gameStates = {} gameStates["main.menu"].onUpdate = MainMenuUpdate gameStates["main.menu"].onDraw = MainMenuDraw -- main loop while(...) -- call the update on whatever state we are in. inside these states is where we can change the currentState variable gameStates[currentState].onUpdate() gameStates[cirrentState].onDraw() Flip() end Then you can get fancy with transitions because this idea above just instantly switches states, but transitions can make for cooler looking transitions between states.

I don't know. Have you played Minecraft I just bought it and if an artist was involved at all in that game I'd be surprised. I like the game and to me shows a pretty good example as to programming being a bigger force for a "good" game than art.

I honestly think the current Lua implementation could be made more like the unity structure by the community, but unless it's officially supported by Josh I fear people won't use it. Unity still has a lot of programming to it though. A better example I think for artists would be UDK with thier flowgraph. I'm a programmer at heart and I like the way Unity has set their engine up in terms of providing the framework. I like not seeing an int main() and using predefined virtual methods. It's a nice and flexible framework and in no way defines how you make your custom game, but instead provides you with the framework that all games can be made with. Unity is much more friendly in that sense than UDK I feel.

Did you get CEGUI calling Lua functions? I know you mentioned CEGUI has that built in, which I was thinking about today. I assume that means CEGUI has Lua compiled into it. Be sure it's LuaJIT and not normal Lua or else the method calls would probably fail as the lua state variable between the 2 are slightly different.

Parent physics bodies to the body part you want. Make a small circle one for the head and parent it to one of the bones in the head so it moves when that bone moves. This will give you a way to tell if there was a collision but won't give physics on the mesh if you are animating that part, but I assume you just want to know which part was "hit"?

I think the missing piece with LE2 scripting that the artists will like in Leadwerks3D is the flowgraph system that let's you connect the scripts visually. I don't think artists will be scripting themselves in Leadwerks3D just like they really aren't in LE 2, but I think it'll make a market for programmers to make smaller specific scripts that artists can use/buy. Sure programmers can make those today but they are generally not that complex (not so much gameplay related) and if they are they generally won't integrate well with another programmers scripts because some specific interfaces were created by that specific programmer and nobody wants to tie themselves down to a specific programmers interface between scripts. So with Josh coming out with a common interface on how scripts should talk to each other programmers can create scripts that the artist/level designer will feel comfortable using to make complex game interactions because they know they share this common interface. Sounds good on paper but I guess we'll see when Leadwerks3D comes out. We know that it's similar to things like Hammer (if you've ever done half-life mods) and that system allowed some fairly complex level design.

I actually included all the header and source files into my VS project. There was a thing where I had to copy and paste some dasm files in another folder to the rest of the header and source files to get that to compile. There also is an int main() in the Lua source that I had to find and commented out to make it compile. I didn't go the route of compiling LuaJIT into a lib and then using that lib in my project. It's small enough where I just compiled the source along with my project. And yeah this stuff can get very frustrated. You don't know how angry I was that my RakNet Lua DLL was working with the lua.exe program but not LE before Josh mentioned that it's not normal Lua that LE uses it's LuaJIT. LuaJIT is just close enough to actual Lua where some stuff was working, some stuff had small differences, and some stuff didn't work at all.

I compiled the source of LuaJIT into my project. LuaJIT I don't think has anything to do with normal lua so don't need the DLL. A linker error shouldn't have anything to do with a missing DLL though. If anything it would be missing lib, but if you compile LuaJIT source right into your project then there is no .lib file to reference. I would assume LuaJIT has that function but not sure as I'm not using that function and not at home. Can you search the LuaJIT source to see if that function is in there?

Note the last time I linked Lua with LE there were some naming conflicts because Josh used/exposed the same name of functions that Lua has. I remember this being a pain. If what you are trying to do is use CEGUI from Lua, you can create a DLL that has all the CEGUI stuff and expose functions to be called from Lua, and even call functions from your DLL back to Lua. This is what I'm doing with RakNet and it's working well (now that I know he's using LuaJIT and not straight Lua). This might be really nice with a GUI as you could register the name of a Lua function to act as an event callback. This is an example of the DLL I'm using. #define LUA_API_EXP __declspec(dllexport) #include "RakPeerInterface.h" #include "MessageIdentifiers.h" #include "BitStream.h" #include "RakNetTypes.h" // MessageID #include <string> #include <map> #include <iostream> #include <fstream> using namespace std; extern "C" { #include "lua.h" #include "lualib.h" #include "lauxlib.h" // prevents the function name from being mangled LUA_API_EXP int luaopen_raknet(lua_State *L); } RakNet::RakPeerInterface *peer = RakNet::RakPeerInterface::GetInstance(); RakNet::Packet *packet; RakNet::SystemAddress serverAddress; map<RakNet::MessageID, string> luaHandlers; static int NetBindMessageEvent(lua_State* L) { int msgID = luaL_checknumber(L, 1); const char* luaFunctionName = luaL_checkstring(L, 2); string functionName = luaFunctionName; // link the lua function name to this msg id luaHandlers[msgID] = functionName; return 0; } static const luaL_reg netLib[] = { {"Connect", NetConnect}, {"Update", NetUpdate}, {"BindMessageEvent", NetBindMessageEvent}, {"CreateBitStream", NetCreateBitStream}, {"Send", NetSend}, {"WriteBitStream", NetWriteBitStream}, {"ReadBitStream", NetReadBitStream}, {"Disconnect", NetDisconnect}, {NULL, NULL} }; // lua calls this to open the library LUA_API_EXP int luaopen_raknet (lua_State *L) { if(!log1) { myfile.open ("RakNetLuaLog.txt", ios::out | ios::app); log1 = true; } WriteLog("Inside luaopen_raknet"); luaL_openlib(L, "raknet", netLib, 0); return 1; } Then in Lua you do: ID_CONNECTION_REQUEST_ACCEPTED = 16 -- Load RakNet package package.loadlib("C:\\Leadwerks Engine SDK\\RakNetLua.dll", "luaopen_raknet")() function ConnectionSuccess() end raknet.BindMessageEvent(ID_CONNECTION_REQUEST_ACCEPTED, "ConnectionSuccess") I also expose an Update() function in the DLL and call that every frame from Lua. The Update method for me is looking for network packets and when it finds a packet that matches a message id I've registered calls the Lua function I associated with it. This should work with a GUI also. Can't remember what is all used with CEGUI to make it draw and collect input so not sure if this way would work or not.

I did, BUT note that Josh is using LuaJIT 1.1.6 and not just normal Lua. For my purpose of loading a DLL and calling Lua methods from the DLL I had to use LuaJIT or I ran into problems with playing nicely with LE's Lua implementation.

Well that was it! I thought I was going crazy. Thanks Josh for pointing this out. I forgot that you switched to that. Thanks Andy and everyone else who helped. All working nicely now. Asking over at RakNet if he minds me giving my custom DLL away as it still requires the RakNet dll to work and people would still have to go through him to get that. This might be useful for others and it's really simple to use. This is just for client stuff via Lua though, the server would still be pure RakNet (ie. in C++ or .NET or whatever supported RakNet language you want to use).

@Andy but that's using SDL and not LE right? So the Lua implementation might be different. Like I was saying it works all fine with Lua.exe only when using with LE. @Josh, hmm that might be it. I don't know anything about LuaJIT, but perhaps it does some things slightly different. So LuaJIT is a complete replacement from just normal Lua? I bet this it though because I remember not having these issues when you first introduced Lua and I seem to remember you switched over to LuaJIT some time after. I'll use LuaJIT in my DLL and see if that makes the difference. If so, we'll have to really specify it uses LuaJIT instead of just Lua because then clearly there would be some slight differences.

I will give this a try tonight With LE and Lua or with some other implementation of Lua outside of LE. If withing LE I'd love to see what code you have for that. What exact version of Lua (patch version also) and a working example if you have one because this all works when done from lua.exe but not when done from LE as the host of Lua.

Man I can't get a value returned to Lua from the DLL either to do this the other way I was thinking. I know this used to work as I'm looking at my example from the old forum. I was so close to getting this thing online, but now it's looking like I'm going to have to rewrite it in C++. static int NetUpdate(lua_State* L) { RakNet::MessageID msg = -1; RakNet::BitStream* reader = NULL; // check for new packets for (packet=peer->Receive(); packet; peer->DeallocatePacket(packet), packet=peer->Receive()) { // assign the message msg = packet->data[0]; // assign the bitstream reader = new RakNet::BitStream(packet->data,packet->length,false); reader->IgnoreBytes(sizeof(RakNet::MessageID)); // special case for connection. need to save off the servers address so we can send data to it later switch(packet->data[0]) { case ID_CONNECTION_REQUEST_ACCEPTED: WriteLog("Connection request accepted"); serverAddress = packet->systemAddress; break; } } // hardcode just to test lua_pushnumber(L, 5); return 1; } package.loadlib("C:\\Leadwerks Engine SDK\\RakNetLua.dll", "luaopen_raknet")() local msgID = raknet.Update() Notify(msgID) Just prints out nothing (nil)

Hey Andy, I'm actually not looping in the lua execute function that I listed. That's how Lua has that method define as is part of the Lua API. I didn't touch it, was just showing where the error was happening inside Lua. What I actually do in my DLL is that I have an Update method that is exposed to Lua. In the main game loop in Lua I call this Update method. The Update method is looking for packets over the network via RakNet and if it finds one it notes the message id, and finds the lua function name I've registered to that ID which is stored in the DLL. Then it attempts to call that. It's strange because this all works great from lua.exe (prebuilt lua interpreter you can download). It's only when I try it from LE's lua when I get the error. The other thing that's strange is that the first parameter of a C function called from Lua is not the real first parameter I've passed in from Lua when using LE, but it is when called from lua.exe which loads a lua file and runs it. In LE I have to start with index 2 instead of 1 when looking at the first parameter. That tells me something strange is going on with LE's implementation of Lua. I think the editor is built using BMax, and engine might be also, so maybe the BMax version of Lua isn't exactly the same as the C version? Not sure. Tonight I'm going to try and just return the message id, and the data inside that message from the Update method and I'll just do the function mapping on the Lua side. It's not ideal in my mind but it should work. The link that you posted, that's not LE though right? That's SDL? Are you using prebuilt lua library and DLL as the interpreter or is there a Delphi port of Lua?

That doesn't seem right. Controller newcont object should delete itself after that if statement because those brackets define the scope that object is in. Even if the break did something the object would only live until ProcessMap completed, meaning anything after ProcessMap newcont doesn't exist anymore. Do you have a destructor for your Controller class? Put a breakpoint in there and as you step through see when it gets called because to me that looks like that object wouldn't survive past either that if statement or the function. Which means inside the ctor you are storing off the address of the object to LE. After the object is destroyed LE still has that memory address stored. Then you convert that back to the class instance but that memory space could be anything by then. It surprises me that e->UpdateBall() doesn't fail on the call itself though. gamelib might be doing something slightly tricky as Lum is known to do funky things That seems odd too. What did you do exactly to actually make it a global instance? Without making it a pointer you can't have it global and pass that data in that function to the ctor because if it's not a pointer to ctor gets called right away, which wouldn't work if you made it global because that would mean you defined it right away but you couldn't have passed it anything to it's ctor because you can't until you are in the process function. In Scene header file try: Controller* newcont; Then in the if statement in process scene do newcont = new Controller(e); See if that works. That will make that object live until you deleted it, which you should in the scene object destructor. Then as long as the Scene object is alive (which I assume stays alive through your game. if it doesn't then you have another issue), your controller object will stay in memory too.

Looks like the same thing happens in Engine.exe. Guess I'll try creating my own exe that does this and see if that works. While I'm stepping through running this via Editor/Engine vs the lua.exe I'm able to see the variable that is messed up. I just don't know why it's messed up. It seems to be the lua_State variable is slightly different when ran from Editor/Engine vs lua.exe. It just makes no sense how you can call that method and it works, but when I call it, it doesn't. The lua_State variable must lose something when it gets xfered to my DLL, but why wouldn't it do the same from lua.exe. Frustrating as this is the last piece of getting RakNet working in Lua and me getting multiplayer in my game. I guess tonight I'll try returning network message and bitstream from the Update and handle the function mapping on the Lua side. Should give the same result.

Can we see that scene loading code you have? The way you create your Controller object sort of looks like it would go out of scope once the scene loading is finished which means the class would get deleted. Normally unless you have global variables you would want to use pointers so as to keep the objects you create "alive" for the long haul (past the method they were created in).