macklebee

Yep, that will do it. Overlapping pointlights set with dynamic shadows seem to get people all the time. Occlusion culling should be enabled on all lights and animated models as discussed in the Scene Panel tutorial. Also, there have been multiple discussions that have some useful tidbits of information on how to design your scene to run optimally: Analyzing performance: http://www.leadwerks.com/werkspace/topic/13222-analyzing-performance/ View ranges: http://www.leadwerks.com/werkspace/topic/13134-still-waiting-on-substance-support/page__st__20#entry93304

You would just have to copy the models, scripts, and prefabs over to the other project. Just make sure you place all the items that make the prefab in the same place or it will not work (or just require you to make the prefab again).

It may no longer be a beta feature - the default branch gets updated as well.

ambientlight.shares? the ambientlight.shader? yeah dont do that. This topic was from over two years ago - there have been many updates since then. Also, have you checked the shadmar's Post Effect shaders in the workshop? I believe klepto's fog is available in there.

You can put 20 light sources but you will need to be mindful of how many are creating dynamic shadows. Constantly updating realtime shadows from multiple pointlights will drop framerate dramatically.

Just tried that script and it appears to work just fine for me. No errors and I am being chased by 5 crawlers. Not that it seems to make a difference for me, but you could just set the 'prefab.script.target' to 'self.player' without having to check that the player has a script and it will work as well.

Like Aggror mentioned, just remove the boolean from those commands (true/false) or just update your project and it will work properly. As for the zombie model running backwards, what is the direction that the model faces when selected in the scene? If it's not facing towards its local +Z axis, then you have to adjust the 'character angle' in its Physics properties panel. Look at the crawler for reference and you will see the character angle is set to 180 because the crawler faces its local -Z axis.

Can you give more detail on your script? Have you checked the output log to see if it has loaded/executed the player's script prior to this script? I just tried this simple script on a csg box with the standard fpsplayer set as the 'script.player', and it seems to work. Script.player = nil --Entity "Player" function Script:Start() if self.player ~= nil then System:Print("player exists") end if self.player.script ~= nil then System:Print("script exists") end end

The problem in the past with using DAZ models for games was due to the ridiculous amounts of polygons used for characters (+500K was not unusual). I do not know if that has changed in recent years as it appears they have introduced a decimator to help reduce polys... Curious to see if its useable now.

Yes, some of the default materials that come with the nature pack also have this issue. I think it is caused by not having shadow shaders in the material but having 'Shadows' checked in the Vegetation properties panel. The default pine-trunk.mat's shaders: shader="Shaders/Model/diffuse+normal.shader" shader3="Shaders/Vegetation/diffuse+normal.shader" Resulting In-Game Scene: Changed pine-trunk.mat's shaders to: shader="Shaders/Model/diffuse+normal.shader" shader1="Shaders/Model/Shadow/shadow.shader" shader3="Shaders/Vegetation/diffuse+normal.shader" shader4="Shaders/Vegetation/Shadow/shadow.shader" Resulting In-Game Scene:

Yes I have seen this issue. It has something to do with the vegetation - specifically some of the tree materials/shaders being used/not used. Once I sorted the correct shaders for the material the dark shadow went away. I would suggest taking a look at the tree materials and confirm the right shaders are being used.

Its saved within the model (MDL) file itself, just like your exported model has the animations embedded in the FBX.

Review the Models and Animation tutorial - section 7 Animation.

Did you actually try the example script i posted? You can even take that code out of the main loop and the player will still move to the point if it can be reached. Whether you think this is wrong is another discussion. You are saying it shouldn't move the entity but only state if the point can be reached and the OP is saying that it should move the entity but doesn't. The example code shows that it does make the player move to the point if reachable even if its in a if/then statement. Unless there is a difference in versions (I am using the beta) that everyone is using and some fundamental thing has changed, then any use of this command that returns true will make the entity move to that point.

Yes, the engine has recast/detour built-in. See the AI, Pathfinding, and Events tutorial and map for examples and review the API for Entity Navigation commands.

Not from what I am seeing. Just one call to it will make the entity move if the point can actually be reached.

The character needs to stand in one place because animation in leadwerks has nothing to do with character navigation / movement. Basically you are just synching animation with moving the character via SetInput / GoToPoint / Follow commands, so the character needs to stay in one spot when the animations run. For reference, look at the inherent crawler model in the Model Editor and play its animations. Then look at the MonsterAI.lua script to see that actual movement of the crawler through the world is separate from the animation.

A picture would help us understand what you are talking about... or better yet, attach the model in question. But if I had to guess, you exported out some of the blender gizmos along with the model. You need to remove those before exporting.

Videos and pics are nice but for something like this I would like to see a working example if possible so that i could test myself. Like I alluded to above, I was not getting collision with a hidden object - using the object script you posted attached to a csg box. So I would be curious to see something I could test that causes this problem.

Are you sure? because I just used the default example code and used the exact code you said didn't work and the player moved. window = Window:Create() context = Context:Create(window) world = World:Create() local camera = Camera:Create() camera:SetRotation(35,0,0) camera:Move(0,0,-8) local light = DirectionalLight:Create() light:SetRotation(35,35,0) camera:SetDebugNavigationMode(true) local ground = Model:Box(10,1,10) ground:SetPosition(0,-0.5,0) ground:SetColor(0.0,0.25,0.0) local shape = Shape:Box(0,0,0, 0,0,0, 10,1,10) ground:SetShape(shape) shape:Release() entity = Model:Box(1,1,3) entity:SetColor(0.0,0.0,1.0) entity:SetPosition(0,0.5,0) local shape = Shape:Box(0,0,0,0,0,0,1,1,3) entity:SetShape(shape) shape:Release() ground:SetNavigationMode(true) entity:SetNavigationMode(true) world:BuildNavMesh() player = Pivot:Create() local visiblecapsule = Model:Cylinder(16,player) visiblecapsule:SetScale(1,2,1) visiblecapsule:SetPosition(0,1,0) player:SetPosition(-4,0,0) player:SetMass(1) player:SetPhysicsMode(Entity.CharacterPhysics) while window:KeyHit(Key.Escape)==false do if window:Closed() then break end if player:GoToPoint(4,0,0,1.4,1) then end Time:Update() world:Update() world:Render() context:SetBlendMode(Blend.Alpha) context:DrawText("NavMode: ".. tostring(entity:GetNavigationMode()),2,2) context:Sync() end Also, the example code you posted for Entity:Follow() is the incorrect syntax - so maybe thats why it didn't work?

If you found a work around then good. If you ever see this issue again, I would suggest posting an actual example showing hidden objects still colliding because I cannot make it happen and would be curious to see an example of the problem.

I am not having any collision with a hidden object, but i wonder if something is being messed up in your script based on the number of collisions being reported on first contact much like in your previous post. Suggest putting in a logic check to only allow the first reported collision to call the 'Hurt' function: function Script:Start() ... self.toggle = 1 end function Script:Collision(entity) if self.toggle==1 then self.toggle = 0 self:Hurt(100) end end

The character controller is a custom physics object so sometimes there are quirks with it. Some entity physics commands work with it and some do not. As far as the issue here, it appears just setting the player's physics mode to rigid body physics momentarily resolves the "bouncing". Script.respawnpoint = "" --entity "Respawn point" function Script:Collision (entity, position, normal, speed) if(entity:GetKeyValue ("name") == "Player") then spawnPos = self.respawnpoint:GetPosition () entity:SetPhysicsMode(Entity.RigidBodyPhysics) entity:SetPosition (spawnPos) entity:SetPhysicsMode(Entity.CharacterPhysics) end end

You set the pick's collision as Collision.LineOfSight which according to this diagram will only collide with 'Collision.Scene' collision types. Here is the list of the inherent collision types and responses: List of inherent types: Collision.Prop = 1 Collision.Scene = 2 Collision.Character = 3 Collision.Trigger = 4 Collision.Debris = 5 Collision.Projectile = 6 Collision.LineOfSight = 7 List of possible responses: Collision.None = 0 Collision.Collide = 1 Collision.Trigger = 4 With the following warning from Josh concerning using the constants and not the numerical values: "You really should stick to using the named constants. Technically, the values of these are allowed to change at any time, without breaking the spec."

Are you using a directional light? Unless you need it, I would delete it. If you need it, the you can try different settings for your lights - static vs dynamic