Rick

std:string Stream::ReadAll() would be convenient.

I understand they are trying to advertise that you don't have to make bindings but all the examples don't use custom user functions. Instead they are using functions that would come with the compiler. That's cool and all, but the ability to use 3rd party C code isn't really shown.

@cassius, there really is no "best". This is a design choice that you have to make. Generally the data you need to different kind of actors will rule this. If it's an RPG type game then it's most likely that all characters will have the same stats/data so you can get away with 1 actor class. Actors will have a list of Abilities where the Ability class will actually do the functionality of the ability and not the actor. With this you will have to assemble actors either via config file or hardcoded.

np. You really should just do some tutorials and examples of classes without bringing LE into the picture to get a better understanding of how they work. Then once you do that, the placement and scope and all that will make more sense.

Yeah the second example is way better. Almost every example I've seen that really pops out uses white heavily. The second example with no AO doesn't even look like it has shadows at all as I would think the pillars there would be casting more on the white.

Do you have 'using namespace Leadwerks;' anywhere? If not then you'll need to prefix all LE class types with Leadwerks:: like Leadwerks::Source.

Did you do #include "Leadwerks.h"?

Those pictures look the same to me. What should I be looking for in them?

As far as I'm aware there is no enter/leave functionality built into LE. I've been asking for it on and off for some time now as I agree it's important. You can make this functionality yourself but it's sort of a pain. In C++ LE uses a non class method (normal C method) for calling collisions (which I don't agree with). Look into: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitycollisionhook-r64 You have to store lists of entities that have collided already and that collided each frame clearing it out at the start of each frame and only raise some kind of enter/leave yourself. It's a pain and I agree LE should have this functionality already.

@YouGroove The problem with that approach is that it assumes you can take anything and make it great. Some project ideas just aren't good. Making prototypes of many projects can help you find the ones that most interest you and are more fun to play which means it'll have a better chance of success.

Yeah it used to work for me, but that was on another PC that I don't have now. On this laptop it hasn't worked at all, but that might be because I got the laptop around the same time of a certain release or something.

I think you can export to obj or something? Then use something like UU3D to import that and convert to GMF. Then you have to have mat files with the same name as the textures you used because those names are inside the model as the textures to use, but LE requires material files and not just textures. I think that was the process I used. Make sure your textures are DDS with mipmaping I think it's called.

I got this all working, will make blog post/tutorial on it.

I got this working. A lot of screwing around but I got it. I'll make a blog or tutorial on all that stuff I needed to do to get all this working.

I can't really assign it to a global var. I'm setting up a callback system where I'm telling the C++ class the table function to be the callback. This will be done from within a lua class function. function ProfileMenu:Enter() self.Network:RegisterCallback(msgID, self, "Callback") end function ProfileMenu:Callback(reader) end I'm looking at code like the following but you don't expose some of these lua functions so I might have to bring in lua myself. What version of lua is being used in case I have to do this? http://lua-users.org/files/wiki_insecure/users/ArielManzur/tolua++/tolua_base.h As you can see lua_Object is a parameter type which is a table. You store some kind of reference from it and retrieve it later to call.

Any ideas on how I can pass & store a lua table to a C++ method and then bring it up and call a function in that table (by name, which I'll also store) it at a later time using LE's lua implementation? The name of the table is not know as I'll be passing 'self' to the C++ method. I just don't know what the C++ parameter should be and how to find it and make the call. Words can't explain how much I hate working with the stack in lua

Anyone else having this issue? Can someone check to make sure after fully updating to the latest version their lua breakpoints are still getting hit?

Josh, are you passing lua table functions back to c++ to be callbacks at all? If so, how are you doing it? So I'm looking at how you do App stuff. Looks like you create a table from C++ and call it App. Then you load the App.lua file which defines the Start() & Loop() functions. Then you get the App table, get the Start function, push the app table as self, and call the Start function. The main difference in my situation is that the table isn't created in C++, but created in lua. I would have to pass the table to my C++ function. I don't think I could really give it a name with SetGlobal. It must have a name already when it's created from lua that I can use?

This sucks that no one else is experiencing this issue because it happens 100% of the time for me.

I did include Leadwerks.h because I needed to change some of the base lua commands to the Leadwerks ones, like lua_gettop to Leadwerks:GetStackSize(). Also because I added the dofile/require at the end of the file (not even sure I needed to) I needed to use the Leadwerks version of these. Now I have to see if I can expose this in a dll. The nice thing is embedding RakNet into the main exe I think is required for mobile games because from what I've read you can't really have dll/external libraries on mobile devices. However, if you do what you talked about on Steam then I would need a dll to hold the RakNet commands and load the dll via lua. I hope that works because then this will be able to run in all environments. I just did an #include "Leadwerks.h" at the top, I didn't actually include all the contents of Leadwerks.h in the pkg so it wouldn't have regenerated any Leadwerks stuff.

Sorry for the stream of thought, but I think I got it working. I took out the declaration to tolua_luacommands_open1() from the cpp file and made a header file that looks like: #pragma once #include "Leadwerks.h" #include "tolua++.h" /* Exported function */ TOLUA_API int tolua_luacommands_open1(lua_State* tolua_S); I then include this header file in the tolua generated cpp file AND app.cpp so that I can call tolua_luacommands_open1() in App:Start() in App.cpp. I don't get errors now when trying to call my classes from Lua and it's hitting breakpoints in my VS project for my class when I make the call from Lua! Success!!!! I would say this is far from how easy you made it sound on this page http://www.leadwerks.com/werkspace/files/file/216-tolua/ If everything works, I'll post a tutorial on all the steps I did.

OK, I was able to get it to run by renaming a couple functions in the file. I renamed tolua_luacommands_open to tolua_luacommands_open1 and luaopen_luacommands to luaopen_luacommands1. Here is what I'm thinking. You used this same method of getting your Leadwerks objects and so those 2 functions are the exact same name for the tolua code you generated. Then when I add it into the project we now have 2 sets of the same function names! I'm shocked it even compiled like that but it does, but clearly that's screwing stuff up. I don't know how I can call my new tolua_luacommands_open1() function inside App.cpp thought? Since it's a cpp file I can't include any header file that tells App.cpp that function exists so it can't find it.

Attached is the pkg file that has the 2 headers for my classes. After it's created I just manually add the includes, but then I also had to make the calls to lua's dofile/require be Leadwerks::dofile/require. I also have to change the lua get_top which I assume is equal to Leadwerks::Interpreter::GetStackSize(). After I make those changes the project compiles, but then I get the error function being called when it tries to Invoke the App:Start() function. Side Note: I find that if I exclude the tolua generated cpp file everything works. So the existence of that file in the project is causing issues even though I get the error BEFORE I even call anything generated in that file. The simple fact that it's in the project causes the problem. luacommands.rar

I'll post it in about 5 hours when I get home.

OK, so the good news is it's making it inside this function because the error I get is: "Lua Error: error in error handling" which is clearly coming from this error handler because it starts with "Lua Error: ". However the message "error in error handling" isn't all that descriptive . If it seems like it's getting inside this function why would: Interpreter::Invoke(1,1,errorfunctionindex) be returning false making the application quit when being done in: if (!Interpreter::Invoke(1,1,errorfunctionindex)) return false; It would seem to me it was able to invoke the error handler function since I get the error msgbox from it, so why would it return false? What's going on inside Interpreter::Invoke() that's making it return false?