macklebee

Not yet but it does look interesting. There is a free trial available at the developer website: https://www.nukeygara.com/

Resource Hacker works for LE Windows executables. Don't know if it would for any other platforms though.

Can you give more information? Example code showing the issue would help to see what is happening. All anyone can do is guess with so little information. example code in lua showing it working: window = Window:Create("example",0,0,800,600,513) context = Context:Create(window) world = World:Create() camera = Camera:Create() camera:Move(0,0.5,-2) light = DirectionalLight:Create() light:SetRotation(35,35,0) drum1 = Model:Load("Models/barrel/barrel.mdl") drum2 = drum1:Copy() drum2:SetPosition(-1,0,0) drum3 = Model:Load("Models/barrel/barrel.mdl",Asset.Unmanaged) drum3:SetPosition(1,0,0) while window:KeyDown(Key.Escape)==false do if window:Closed() then break end if window:KeyHit(Key.D1) and drum1 then drum1:Release() drum1 = nil end if window:KeyHit(Key.D2) and drum2 then drum2:Release() drum2 = nil end if window:KeyHit(Key.D3) and drum3 then drum3:Release() drum3 = nil end Time:Update() world:Update() world:Render() context:Sync(true) end

Well, it could be done via shaders. But if you need to change/adjust the UV texcoords on a model, I would recommend just using your modeling app to perform this.

Well, the mapping scale is meant only for CSG as mentioned in the material tutorial: The Material Editor is not using CSG for its models I suspect, but rather models embedded into the program. Yes, it doesn't appear that the brush/face's mapping scale is exposed which is not surprising considering Josh's previous statement about the brush class: So essentially, the mapping scale is only applied to CSG which means only applied to brushes created within the Editor. Like I mentioned above if you change a brush's material mapping scale that is already created within the editor, it will not update visibly in the editor unless you move the existing brush. Even if you do not update in the editor, it will still update in game.

Other than not updating within the material editor itself and what I listed above, I am not having any issues with this as far as not working at all. What OS and material/shaders are you trying this with? Have you tried doing this as well via selected faces?

Looks pretty good! Maybe add some water splash/spray emitters on the edges of the waterfall to add to the effect?

Decals are inherently only set to include/exclude based on object class - brush, model, or terrain. The only suggestion I can think of is trying to remove the 'decalmode' material flag portion of your character's shader file. Suggest saving and applying it as a separate shader name to the character's material file. I don't know if this will work, but if it does then it seems like setting the decal mode per entity would be more preferable than per class. Edit: It does work - just remove the decalmode lines from the shader file: if (decalmode==1) materialflags += 4;//brush if (decalmode==2) materialflags += 8;//model if (decalmode==4) materialflags += 16;//terrain

It doesn't appear to update in the Material Editor, but the changes you make there do update with any newly created object in the Editor that has that material or when an existing CSG object is moved. Also, if you make the change via the Texture Mapping in the Editor, it updates the selected face.

context:SetFont(self.ammofont) local ammo = self.player.script.weapons[self.player.script.currentweaponindex].ammo if ammo >= 100 then context:DrawText(self.totalammotext, (context:GetWidth()*.935)+self.size.x*.02, (context:GetHeight()*.955)-self.size.y*.5) elseif ammo < 100 and ammo >= 10 then context:DrawText(self.totalammotext, (context:GetWidth()*.942)+self.size.x*.02, (context:GetHeight()*.960)- self.size.y*.5) elseif ammo < 10 then context:DrawText(self.totalammotext, (context:GetWidth()*.955)+self.size.x*.02, (context:GetHeight()*.965)- self.size.y*.5) end You never see the below 10 condition because you are satisfying the second condition since 10 < 100. Another way to do this without having to resort to putting multiple conditions together as I showed above using the 'and' would be to just rearrange the order of conditions: context:SetFont(self.ammofont) local ammo = self.player.script.weapons[self.player.script.currentweaponindex].ammo if ammo < 10 then context:DrawText(self.totalammotext, (context:GetWidth()*.955)+self.size.x*.02, (context:GetHeight()*.965)- self.size.y*.5) elseif ammo < 100 then context:DrawText(self.totalammotext, (context:GetWidth()*.942)+self.size.x*.02, (context:GetHeight()*.960)- self.size.y*.5) else context:DrawText(self.totalammotext, (context:GetWidth()*.935)+self.size.x*.02, (context:GetHeight()*.955)-self.size.y*.5) end

Suggest playing around with the camera's FOV. The default is 90 degrees. It's 70 degrees if using fpsplayer script which sometimes seems restrictive in some scenes depending on your screen's aspect ratio or your window's resolution.

huh? It wasn't shared or official? No, you are not remembering correctly. It was one of the big features of LE2.3 (see deserthighway.sbx) and was a part of the Editor all the way to the final version 2.51. And it worked just fine once you figured out setting the rotations on the road nodes to determine how you wanted your curve to look, The biggest drawback was just how long it took to load the saved serialized data to create the road.

I don't ever remember having that issue. If you run my example shown do you have the same issue? If not, then i would suggest you set your code like my example - most noticeable difference is i set the mouse's position after setting the camera's rotation, not right after getting the mouse's position.

I think you mean clamp the rotation around the X-axis. http://www.leadwerks.com/werkspace/topic/14389-headbobbing-mechanic/#entry98643

you can just adjust the position drawn when under 10 by using if statements, or you can format the number to show a leading zero when under 10. --Draw the Ammo Count context:SetFont(self.ammofont) local ammo = string.format("%02d", self.totalammotext) context:DrawText(ammo, (context:GetWidth()*.935)+self.size.x*.02, (context:GetHeight()*.955)-self.size.y*.5)

http://www.leadwerks.com/werkspace/topic/14513-unique-model-material/#entry99202

http://www.leadwerks.com/werkspace/page/tutorials/_/materials-r7

Currently, I don't have a way to test this due to graphics card issues, but looking at the code I would make the following suggestions: - Load the textures and fonts in the Script:Start() function - In the Script:PostRender() function, always set the context's blendmode and color back to the standard Blend.Solid and (1,1,1,1) to avoid interference with other code that might be rendering images and texts. - Once you set the blendmode to Alpha, you don't have to keep doing it prior to each Draw command - Leadwerks colors use a color scale of 0-1 and not 0-255. The only thing that displays 0-255 is the editor's color property but it is actually using 0-1 to set the color property and it will return the 0-1 scale. - I can't tell if your hud image requires alpha or not, if it does then ignore this - but if it doesn't then draw with a solid blendmode example code that shows the above changes: Script.size = Vec2 (175,25) --vec2 "Size" Script.textcolor = Vec4(1,1,1,1) --color "Health Text " Script.ammocolor = Vec4(1,1,1,1) --color "Ammo Text " Script.player = nil Script.healthtext = nil Script.maxhealthtext = nil Script.clipammotext = nil Script.totalammotext = nil Script.healthfactor = nil Script.healthdisplay = nil Script.ammodisplay = nil Script.clipdisplay = nil function Script:Start() self.hudfont = Font:Load("fonts/Arial.ttf", 14) self.clipfont = Font:Load("fonts/Arial.ttf", 32) self.ammofont = Font:Load("fonts/Arial.ttf", 18) self.image={} self.image.ammoboxdisplay = Texture:Load("Materials/HUD/Status.tex") self.player = self.entity: GetParent() end function Script:UpdateWorld() self.healthtext = self.player.script.health self.maxhealthtext = self.player.script.maxHealth self.healthfactor = self.healthtext / self.maxhealthtext self.clipammotext = self.player.script.weapons[self.player.script.currentweaponindex].clipammo self.totalammotext = self.player.script.weapons[self.player.script.currentweaponindex].ammo --self.Scoretext = killscore self.healthdisplay = "+" ..self.healthtext self.clipdisplay = "" .. self.clipammotext self.ammodisplay = "" .. self.totalammotext end function Script:PostRender(context) context:SetFont(self.hudfont) --Draw HUD Display context:DrawImage(self.image.ammoboxdisplay, context:GetWidth()*1.05-self.size.x, (context:GetHeight()*.9)- self.size.y, self.size.x*.65, self.size.y*3.7) --Draw the Health --DrawText (text to draw, xpos, ypos) context:SetColor (self.textcolor) context:SetBlendMode(Blend.Alpha) context:DrawText(self.healthdisplay, (context:GetWidth()*.932)+self.size.x*.02, (context:GetHeight()*.915)- self.size.y*.5) context:SetFont(self.clipfont) --Draw the Clip Count --DrawText (text to draw, xpos, ypos) context:DrawText(self.clipammotext, (context:GetWidth()*.880)+self.size.x*.02, (context:GetHeight()*.928)- self.size.y*.5) context:SetFont(self.ammofont) --Draw the Ammo Count --DrawTex (text to draw, xpos, ypos) context:DrawText(self.totalammotext, (context:GetWidth()*.935)+self.size.x*.02, (context:GetHeight()*.955)-self.size.y*.5) context:SetBlendMode(Blend.Solid) context:SetColor(1,1,1,1) end

It's hard to tell from a screenshot - a simple example program that shows the problem by showing how you are drawing the text would be more helpful. But since we have to guess, are you loading multiple sized arial fonts or are you scaling the context when drawing? Do the numbers clear when they change or is there a smearing from the previous numbers?

Since the introduction of the new GUI/window creation, creating a window now requires you to include the parameters of Window:Create(): Syntax static Window* Create(const std::string& title="Leadwerks", int x=0, int y=0, int width=1024, int height=768, int style=Titlebar)

In that case, 15% is taken by Leadwerks, 10% by Shadmar, 10% by Roland, 10% by Rick, and 10% by me. Re-read the sentence from Josh that you quoted and you have the answer to your question: "If you sell items in the Workshop Store, Valve will take 30% and Leadwerks will take 20%."

Its hard to tell because in both videos you keep moving the character around when playing the run animation in the model editor for some reason... but it looks like the animation has translation properties. The characters' animation should be centered around the origin and the character should just be running in place. Maybe I am wrong but its hard to tell from your videos, but the character looks like its moving forward from its origin which may explain some of the sliding that appears to be happening during its navigation.

AI, Pathfinding, and Events Tutorial: http://www.leadwerks.com/werkspace/page/tutorials/_/ai-pathfinding-and-events-r28#section9 Look at section 9 regarding Navmesh Generation.

Leadwerks engine's colors are on a scale between 0-1, only the editor's color property displays the 0-255 scale. See this bug report that explains why: http://www.leadwerks.com/werkspace/topic/12241-script-color-property-returns-unexpected-results/ and the other bug report that was posted with the same question: http://www.leadwerks.com/werkspace/topic/14366-color-picker-bug/ If you would set the property as shown below, you would see the correct values in the editor's color property:

If you look at the MonsterAI script itself, you will see that the animation names called out are: - Idle - Run - Death - Attack1 - Attack2 If you open the crawler model in the model editor, you will see this matches its animation names as well. If you are going to use the inherent script for the crawler, then you must make your model's animation names correspond to the script.