Rick

I think what we would find out is that the competition would be less about visual and more about gameplay, because that's what makes a game come to life. Like I enjoy the visual of this game because I like that style, but the gameplay is horrible and I'll never play it again. The gameplay aspect would be more of the competition in my view, but visual would also be a part of it. Also, I'm guessing the game demo won't be much and would still require a huge amount of work to make anything that isn't the game demo in the art of gameplay.

This is a game that could be fun but is horrible as it stands. - The camera controls was just bad. Not being able to rotate with the mouse just made moving around a pain. - Not even close to enough time to build anything. You need time to see your level before you know where to build anything and that means you need time. - Lack of feeling any sort of connection with the character. - I didn't know what 1/2 the stuff I was building was because I needed to just build so fast because there wasn't enough time.

Where would one check out suck movement files? Why wouldn't we all use this? Seems idea and easy to get a human walking movement file and use that for all humans walking, yet it seems most people try to animate them manually all the time.

So what are you using to get this working? When I imagine motion capture I also picture those EA people with black clothes and tennis balls all over their body

I think this needs to be turned into a contest. Make a tower defense game in 2 months.

Need a little help trying to figure this out. Basically it's GUI programming. This has to do with finding what control the mouse pointer is over. Controls can have children controls which will always be in the bounds of their parents. So if the mouse is over a control, we then have to go inside that controls list of children controls to see if the mouse is over any of those, etc, etc infinitely deep. Hence why I use recursion. In my example I have a form control which has 4 controls on it. Exit button, logon button, username textbox, & password textbox. In the code that I have what ends up happening is the form control gets returned to the calling function. I need the Exit button (since that's where the mouse is over in this example) to be returned. Inside this recursion the Exit button does get returned, but the chain continues and since the form is over the mouse it ultimately gets returned to the calling method. I need some way to retain the last control before a null children list is found so I can return that one up the chain to the calling method. Here is the code in C++, but the idea could be in any language. Control* GUIManager::FindControlOverMouse(map<string, Control*> controls) { map<string, Control*>::iterator iter; for(iter = controls.begin(); iter != controls.end(); iter++) { if((*iter).second->InBounds(MouseX(), MouseY())) { map<string, Control*> children; children = (*iter).second->GetControls(); // Go back into this method with this controls list of controls Control* ctl = FindControlOverMouse(children); return (*iter).second; } } return 0; }

pick.entity from what I remember returns the mesh not the model. Try GetParent(pick.entity), or it's the other way around. Anyway, it has to do with that. A better test would be to step through the code and see what value your model returns after you load it, and then see what value pick.entity returns and what value GetParent(pick.entity) returns.

I'd say if you aren't seeing any artifacts and are testing on a number of different graphics cards, then use DXT1, or you can take Josh's word for it and just use DXT5. If you are looking for some sort of proof I'm guessing you won't get it. Probably just best to go with what the creator of the engine says.

Where are you sending the message to the entity? Can we see that code?

C++ will give the best performance, but they are give good performance.

Wh1sp3r you only think this way because you've been using LE for some time now and get how it works. When new people come on they have a hard time with it. Documentation is important. There is enough of it out there but some is outdated.

I agree with Lumooja. To remove the dependency of some people who just want this basic functionality it would be better that they didn't have to bring lua into their project. Just rename the lua functions you created and problem solved.

Just curious but why won't the callbacks work for you in this case? If you need to do some conditions based on multiple things being collided with you can use some flags to get that working. Otherwise I can't see why you would have issues with using a callback. I believe Josh did this so he didn't have to store all that collision data each cycle.

I also got it working with a rename of the le lua files.

If I wanted to test thing out myself how would I do it? If I rename these methods in engine.cpp and engine.h to have the l in lua be L, and I try to compile it complains: 1>c:\program files\leadwerks engine sdk\cpp\engine.cpp(2714) : error C3861: 'lelua_gettop': identifier not found 1>c:\program files\leadwerks engine sdk\cpp\engine.cpp(2719) : error C3861: 'lelua_pushobject': identifier not found 1>c:\program files\leadwerks engine sdk\cpp\engine.cpp(2724) : error C3861: 'lelua_pop': identifier not found 1>c:\program files\leadwerks engine sdk\cpp\engine.cpp(2729) : error C3861: 'lelua_setglobal': identifier not found From what I can see these lelua_ methods should be coming from the dll? When I look at an example like leCreateGraphics(), the definition or declaration isn't found anywhere that I can see. [EDIT] Nevermind, I see.

Yes, this works. If I comment out the lua methods LE has in engine.cpp and engine.h and then use the lua library in my project I was able to expose my C++ method to lua and have it call. The C++ code static int KattSendMessage(lua_State* L) { char* _msg = (char*)lua_tostring(L, 1); char* _extra = (char*)lua_tostring(L, 2); string msg = _msg; string extra = _extra; LuaMessageManager::Instance().ProcessMessage(msg, extra); return 1; } BP L = GetLuaState(); lua_register((lua_State*)L, "KattSendMessage", KattSendMessage); In object of my lua models I placed inside the object:Update() method: KattSendMessage("rick", "test") I placed a breakpoint in the C++ function and it did indeed get called with "rick" & "test". I'd say this will work like a charm. Josh if you could rename the LE lua function it would make life easier as we wouldn't have to change them ourselves and always maintain a separate copy of the headers when new versions come out. [EDIT] The thing to be careful about with exposing your own classes/functions to lua is the editor won't recognize them and give a nil value, which kind of sucks. Probably have to wrap them in a nil value check.

Did they do it in 4 weeks worth of 8 hours a day times x people or a generic 4 weeks (which could mean anything from part time to working 16 hours a day).

Yes, it's possible. It's a big topic and has a learning curve though (like anything else I guess).

OK, will do when I get home. I already have a test example setup for exposing a C++ function to lua which works with just C++ and lua, but doesn't with LE and lua. Will post here with the results.

I'd be more than happy to test it, but I need the LE lua function names to be different than the lua library function names to test it. I'd really prefer to not wrap lua in a namespace because it's a pretty big library and that would be a huge pain. I agree 100%. Please rename those lua functions you have wrapped and I'll test it out. I currently see no reason this wouldn't work. Well, I guess the only reason might be you expose it as BP instead of the lua state type, but a conversion to the lua state type should work.

I still think it's best to just create 2 controllers of different size and swap them in and out.

I think collisions can give unpredictable results if you scale bodies though.

Are you wrapping lua functions because of the BMax users? If so, could you by chance make the wrapper methods a slightly different name? Something that let's us know they are LE wrapped methods? For us C++ programmers there really is no need to wrap the lua methods and if they didn't have the same names we could just import lua and use the lua functions ourselves. Please don't put this restriction on the C++ programmers. It's just an easy thing to rename the lua methods you are wrapping to something else. Since they have the same name the compiler gets screwed up. There is no need for us to initialize lua in our C++ program if we use the framewerks because you already do that. At that point the lua_State* is all that matters, and since you expose that we could (if the function names were different) use normal lua commands.

Yes it is, however it's not that straight forward. There are tools that can help though. If you google you'll get a ton of hits. Also note though, that it seems there is a problem with exposing anything from C++ to LUA if you are using LE and linking in pure lua. Josh has written his own lua functions that share the same name as the pure lua functions so if you link pure lua into your program they'll collide and won't compile. So you either have to complain to Josh and hope he changes it or you'd have to wrap lua in a namespace (since it's open source you can) but lua is a pretty big library and that can take time. Or maybe you can think of another way. I'm all ears on that.