Josh

Please read this news item: http://www.leadwerks.com/werkspace/blog/41/entry-619-data-loss-announcement The ordering system is a recent addition to the site, and the majority of developers do not have a purchase record in the client area. However, your license is still valid and you have access to the entire site. You can download the installer here: http://www.leadwerks.com/werkspace/files/file/186-leadwerks-engine-updater/ And if you need your registration key re-sent just email support at leadwerks.com. We have separate records of all accounts, and your purchase is in our records.

ha...there's enough problems with people understanding the spelling as it is.

That would go in community tutorials.

It sounds like you want it travelling at the same velocity, perpindicular to the normal of the ground. Take the vertical velocity and use that to create a vector with the horizontal movement to calculate how much the horizontal movement should be reduced by, You should definitely multiply the movement by something like 0.1 when the controller is airborne.

The reason the engine doesn't store a list of collisions is because it can result in hundreds of dynamic allocations of memory each physics update, most of which will be unneeded.

It's behaving correctly. -You are applying horizontal force to the player, even when they are airborne. You should greatly reduce their movement when airborne. -Your movement is quite strong compared to gravity. Turn the movement down or increase the gravity, or both.

I think this is what we want the classes to be: #include "../le3.h" namespace le3 { class NavMesh { public: float radius; float height; float climbheight; float maxslope; float cellsize; void AddVertex(const float& x, const float& y, const float&z); void AddPolygon(const int& count, const short* indices); bool Build(); bool BuildTile(const int& tilex, const int& tilez); Path* FindPath(const Vec3& p0, const Vec3& p1) }; class Path { public: std::vector<Vec3> points; }; }

You do not need to buy any other software to convert models. You have not posted any files for us to try, so there is no way for us to know what the problem you are having is.

Recast uses a fixed radius, doesn't it? I mean, it can't dynamically handle characters with different radii, can it?

Yep, that is true.

Handmade navmeshes in the CSG editor might be much more optimal: http://www.ai-blog.net/archives/000152.html However, my instinct says people will prefer an automatic solution, even if performance was ten times slower.

I just tried this, and the ball joints are holding the chain together: SuperStrict Framework leadwerks.ENGINE Graphics 640,480 RegisterAbstractPath "C:\Leadwerks Engine SDK" RegisterAbstractPath AppDir If Not CreateWorld() RuntimeError "Failed to create world." Local camera:TCamera=CreateCamera() Local buffer0:tbuffer=CreateBuffer(640,480,BUFFER_COLOR0|BUFFER_DEPTH|BUFFER_NORMAL) MoveEntity Camera, Vec3(0,40,-30) RotateEntity Camera, Vec3(45,0,0),0 SetShadowQuality(1) Local light:tlight=CreateDirectionalLight()' Create light MoveEntity (Light, Vec3(0,10,0) ) RotateEntity (Light, Vec3(45,45,0) ,0) EntityColor(Light, Vec4(1)) AmbientLight (Vec3(.2,.2,.3)) Local ground:tentity= CreateCube()' Ground Local groundphy:tbody = CreateBodyBox(100,100,100) EntityParent (ground,groundphy) ScaleEntity(ground,Vec3(100,100,100)) MoveEntity (groundphy, Vec3(0,-50,0)) SetBodyMass(groundphy, 0); EntityType (groundphy, 1, 1); Local crane:TEntity= CreateCube() Local cranephy:tbody = CreateBodyBox(100,2,2) EntityParent (crane,cranephy,0) ScaleEntity(crane,Vec3(100,2,2)) MoveEntity (cranephy, Vec3(0,30,0)) SetBodyMass(cranephy, 0) EntityType (cranephy, 1, 1) Local cubePhy:tbody[10] Local cube:tentity Local joint:tjoint For Local i:Int=1 To 10 cube= CreateCube()'boxes cubePhy[i-1]= CreateBodyBox(1,1,1) EntityParent (cube,cubePhy[i-1],1) ScaleEntity(cube,Vec3(2,2,2)) SweptCollision (cubePhy[i-1], 1) MoveEntity (cubePhy[i-1], Vec3(0,i*2-1+10,0)) SetBodyMass(cubePhy[i-1], 1) EntityType (cubePhy[i-1], 1,0) If i=10 Joint:tjoint = CreateJointBall( cranephy,cubePhy[i-1], Vec3(0,29,0)) End If If i>1 Joint:tjoint = CreateJointBall( cubePhy[i-1],cubePhy[i-2], Vec3(0,i*2-2+10,0)) End If Next Collisions(1,1,1)' Important! Enable collision between bodys of Type 1 While Not KeyHit(KEY_ESCAPE) If KeyHit(KEY_SPACE) AddBodyForce(cubePhy[Rand(9)],Vec3(10000,0,10000),0)' apply force End If UpdateWorld(1) SetBuffer(Buffer0) RenderWorld() SetBuffer(BackBuffer()) RenderLights(Buffer0) DrawText ("Press SPACE to apply force to one of the boxes!",0,0) Flip 1 Wend

Your programmer must be smarter than me, because I just see pages and pages of gibberish.

If you download it with SVN there's a doxygen folder. There's a footer and header html files, but no index or main page: http://code.google.com/p/recastnavigation/source/checkout

If you had ordered it through the account you are posting on, your account would have automatically been moved to the "Leadwerks Developer" group. If there was an error please email support at leadwerks.com with the email address you used to order and explain the problem.

So where's the documentation?

I'm trying to figure this out myself. His library is completely undocumented...there's just a demo with SDL, a GUI, and who knows what else built into it, so it's impossible to tell what the actual commands to use it are.

That's not a bad idea. Yes, you can link from one actor on one entity to another actor on another entity.

Can you rephrase that? I think we'll be able to save flowgraphs as part of a prefab, so you can set logic up once for a set of entities and then save it as one prefab of interconnected objects.

Mike, the entities are referenced by a unique ID, so the name does not matter. What scares me is what happens when the user resaves a script and the outputs and inputs change. It's very hard to write an editor that dynamically reloads everything. The whole purpose is to have a standard way of making things interact, so that all our scripted objects can talk to one another.

Ah yes, it's in a passworded zip, and only the editor knows the password.

To make an entity in Leadwerrks3D behave, you can drag a script from the asset browser to the actors list in the entity properties editor. Each entity can have multiple scripts attached to it. Each script can have different variables exposed, with control for the GUI they are displayed in. For example, you can specify upper and lower limits of a spinner or a list of choices for a drop down box. Each script attached to an entity, along with its set of properties, is called an "actor" because...it acts. To handle the interaction of different actors, a flowgraph is used. You can drag actors from the entity properties editor into the flowgraph editor. Each actor has inputs and outputs defined in its script. You can connect the output of one actor to the input of another. For example, you can connect the "tick" output of a timer script to the "Resume" output of a mover script, to make the mover translate and rotate an entity at regular intervals when the timer ticks: I hope this makes it more clear how entity interactions can be handled in Leadwerrks3D, even without programming. With this system, we're all working on one big game together, and we can share functional objects without any difficulty.

I believe you can do stuff like this so all actors can access a per-entity value: function actor:Update() self.entity.myvalue="Hello" end Normally you would want to keep them in their own separate spaces, within the actor table. Programming the editor to handle the multi-script attachments and properties, when scripts or objects may be reloaded at any time, is really incredibly gnarly, which is why I have never done anything like this before.

An "actor" is a script attached to an entity, with a set of properties. Each actor has it's own set of variables in Lua that don't interfere with each other. You can have multiple actors, even actors of the same type, attached to one entity, and they are each in their own "space". In the flowgraph, you will actually be looking at actors, not entities. To you and me, it's trivial to just write exactly what you want a script to do. To 99% of the potential market, programming is an utter impossibility, but they can attach a few behaviors to an entity and adjust some settings. It allows game development through visual trial and error. Good eyes! On one hand, this seems like a lot of work just to allow designers to do things without code that programmers can easily do. On the other hand, this means you can code a few scripts, give them to a designer, and let them make some game maps for you with interesting variations of the gameplay mechanisms you programmed.

Below you can see the properties editor. When you select a script attached to an entity, the properties for that script appear on the right. Here we have a simple "Pulse" script that changes the color of the entity along a sine curve. This can be used for making lights that pulsate slowly, or continually turn on and off. Here's what the script looks like. The "--in" tag at the end of the Pause and Resume functions indicate that these functions can be activated in the flowgraph editor. (A node can be connected to them to call them.) --float speed 1 --color color0 0,0,0,0 --color color1 1,1,1,1 --bool recursive function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:Update() if ~self.paused then local i = math.sin(AppTime()*self.speed*0.01) self.entity:SetColor(i*self.color0+(1-i)*self.color1,self.recursive) end end Here's our "mover" script, which just performs simple movement and rotation without physics: --vec3 translation 0,0,0 --vec3 rotation 0,0,0 --bool global true function actor:Start() self.paused=false end function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:SetTranslation(translation)--in self.translation = translation end function actor:SetRotation(rotation)--in self.rotation = rotation end function actor:Update() if ~self.paused then if self.movespeed~=Vec3(0) then self.entity:Move(self.translation[0],self.translation[1],self.translation[2],self.global) end if self.turnspeed~=Vec3(0) then self.entity:Turn(self.rotation[0],self.rotation[1],self.rotation[2],self.global) end end end Want an entity to animate in a loop? Attach this script to the entity: --int sequence --float speed 1 --bool paused false function actor:Start() self.frame=0 end function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:Draw() if ~self.paused then self.frame=self.frame+AppSpeed() self.entity:Animate(self.frame,self.sequence) end end What if we wanted a one-shot animation that plays when something triggers it? We can define an "Enable" function, connect another node to it, and some other event can cause the script to play the animation through once. Here's "PlayOnce.lua": --int sequence --float speed 1 --bool enabled false function actor:Start() self.frame=0 self.enabled=true end function actor:Enable()--in self.enabled=true self.frame=0 end function actor:Disable()--in self.enabled=false end function actor:Draw() if self.enabled then local length=self.entity:GetAnimationLength(self.sequence) self.frame=self.frame+AppSpeed() if self.frame>length then self.frame=length self.enabled=false end self.entity:Animate(self.frame,self.sequence) end end By using these general-purpose scripts we can set up game interactions and interesting behaviors, without coding...but if we need to code something new, the tools are a couple clicks away.