Canardia

It doesn't really matter how much time you spend, because the project is organized so that everyone can pick up task to do from a list of tasks I set up. So if you don't have time to do a task, the just don't pick it up, someone else will do it then

Read the hotfix: http://leadwerks.com/werkspace/index.php?/topic/483-leadwerks-community-gamelib/page__view__findpost__p__4331

Could the crouchmode be a float instead of int, so I could say how much it should crouch, and don't need to recreate the controller for different heights?

I think he wants to paint a surface with a material.

It seems the right time to re-open the LCP1 project, since many community members are seriously trying to get things done, and have done so already. Many people ask for help, and are learning fast new things. A community game project should not be an unpleasant task for anyone, but rather an opportunity to learn new things, and benefit from the work of other people, and be helpful to your fellow community members too. And if you're already working on your own game (who isn't?), you might get some useful knowledge to help you finish your own game faster too. I've learned a lot from the first opening of LCP1, and with that experience I think this project can now finally come true. The Leadwerks Engine has also improved a lot since then (the first LCP1 demo was done with Leadwerks Engine 1.13 back in the year 2007, imagine!), and I've developed game libraries from there on too. Anyway, I don't want to tell too long stories, but rather get the people who are interested in this to see some results. So I've remade the old LCP web page from scratch, and organized some people to make things they are good at and like to do. Here's the new web page which will be updated with more information in the coming days: http://www.siipi.com/lcp1

C++ and Lua at the same time. You can do things which you find easier to do in either language, and when you need more speed for some algorithm you do it in C++. You find lots of 3rd party libraries on the internet for both too.

PaintEntity( FindChild(model,"meshname"), LoadMaterial("abstract::matname.mat") );

Make sure you don't have any overlapping surfaces.

Make sure you see the textures in UU3D. If UU3D can't load the textures, it will remove them from the gmf completely.

I would keep the basic Lua commands which allow setting of the Framework variable in the headers, because not everyone needs Lua in their project. And of course rename them so they don't conflict with the C++ Lua headers.

I think Josh was waiting for this proof that it works before he can agree that the lua_xxx functions in LE should be renamed capitals per word, like all LE functions are anyways. I had the idea of removing the underscore too, and making them LE conform: SetLuaGlobal, PushLuaObject, etc... Great job Rick to get it to work!

Time for a bottle of champagne! Oh, but I don't have any Maybe you can model one?

Do you have the skin shader in your mat file?

Yeah, that would work if you're athletic enough for such manouver I would just turn on my side, and try to squeeze my head to the other side, and then the legs. Of course it also depends if the corridor is more broad than high. If the corridor is quite small in both dimensions, you'd use the diagonal space and squeeze your head, and one leg at a time to the other side.

Yes and no, actually just scaling the controller to a prone size would be more realistic, since people in prone position are able to turn around in a small corridor, which would not be the case if the controller was laying flat.

Josh, could we rename the lua_xxx commands in the C API to Lua_SetGlobal, etc... so that all names start with capital letters? Then people can use the original Lua headers with C++ and other languages with LE.

Yes, for Project Wizard you should update the download, but for gamelib I'll do more changes and release 0.0.19.0 in a few days, so it will be ready when Project Wizard is not beta anymore.

Yes, that is a better way, but also more complicated. The simple approach I suggested with parenting the arms to the camera, works in its context, since games which don't have a player model but only arms (like Far Cry 2), don't also have a 3rd person mode. If the game has a 3rd person mode, then this approach would fail, and it would be better to parent the arms to the player model, even if there is no player model. At least the arms would then stay in 3rd person mode, and not follow the 3rd person camera. If the game has a player model (like Crysis), then the arms would fail in any case (unless your player model has no arms), and you would need an even more difficult approach by turning the arm bones of the player model.

I have many gmf models which have no editable model format. Gmf models could be also sold for lower price than editable models, if some model seller wants to fine-tune his product range.

That didn't need very sharp eyes, and it popped up 2 big error dialogs when trying to run gamelib example from wizard And I found a bug in gamelib 0.0.18.0 also which makes it crash (you could hotfix it by copying line 542 (scene.game=this;) as new line before line 541), I'll make a quick fix today.

It makes sense in many situations to be able to create a physics hull for gmf models. When you're working on some project, you usually have only the gmf files in your game directory, and want to create phy file only at final stage, when the models are otherwise OK. Usually your editable model formats are in completely different places than your final gmf files, and it's hard to find the right editable model. When you work with different modelling programs or buy models from different places, you might also not have the same editable format available. Then you would need a phy file converter for any random editable file format. It makes also no sense to have to create obj files, if you don't need them for anything else than making phy files.

Bug: project.rc is missing #include "resource.h". You can download the correct .rc file from gamelib's resource.rc and use it as project.rc in ProjectWizard.

The upgrade could indeed be a bit cheaper than the price of the new version minus the price of the previous version. Thay way, more people would buy the engine now, and not wait for the new version, since they would get it cheaper. I don't think there will be a payed upgrade anytime soon, as it would need some essential new features. The 2.3 upgrade was already such an essential new feature set. Maybe when the engine supports OpenGL 3.2, realtime GI and colored shadowmaps, I would find it worth to pay for those features.

You can use normal engine commands to animate the hands. Look for example how it's done in fpscontroller.lua.

GameLib 0.0.18.0 is ready. New features: Player can throw picked up object (no extra coding needed, it's in game.PlayerShoot()) Game window has now custom icon, and can be modified for each game Game exe has custom icon too, one for detail view in Explorer and one for Desktop (it is automatically switched) LEO's Engine class is now part of the Game class (game.engine.SetFilters() for example) Game class has now custom Flip method, which allows the game to run using much lower CPU load (game.scene.Flip(sync,sleep)) The procedurally generated player_info place holder player model has now a head! So with the integrated LEO Engine class, the main program gets much cleaner: #include "gamelib.h" int main() { Game game(CREATENOW); // Initialize the engine (load the DLL) game.Initialize(640,480); // Create the graphics window while(!KeyHit()) { game.scene.Update(); game.scene.Render(); game.scene.Flip(0); // Don't wait for sync, don't give time to OS } return game.Free(); // Terminate the engine (unload the DLL) }