beo6

I have created exactly for this issue a script. See here: http://leadwerks.wikidot.com/wiki:align-to-ground That should help you align your animal to the ground. According to josh AlignToVector should work but i was not successful with that method.

That is definitely odd. I guess rigidBodyPhysics is the default so it makes sense that it is not required. However that it does not work with a polymesh is odd.

You forgot to set the PhysicsMode. I think you can also release the shape after setting it to save a bit memory. ballmodel=Model::Load("Models/ball.mdl"); ballmodel->SetPosition(0,3,0); ballmodel->SetPhysicsMode(Entity::RigidBodyPhysics); ballmodel->SetMass(1); ballmodel->SetCollisionType(1); shape=Shape::Load("Models/ball.phy"); ballmodel->SetShape(shape); shape->Release(); Hope that helps.

Hmm. I think that depends on what you are trying to do. But you could try to make the friction higher so it stops quicker.

Just wait until it is finished. It takes some time to copy the samples.

ahh. sorry that i misunderstood you. Not sure if it is possible but since the debugger can read values in scripts maybe it is possible to also set them. We will see

i thought only the automatic navmesh generation was taken out and we should call the navmesh generation method manually. However it takes minutes until it is finished. So i wonder how the dynamic navmesh generation was done in the first place and if that would also take minutes on a terrain.

I don't think that is exactly what is needed for an entity that should rotate according to the terrain slope and also rotate in the direction it is moving since both are different axis the entity need to align to. But maybe i am just too stupid for it. local world = World:GetCurrent() local pickinfo = PickInfo() local pivotPos = self.pivot:GetPosition() local rayStart = Vec3(pivotPos.x, pivotPos.y+1, pivotPos.z) local rayEnd = Vec3(rayStart.x, rayStart.y-50, rayStart.z) if (world:Pick(rayStart,rayEnd,pickinfo,0.1,true,Collision.Scene)) then local terrainNormal = pickinfo.normal local pivotRotation = self.pivot:GetRotation(true) self.entity:AlignToVector(terrainNormal, 1, 0.5, pivotRotation.y) end It seems no one else had an idea when i opened a forum post with that problem so i was stuck and searched for a different solution and found a more complicated one which worked for me.

Nope. AlignToVector didn't worked in that case because i need to take the model rotation into account and ignore the terrain vector rotation or else it works only on one side of a hill. I am no expert in that. I just copied from another engine and it worked where everything else i tried failed.

even if i agree that they might be too complicated, i struggled with them myself a bit. However sometimes they are necessary. Look at my script for rotating a model according to the terrain slopes. Entity:Turn will not help there. So they should be accessible. I don't like if things are unaccessible just because someone thinks they are too complicated. That just sounds like anyone else is just stupid. (really sorry for the harsh wording. don't want to be aggressive)

You can do that already. So i don't understand your question.

Not sure what that tutorial tells about. Quaternions. But i thought you already have your quat. You can create a Quat with: local quat = Quat() Too bad that Quaternions are undocumented.

Entity:SetRotation(quat)

not in my tests

Navmesh modification by code is important too for dynamic obstacles.

You are probably not setting context:SetBlendMode Before your draw calls. I noticed that debug mode changes it most likely because it draws the debug output on screen like FPS etc.

Hello Aggror and thank you for your reply. since i currently have no building functionality i tested with my existing units and they collided badly with the baked navmesh. recreating the navmesh when a building is build also takes a very long time. (several minutes) so even this case is highly unusable since it pauses the whole game. Changing the existing navmesh would be the best option i think. The units i have already move nicely over the terrain so i don't think i need so much fine tuning. I remember your mentioned thread about navigation without physics. However they talk about using the path data directly. If i would do that and move the entity with translate i would end up having the same issue and navigating around obstacles on my own. Also i would have to wait for the standard LE 3.1 version so i can access the navpath from code since it is not accessible from LUA. I think only flying units will not use the character controller and navmesh since they would not have issues flying over mountains or other obstacles. So. +100 for having the possibility to change only small parts of the navmesh. (as long as that does not pause the game for minutes of course)

// small push. Anyone already knows more? I can't believe that we need to regenerate the complete navmesh which takes a long long time, just when we dynamically add one obstacle in the level.

I am not sure but you might want to remove the Steamworks:Initialize() call in the App.lua file so the game does not want to connect to steam when you run it.

I thought Newton Dynamics 3 is used in LE 3.x ?

i wonder how why you would need that? isn't the main purpose of a UI toolkit to don't have to worry about every widget position?

I saw someone mentioning the possibility to compile the lua files. But i haven't tried it out yet. Also in Leadwerks 3.0 c++ version you where able to zip all your assets with a password and entered it in the code. It was not super secure some you could still find the password in the binary file if you knew where to look, but for newbs it was savely hidden. I guess a more secure way will come in the future.

Press Publish in the project manager?

I don't really understand what you mean. My units are always inside the Navmesh. When i keep the GoToPosition function always running both units move around each other. But: 1) i am not sure how the performance will go when there are many units with pathfinding always active. 2) it looks bad when a soldier moves near a tank where the tank is standing still and as soon as the soldier comes near the tank the tank also starts moving to make space for the soldier. 3) that would not work for buildings since these will not have a character controller and they should not move.

Hello everyone. Since i get further and further quite nicely with my small RTS Project i have another question which is depending on performance. I have units in a realtime strategy game. these can drive/walk around a terrain and buildings can be build by the player. The first calculation of the navmes of the terrain with no entity on it took a couple of minutes in the editor. First i tried to recalculate the navmesh when an entity reached its destination ingame. However that freezed the game for a very long time completely. using the method SetNavigationMode(true) does nothing for entities that didn't got baked into the navmesh in the first place. The character controllers just bump into each another. Is there anything i do wrong? Or is there a better way for pathfinding? Maybe i should overwrite the destination when the controller encounters an obstacle and try to move around it manually? Thanks for any idea, suggestion etc.