Rick

So maybe an indie mobile edition on steam would sell

I get the impression what he means is the grenade model itself is thrown out into the world from the hand from the animation. That means it goes the same place every time. Normally at the point of where the grenade leaves the hand you'd want the grenade to disappear so that you can place your own grenade model so you can throw it in code to any distance you need independent of the animation.

Yeah do what Crazy says. It basically is what I was saying but it creates the App table inside C++ vs the App.lua file. It's funny that the C++ source is still there for Lua projects but no VS project is created. Interesting.

How about something like this App.lua App = {} function App:Start() return true end function App:Loop() return true end In C++ bool App:Start() { Leadwerks::Interpreter::ExecuteFile("App.lua") // now you can push the App table and call it's Start() function and get it's return value and return that or Leadwerks::Interpreter::EvaluateString("App:Start()"); } bool App:Loop() { // again push App table and call Loop() and get return value and return that here or Leadwerks::Interpreter:EvaluateString("App:Loop()"); }

nick.ace you can do this now with a C++ project. You can still use Lua with a C++ project. Guppy is looking for an App.lua type of functionality with a C++ project though I'm not 100% sure why it's needed. Maybe so changing resolutions doesn't require a recompilation? You could probably just make global functions (not part of App like App.lua) and call those directly? App.lua function Start() return true end function Loop() return true end if Start() then while Loop() do end end Leadwerks::Interpreter::ExecuteFile() would probably let you load an App.lua that looks like the above to start the code. If you wanted the C++ Start() & Loop() then maybe Leadwerks::Interpreter::EvaluateString("Loop()"); (and Start()) after Executing the file first to load the functions into the global table would work.

I don't believe LuaJit and toLua are in any way related are they? I personally don't like messing around with the whole idea of "cleaned header files". I'm sure RakNet doesn't adhere to those rules and setting that up manually for all of RakNet would be a pain in the arse. I could do it for my own exposure but then again the need to mess around with that I don't feel is required when simple static C++ methods gets the job done. When I looked at that it seemed more trouble than it was worth, but that's just my take on it. If someone had the time to expose all of RakNet using something like toLua then that would be great, but it would also take a long time and be error prone most likely, but very welcomed I'm sure by many people.

When I did it some time ago I actually didn't use ToLua but just the old fashion way. I flattened the RakNet classes and made it more procedural. Had functions like: Connect(), Host(), CreateBitStream(), WriteBitStream(), ReadBitStream(), Send(), NetworkLoop(), BindEvent(). More like the top part of this: http://lua-users.org/wiki/BindingCodeToLua So I had global RakNet variables in my DLL for the peer interface and such.

"Also, one big model won't allow you to apply different material properties." You can have different materials on the same model. Generally you don't want to use 1 big model because there is almost always repeated geometry in a level and if you use 1 big model all that geometry will be loaded multiple times. When you build the level in LE you put multiple instances of the same model in your scene and the geometry gets shared which saves memory and loading times! An example would be if you have barrels in your scene. You wouldn't want those to be part of your level in your 3D modelling package. You'd want it to be it's own model and then add multiple barrels into the scene via LE. Generally you assemble your scenes like this.

You have to make the bindings. This basically means exposing the C++ RakNet to Lua. I've done this before but have since lost the code as back before it was free the creator said I couldn't distribute the DLL but had to give the source instead. It's very doable and not all that hard. I've been meaning to do it again but just haven't found the time. You don't have to expose all of RakNet, just create some high level functions that give you the functionality of sending/receiving data. I think I exposed like maybe 5 functions to Lua or something like that.

Are you sure the model isn't massive in scale?

It's at the bottom of the viewports. I like the flowgraph ideas though. It would be nice to zoom in/out and allow multiple flowgraphs. Flowgraphs should just be things you can add to your scene like any other entity. No need for only having 1 special flowgraph for the entire scene. We should be able to add any number of flowgraphs to a scene.

Session 8 is up where I go over the progress so far

Per the chart in the link below if I change the CollisionType to Debris on a character controller physics mode I wouldn't expect characters to collide with each other but they still seem to from my testing. I'm looking for a situation where character controllers don't cause physical collision and I thought the collision type did that no matter what the physics mode (or at least I feel it should). http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/collision-r778

Some csg painted with the invisible mat and made the parent to the brick model would give you better hit detection so it's not model perfect. I noticed you had to struggle a little to pick the brick model perfectly in order to bring up the hand. Same probably everything in your scene (noticed axe had same issue).

You can make some csg as children to the model and mark each one as shape hint. That would probably be better than using the model as the physics shape as it's more complex than it needs to be. If you want you can pain the csg with the invisible mat so you don't see it during design time. If you mark as shape hint during runtime those csg's get removed and just used as making the shape for the model. It would be much more basic so "faster" than using the model itself.

You declared your destructor (~Monster()) in your monster.h but you didn't define it in monster.cpp monster.cpp Monster::~Monster(){}

Looks a little better (although your int main() is massive but that's for another day probably). What is the error now because I suspect it's different after your change. Knowing the error helps us debug it.

vector<Monster>::iterator monsteriter; That is inside your Main.cpp but you use it inside your Monster function. Your Monster function doesn't know that variable exists. You have it as global (horrible idea). Declare variables in the same scope they get used. The same thing for your monsterarray. The question is why are trying to move all your monsters in your Monster class. Naming your class Monster implies that it's 1 monster not all of them. class Monster { public: void Move(){} } int main() { list<Monster> monsters; monsters.push_back(Monster()); list<Monster>::iterator iter; for(iter = monsters.begin(); iter != monsters.end(); ++iter) (*iter).Move() } Things to notice above. The Monster class represents 1 monster. I make the list of monsters and iterator inside int main() (this is even bad but it's a start if you are new to this stuff). There is no reason for them to be global like you have. I loop over the monsters inside int main and call each ones Move() function. I would challenge you to not make any global variables. It will force you to think about your design move and from the code above I think you will benefit from that. It will slow down your game making but will help you be a better programmer.

Sorry, can you print out the errors you are getting? I don't have LE 2.x anymore so I can't run this to find the errors and I'm too lazy to set this all up to find the errors myself. What errors are you getting?

Wall of code crits for +500! Are you getting an error? If so what is the error? At first glance it looks to be OK. You have a monster.h and monster.cpp which holds your monster class. That looks ok. Then you include monster.h into your main app and start using the monster class. Seems OK at a early glance.

You would have to do this yourself. However, note that loading a model during real-time if it hasn't be loaded on startup will most likely pause your game. Once a model is loaded once then loading it again will make an instance of it (unless you tell it otherwise) which will be instant. So generally you'll want to load 1 of all models in your scene on startup. Then you would manually have to do what you want with loading models in a range.

Thanks guys. Going pretty well so far.

You can use csg as the physics shape for a model. Have the model be the parent then line up csg around the model (you can have many csg objects if it takes that) and make them children to the model and select shape hint on them. When the game runs that csg will be made into a .phy for the model and won't be csg at all.

I think you need a shader that will discard certain pixels. Perhaps paint the transparent part pink and then in the shader you discard pink pixels and leave the others? You can look at this thread to see how you might do that: http://www.leadwerks.com/werkspace/topic/10704-model-transparency/

Session 7 up