macklebee

orbital camera example here: http://www.leadwerks.com/werkspace/topic/14066-solvedrotate-the-camera-around-the-object/#entry96667

Everything color related in the engine uses the 0-1 scale. The color picker is set with a 0-1 scale and it will return a 0-1 scale. Only within the actual picker will it show the 0-255 scale. See the bug report from a year ago that explains why this is the case: http://www.leadwerks.com/werkspace/topic/12241-script-color-property-returns-unexpected-results/

Nope - makes no difference. It appears like there is something wrong with the UV's as there is a hint of blue on the cone/cylinder. If you loaded the orangegrid.mat, you would see a hint of orange.

Yes, appears to be a bug - like the UV's are not being set properly upon creation of the cylinder or cone when done via code. This has nothing to do with adding a physics shape.I would suggest you open a bug report with a simple main.lua script that shows the issue instead of an object script.

If we have to guess, then I suspect the model's UVs are not mapped correctly. Like I suggested in steam forum, we need to see the actual fbx, mdl, tex, and mat files to be able to test ourselves, otherwise we are just guessing. Zip those files up and post them please.

For the rope material, you are using the animated diffuse shader. Change it to the normal 'Model/diffuse.shader' and you will see it. Also remember that you can right-click to open the material file to view as a text file. This will show the settings as well as the file paths to the textures and shaders. Granted if the animated shaders were not named exactly like the normal shaders, this wouldn't be an issue that continues to stump people time and time again.

Entity:Hide() This functions hides an entity. A hidden entity will be invisible, will not collide with other entities, and its 4x4 matrix will not be updated when the parent moves. For trigger boxes and the such, use the invisible.mat material file found in the Materials/Effects folder.

If you read the link that was posted, you would see that an animation shader is required in your material file for animated models. Since you only posted the fbx and mdl file, I assume you never created a Leadwerks material file that uses an animated shader. Also the fbx model does not have any UV's mapped and the model itself is huge. Here is the model scaled down to 1 meter tall, properly UV mapped, and with a Leadwerks animated shader material applied. box_anim.zip Again, this is not a Leadwerks bug, but rather a problem with how you are using/exporting from Blender and then not using the correct Leadwerks material. The Game Art forum is a good place to search for examples on how to export from blender. I think forum member ScrotumPancakes ScrotieFlapWack recently provided some tips on the blender setup. Edit- My mistake with the forum name - thats what pops into my head everytime I see his name. Thanks for the catch, Thirsty Panther.

The bug report section is not the ideal place to post this. Have you looked at the official tutorial: http://www.leadwerks.com/werkspace/page/tutorials/_/models-and-animation-r8

Sure there are workarounds but it doesn't really make sense that a character using the navmesh can start walking through any object with higher mass. I could see trying to incorporate a workaround into a map with a lot of objects and characters turn into a real pain. The physics bodies should be colliding and preventing this from occurring and that doesn't appear to be happening. It looks like it reports the collision but doesn't prevent it from passing through. What is interesting is if the object's mass is lower than the character's mass, then the object will just be pushed out of the way which means the collision is happening. But set the object's mass higher, the character walks through it.

As covered in the topic started by Angelwolf here: http://www.leadwerks.com/werkspace/topic/14318-my-monsters-can-run-through-walls/#entry98176 Characters can walk through objects that have mass no matter what the collision types are set. Attaching an example that shows the issue. The top box has mass and the lower box has no mass. Example that shows the problem: window = Window:Create("monster",0,0,800,600,17) context = Context:Create(window) world = World:Create() camera = Camera:Create() camera:Move(0,8,0) camera:SetRotation(90,0,0) camera:SetDebugPhysicsMode(true) light = DirectionalLight:Create() light:SetRotation(35,35,0) ground = Model:Box(40,1,40) ground:SetPosition(0,-0.5,0) ground:SetColor(0,1,0) shape = Shape:Box(0,0,0, 0,0,0, 40,1,40) ground:SetShape(shape) ground:SetNavigationMode(true) box1 = Model:Box(1,1,5) box1:SetPosition(0,.5,3) shape = Shape:Box(0,0,0, 0,0,0, 1,1,5) box1:SetShape(shape) box1:SetMass(1000) box1:SetCollisionType(Collision.Prop) box2 = Model:Box(1,1,5) box2:SetPosition(0,.5,-3) shape = Shape:Box(0,0,0, 0,0,0, 1,1,5) box2:SetShape(shape) shape:Release() box2:SetCollisionType(Collision.Prop) world:BuildNavMesh() monster = Model:Load("Models/characters/crawler/crawler.mdl") monster:SetPosition(-4,0,0) monster:SetCharacterControllerAngle(180) monster:SetMass(1) monster:SetPhysicsMode(Entity.CharacterPhysics) monster:SetCollisionType(Collision.Character) waypoint = {} waypoint[1] = Pivot:Create() waypoint[1]:SetPosition(4,.5,4) waypoint[2] = Pivot:Create() waypoint[2]:SetPosition(4,.5,-4) waypoint[3] = Pivot:Create() waypoint[3]:SetPosition(-4,.5,1) wpt = 1 while window:KeyHit(Key.Escape)==false do if window:Closed() then break end if window:KeyHit(Key.Space) then wpt = wpt + 1 end if wpt > 3 then wpt = 1 end pos = waypoint[wpt]:GetPosition(true) monster:GoToPoint(pos,2,3) Time:Update() world:Update() world:Render() context:SetBlendMode(Blend.Alpha) context:DrawText("Press SPACE to move to next waypoint",2,2) context:SetBlendMode(Blend.Solid) context:Sync() end

It appears to be related to the door having mass. Set the door to zero mass, and the monsters cannot go through. This also means a possible work around would require you to not use joints but to use SetPosition() to open / close the doors. But this also means the monsters will walk right through any prop as well unless it was set as a nav obstacle. So yes, it appears maybe something has changed. Edit: Created an example and opened a bug report that shows the issue: http://www.leadwerks.com/werkspace/topic/14323-character-pass-through-objects-with-mass/#entry98210

No, you do not want the door set as a 'Nav obstacle' because then there would not be a path through the door when the navmesh is built. As I mentioned above, the 'AI and Events' tutorial map uses a trigger that enables the monster script (and opens the door) which will allow the monster to start navigating through the door and the scene. Edit - it appears the characters can push through the door when it has mass and/or set up as a physics object using joints. You could set it up so that the mass and script is applied to the door once you want the door to open, but that would be a little more complicated. So the best/easiest way probably is to use the method shown in the tutorial map.

Does the door have a physics shape? Use camera:SetDebugPhysicsMode(true) in game or turn on in the editor. What do you have the collision types set to for the door and the monsters? A good reference is the 'AI and Events' tutorial map that shows this exact scenario. In that map's flowgraph you will see that the monster script is not enabled until a pushbutton trigger occurs which may be something you would want to emulate as well.

The crouch height is 1.2 meters (I must have been remembering old heights typically used with LE2). What may be confusing about the crouch is that the visible debug physics body does not change size when crouch is true. Example script that shows the crouch height of 1.2 meters. Use WSAD to move and hit C to crouch: window = Window:Create("crouch height",0,0,800,600,17) context = Context:Create(window) world = World:Create() camera = Camera:Create() camera:SetRotation(40,0,0) camera:Move(0,0,-8) light = DirectionalLight:Create() light:SetRotation(35,35,0) camera:SetDebugPhysicsMode(true) ground = Model:Box(10,1,10) ground:SetPosition(0,-0.5,0) ground:SetColor(0,1,0) shape = Shape:Box(0,0,0, 0,0,0, 10,1,10) ground:SetShape(shape) shape:Release() box1 = Model:Box(1,1.2,1) box1:SetPosition(-2,0.6,-1) box2 = Model:Box(1,1.2,1) box2:SetPosition(2,0.6,-1) box3 = Model:Box(5,1,1) box3:SetPosition(0,1.7,-1) shape = Shape:PolyMesh((box1:GetSurface(0))) box1:SetShape(shape) shape = Shape:PolyMesh((box2:GetSurface(0))) box2:SetShape(shape) shape = Shape:PolyMesh((box3:GetSurface(0))) box3:SetShape(shape) shape:Release() player = Pivot:Create() visiblecapsule = Model:Cylinder(16,player) visiblecapsule:SetScale(.8,1.8,.8) visiblecapsule:SetPosition(0,.9,0) player:SetPosition(-4,0,0) player:SetMass(1) player:SetPhysicsMode(Entity.CharacterPhysics) crouch = false while window:KeyHit(Key.Escape)==false do if window:Closed() then break end move = ((window:KeyDown(Key.W) and 1 or 0) - (window:KeyDown(Key.S) and 1 or 0))*4 strafe = ((window:KeyDown(Key.D)and 1 or 0) - (window:KeyDown(Key.A) and 1 or 0))*4 jump = (window:KeyHit(Key.Space) and 1 or 0)*8 if window:KeyHit(Key.C) then crouch = not crouch end player:SetInput(0,move,strafe,jump,crouch) Time:Update() world:Update() world:Render() context:SetBlendMode(Blend.Alpha) context:DrawText("Crouched: "..tostring(crouch),2,2) context:SetBlendMode(Blend.Solid) context:Sync() end Also note this example shows that when crouching under something, the developer needs to prevent standing back up to prevent weird physic results from occurring - ie character slingshot across map, character pushed through the map, etc...

yep, in lua the only FindSurface() available was for Model:FindSurface() - which you may be able to use after the csg/brush is auto converted. Its been available for quite sometime to export to OBJ.

At runtime, a csg/brush is converted to the Model Class - assuming it doesn't have a script or mass. You can then get the surface easily. Out of curiosity, does the inherent export for the CSG not work for your needs or is there another aspect that requires you to make your own export?

How low are the objects that you are trying to crouch under? If its lower than 0.8 or 0.9 meters then you will not be able.

so like this but pixelated?

In the Windows version, it doesn't automatically resize the screen resolution (context's width & height) either when switching in-game but it does make the window go fullscreen. And while there is no inherent method to determine current display resolution, I just always pick the last available resolution that the monitor can support as typically this is the default native resolution.

Just make your own Collision type and response: http://www.leadwerks.com/werkspace/topic/11744-defining-new-collision-constantstypes/#entry84834

If using images meant for UI, makes sure the converted tex file is saved as uncompressed. The default is DXT1 which will convert images to powers of 2 which usually distorts images used for UI (as they are not typically powers of 2). Remove mipmaps as well. Read the section regarding Compression in the Leadwerks Texture tutorial for more details.

hmm well thats two people using AMD according to your profiles.

A lot of stuff running in the background? Is Realtime Render enabled in the View menu? Is this something new or has it always been like this? Graphics card driver has been updated recently thats now causing this or maybe you need to update?

Again, we are not mind readers. Your first post just asks if you can run the game fullscreen. Your second post just said you cannot find where to do "that" which seemed to be asking where in the Window:Create() command to set the fullscreen style parameter. The third post asking to find a script was interpreted to be asking for a script showing how to change to fullscreen in game. You need to explain better what you are looking for as I had no idea that after a month of posting here that you didn't know that the Main.lua script was the script being ran at runtime. Again, I would recommend that you review the official leadwerks tutorials as they are full of good information that will help explain a lot of the beginner's questions.