macklebee

Just perform the context:Screenshot() based on a key hit - because it does not immediately end a game. if window:KeyHit(Key.P) then context:Screenshot("c:/screenshots/image_"..Time:GetCurrent()..".tga") end Run your game's executable and not through the editor if you don't want a steam pics page to open after the game closes - of course, do not initialize steam in your game either...

Agree - beats having to refresh constantly

Good deal. I think that's always been an extremely useful feature here.

will there not be a chat any more?

yep looks like its fixed. You can close this bug report:

The bug report had to do with Window styles would always lower case the 'Window' portion of the code when posted in the forum. So 'Window.Center' would automatically convert to 'window.Center' for whatever reason.

what about the issue with the word Window ending with a period, which was a long running bug report for the forum. window = Window:Create("example",0,0,1024,768,Window.Center) Edit- looks like it works now and that report can finally be closed.

This example shows the issue Haydenmango is describing where the child is slow to follow the parent's movement: window = Window:Create() context = Context:Create(window) world = World:Create() camera = Camera:Create() camera:Move(0,0,-4) light = DirectionalLight:Create() light:SetRotation(35,35,0) parent = Model:Box() parent:SetColor(0.0,0.0,1.0) child = Model:Box() child:SetColor(1.0,0.0,0.0) child:SetMass(1) child:SetPosition(2,0,0) joint = Joint:Hinge(0,0,0, 0,0,1, child, parent) while true do if window:Closed() or window:KeyDown(Key.Escape) then return false end p = window:GetMousePosition() p.z = 4 p = camera:UnProject(p) parent:SetPosition(p) Time:Update() world:Update() world:Render() context:Sync() end

Creating a Ball Joint causes the engine to crash. Run the example in the API reference to duplicate: http://www.leadwerks.com/werkspace/page/api-reference/_/joint/jointball-r732

https://www.leadwerks.com/docs.php?page=API-Reference_Object_Joint_Slider#

It appears there's something in the scene it doesn't want to render? Have you tried removing objects from the scene panel to see if the issue stops?

http://www.leadwerks.com/werkspace/blog/1/entry-1866-common-bottlenecks/page__st__20#commentsStart\

hmmm this may explain why none of my vehicles work....

I would expect 100 rigged crawlers to have a more significant expense when moving than 100 collapsed crawlers. The rigged crawler has 24 bones, so the engine is having to update not just 100 models but 2500 entities when you perform a Move(). Same idea with the navmesh navigation. And it may be worse with the character models you are trying- how many bones do they have? Then add animation ontop of that... One way to lessen the animation costs is to perform animation only in the Script:Draw() function. The only thing that might lessen the navmesh navigation is if Josh implements model LOD's at some point (like we had in LE2) - where at some distance the model can be swapped for a non rigged version of the model. As far as FPS though - that's very subjective and will vary from computer to computer, but IMO if you can still achieve a fairly stable 60 fps then you are probably alright. And in some games, you might not need it that high, depends on the game/gameplay, etc...

yeah- this post was about the character controller not rotating unless the controller was moving... because someone wasn't using an up to date version. The problem you are referring to is a completely different issue. And yes, i do see that... but it only occurs on the start of the program - almost like the character physics werent created all the way yet prior to the platform moving. if you jump several times, you can get the character to land on top of the platform and its all okay after that. Definitely an issue, but as Josh is implementing the new newton physics engine version in a new way in this beta i suspect there will be issues. You should definitely make a bug report.

huh? am i missing something? why wouldn't it not rotate if i don't move the mouse?

Yeah, not quite sure what i should be seeing here in the beta. I can turn completely around with just the mouse while not pressing the WSAD keys.

or just update your project to three of the available versions, beta (Ver4.4), stable (Ver4.3), or Ver4.1. This latest issue was caused by an "optimization" in the Ver4.2 that was resolved within Ver4.3 beta and was never part of the Ver4.3 stable release.

I can't get this to occur. Can you give more information about your emitter settings? Also, the Play() like many LE commands probably shouldn't be called every loop as it's meant to only resume playing a paused emitter. I am not having any issues with this simple example: window = Window:Create("Example", 0, 0, 800, 600,window.Center) context = Context:Create(window) world = World:Create() camera = Camera:Create() camera:SetPosition(0,1,-1.5) light = DirectionalLight:Create() light:SetRotation(35,35,0) prefab = Prefab:Load("Prefabs/Effects/smoke.pfb") prefab = tolua.cast(prefab,"Emitter") while not window:KeyHit(Key.Escape) do if window:Closed() then return false end if window:KeyHit(Key.Space) then if prefab:GetPaused() == true then --emitter is paused prefab:Play() else --emitter is not paused prefab:Pause() end end Time:Update() world:Update() world:Render() context:SetBlendMode(Blend.Alpha) context:DrawText("Press Space to Play/Pause",2,2) context:SetBlendMode(Blend.Solid) context:Sync(true) end If the parent has a script, it will call the child script's Start() unless otherwise specified by NoStartCall. If the prefab is just the emitter as the prefab or the parent of the prefab then it will play with or without a script if the emitter settings are set that way. And yes, the SetLoopMode needs to be set... bit i assumed he did that when he created the emitter prefab?

burgelkat - thats the difference. Nice catch. In the two leaves shaders that use the wind calculation (vegetation & vegetation shadow), the code is slightly different between the two. Shaders/Vegetation/leaves.shader: vec4 movement = vec4( vec3( (vertex_color.r) * vertex_normal * 0.02 * (sin(seed)+0.25*cos(seed*5.2+3.2)) ),0.0); Shaders/Vegetation/Shadow/leaves.shader: vec4 movement = vec4( vec3( (1.0-vertex_color.r) * vertex_normal * 0.02 * (sin(seed)+0.25*cos(seed*5.2+3.2)) ),0.0); The Shaders/Models/groundplants.shader code also looks like the vegetation shadow code. I am not sure why it appears to work on some trees and not the others (an issue with vertex normals/color?). But if you change the code to '1.0-vertex_color.r' then it appears to work fine on his pine tree.

Two years on a suggestion that Josh liked, and I am still having to go back to the assets tab to create a new script instead of just creating it with the object's properties tab.

The problem is with recast/detour. The navmesh needs certain data like character height/width/stepheight to determine if a path would be feasible, how close a path should be around walls, etc... If you had multiple character sizes then you would need multiple navmeshes - which means characters on different navmeshes would have no knowledge of each other. While I agree that having access to certain variables to control the character cylinder size would be ideal, then it would be an issue with navmeshes and what is passed to it prior to creation. The easiest solution (especially for 90% of users) was to hardcode this. Maybe one day Josh will allow us to control these variables for the controller and the navmeshes, but I would be surprised since this has been requested since LE3 with no luck.

This is not occurring for me at all. So instead of necro-posting a 4 year old post, make a new post with an example that shows your problem. Add details like if you are using the beta or an older revision, are you using a custom script that controls the controller, etc...

I never really understood the inherent env shaders as it puts the cubemap against the emission channels for FragData2. Seems like it should be put against the diffuse color components of FragData0. Here is a shader that does this - and honestly at this point i don't know where I got it... diffuse+normal+specular+cubemap.zip I used the inherent glass textures for the diffuse, normal, and specular texture slots. I put the skybox texture as slot 4, set the blendmode to Alpha, and set cast shadows, two sided, depth test, depth mask, and z-sort to true.

I try to not parent anything that doesn't have the scales set up correctly to (1,1,1). It seems there is always something that is going to cause issues with rotation or positioning if you have multiple things scaled especially if you are setting the rotation/position to local space. As far as child scripts, I just keep in mind that its parent and its parent's parent - all the way to the base parent, must have a script. So far that approach has worked for me. But in attempt to make this even easier and to avoid any scaled positioning/rotational child issues, this whole assembly could have been one prefab without the need to load another prefab onto it. But I understand your reasoning for it, since you are going to use the same candle flame effect on other items other than the chandelier.