TheConceptBoy

Haha, I actually never thought that you'd use Fusion for Hard Surface Modeling. That's brilliant, No more dealing with broken faces and vertecies. Haha

Wait, that's all it takes? Does that set up Lua interpreter and create the C++ game all in just those few puny lines of code? This is amazing!

I'm guessing my ball join solution was no bueno right?

There's a video for leadwerks on moving objects using the Editor. We need THAT same thing but in C++

I got it. Making a tutorial about it now. XD

But that's the thing, I don't think the offset works. It always defaults to the center. even if I set the position of the new join to be at the position of the pick.position, it snaps the box by it's center.

What I mean is what do the, posx, posy, posz do. They seem to have no effect on the entity that it drags. static Joint* Kinematic(float posx, float posy, float posz, Entity* entity) if I pick a box by it's corner, I want to drag it by the corner. but the kinematic body seems to move the box to the position by it's center.

yeah, I'm trying to get the constraint to NOT be in the middle of the object but at the location where the PickInfoData.position reports the collision taken place

Say you've got 5 levels, each level has lots of interact-able objects like switches opening doors, turning on lights, explosions triggered by queues and timers. Enemie spawning on triggers, custom animations and what not. How would you organize the code for each level? Create a custom Actor Class for that one level and when the level starts, spawn that actor to run all that level code?

Good day, everyone. I'm a tad perplexed. I'm attaching a kinematic joing to a model but I don't want the joint to be attached to the smack center of the model because when I use SetTargetPosition(pick_sphere->GetPosition(true),1); Then the target simply gets moved by it's center. I can kind of get that, since the function says you're moving the target of the joint, it would use the targets center point. The question I have then is, What's the point of setting the position for the joint creation with: Joint::Kinematic(pos.x, pos.y, pos.z, entity) What is the purpose of it? There isn't a Join->SetPosition so you can't move the joint? The point here is to move the target to a position NOT by it's center, but by whatever point you're grabbing the objects by.

Indeed why Isn't it documented? There's a pool of super useful functions floating around in the aether of the leadwerks header files that are essentially lost to new users who rely on the docs. Isn't that the whole point of the documentation?

Really? I figured the whole deal with using the Actors is that you can just handle all the zombie related stuff IN the actual zombie when it's created... like Load the sounds, load the Model, load the animations, textures, materials and what not - everything related to the zombie. Instead it's like you're but a stone throw away from just doing it with your own class and not using Leadwerks Actor.. The hooks are useful though. I know that you should probably only load up the zombie 3D model once and instance it to all the actors. You really don't need to have 40 spawned zombies ALL load the model right? You can probably just Load the model once in the engine and then have the various zombies use that one loaded mode. Am I thinking this right? Say if I load the Model in the main.cpp, can the zombie actor class access the model variables located in the main file? I know I can set the zombie model when I create the zombies in the main.cpp file, but I'd love to be able to just leave ALL zombie related code in the zombie, including the model assignment.

Oh and from this point on, we are loading models and meshes inside the zombie actor class on Attach() right? When we detach, I believe I read somewhere that the engine handles removal of created instances automatically? Models. Sounds, Physics, Shapes?

A little while back, when I was experimenting with UE. I was advised against running IF statement checks on a loop when using blueprints. I'm not sure if that same advise would have applied to C++ but I thought I'd ask. UE promotes trigger based interaction. Instead of a light bulb checking IF a switch is on or off every cycle, the switch instead sends a trigger to the light bulb when the action of switching is performed. I mean there's gotta be an if statement in there somewhere in the switch then, am I wrong? Would this apply to Leadwerks C++ oriented programming too?

Ah, so far the array created with the Entity class method was the correct procedure. So that part lines with with the standard C++ game dev procedure. And I take it, then you can address each zombie in that array by using it's id in the entity array slots then?

Now that I've gotten a single instance of the zombie class spawned, which, now that I've gotten a hang of it, was pretty damn straight forward. Thank you for the help and patience btw 1) Creating a proverbial horder of zombie instances would require creating an array based on the actor entity class and storing all the zombies in that array?

Can we use an alternative to VS? Do we have to use VS? You seem to also be able to run the code from within the LW Level Editor. And the Built in code editor can also open cpp and h files

Ah, great. So there was literally no way an inexperienced C++ programmer would have ever been able to guess that one. Well at least I know now. Any ideas if it was VS that caused it? Or perhaps the internet browser is designed to add scramble to potentially harmful files? Notice how the cpp file transfered ok but the .h file had all sort of a mess added to it's suffix?

wait... is there already a class zombie in the leadwerks source files?

yeah, it did. What it he god damn hell did you do besides renaming the class to cZombie? xD

cZombie()? How does that fix the damn thing? I saw that c prefix in your own BasrActor file you posted but I figured that was just you personal naming convention. Is this some sort of a special modifier?

You'd think that if you right click on the Source folder in the Solution explorer and create a class, it would be created in that folder... but noooo

Now these files have to be in the /Source folder, right? VS Seems to always create them in the Windows project folder where the solution is sitting. i have to move them to source manually.

Haha. Ouch. Ok. Going to check that again.

zombie.hzombie.cpp I've tried playing around with setting the functions as public, as per yours and some other posts with suggestions.