macklebee

It may be failing to load a map. Delete your 'leadwerks.cfg' and then try starting the editor again. Edit- also, attach your 'leadwerks,log' because it looks like there is another error referring to '...target entity not found'

The only time I see this is when I load the chandelier prefab via code. If the chandelier prefab is in an editor scene, then it loads everything fine. Is this what you are doing? Edit-- I went through and fixed the scale on all the candles, candlesticks holders, and the chandelier by opening them in the Model Editor and using Tools>Collapse to set the inherent scale to (1,1,1). Then I rebuilt my chandelier with the candlesticks and added a slightly modified version of the 'LoadCandleFlame.lua' script that makes the flame a child of its candle. Also, my flame is a scaled sprite prefab of the firepit fire and point lights so i had to change slightly the Y positioning of the Flame in the script. Now whether I load the chandelier via the map or load it via code, it loads, runs the scripts, and positions the candles' flames properly. 'LoadCandleFlame.lua' was modified so that it only needed to be attached to the chandelier model itself. Also, note that I didn't use the 'Candle_02.mdl' as its origin was offcenter from the model after fixing the scale. function Script:Start() local candle = "Candle_0" local numberofkids = self.entity:CountChildren() for j = 0, numberofkids - 1 do local y = 0 local child = self.entity:GetChild(j) local pos = child:GetPosition(true) local name = child:GetKeyValue("name") local Flame = Prefab:Load("Prefabs/Props/CandleLight.pfb") Flame:SetParent(child) if name == candle..1 then y = .16 elseif name == candle..3 then y = .19 elseif name == candle..4 then y = .23 elseif name == candle..5 then y = .26 end Flame:SetPosition(pos.x,pos.y+y, pos.z, true) end end Granted all of this could be just turned into one prefab instead of building onto each other...

Is your 'brick' made from a CSG brush in the LE Editor? If so, review the "Painting Brush Faces' section of the Materials tutorial. http://www.leadwerks.com/werkspace/page/tutorials/_/materials-r7#section6

its very odd. what is really weird is that the branches' shadows show movement but the actual branches do not.

The modeling application you use or its export options will affect the vertex colors. If you are not using the vertex colors for anything else, then just open the model in the LE Model Editor and use the Tools>Strip Vertex Colors option and it will make all vertex colors white (1,1,1).

Pictures are nice but an example model and script showing the issue would be more helpful.

Seems to work ok for me - maybe I am not seeing the issue you are referring to? Other than the warning about 'ex_texcoords0' and 'ex_normal' might be used prior to initializing, I am not seeing a problem. Do you have a particular item where the normals seem wrong? To get rid of the warning, just initialize the variables prior to the for loop: void main() { ex_texcoords0 = vec2(0); ex_normal = vec3(0); for(int i = 0; i < gl_in.length(); i++) { gl_Position = gl_in.gl_Position; ex_color = g_ex_color; ex_texcoords0 = g_ex_texcoords0; ex_normal = g_ex_normal; EmitVertex(); } EndPrimitive(); ... ...

Well, looking over the wind calculation they still move based on vertex color and maybe that is his issue. But Tomas has not said whether or not his problem with lack of movement occurs when he is manually placing the tree or when using the vegetation tool. If he is manually placing the tree, then the leaves will not move based on the inherent 'Models/leaves.shader'. If they are not moving when the tree is set using the vegetation tool, then it very well could be the vertex color that is preventing the swaying. //Wind animation float seed = mod(currenttime * 0.0015 ,360.0); seed += ex_entitymatrix[3].x*33.0 + ex_entitymatrix[3].y*67.8 + ex_entitymatrix[3].z*123.5; seed += modelvertexposition.x + modelvertexposition.y + modelvertexposition.z; vec4 movement = vec4( vec3( (vertex_color.r) * vertex_normal * 0.02 * (sin(seed)+0.25*cos(seed*5.2+3.2)) ),0.0); modelvertexposition += movement; modelvertexposition = entitymatrix_ * modelvertexposition; But again without seeing the model, its all just a guess.

The only time I see leaves swaying is when the tree is set with the vegetation tool. If I set the same tree by just placing the model, I get no leaves swaying. The 'Models/leaves.shader' doesn't have a wind animation calculation in the vertex code, but the 'Models/Vegetation/leaves.shader' does. So that at least explains that, even though I think that needs to be rectified inside the 'Models/leaves.shader'. As for the other issues with shadows, without seeing the model in question we can only guess. Perhaps you need to recalculate your normals? Faces are flipped? Maybe you don't have the material settings the exactly the same? I know I mess up trees' shader setting all the time because for some reason the default LE shaders are all named the same but are only differentiated by what folder they are in... ie. there are 3 'leaves.shaders' but the one in the vegetation folder can't be used for shader 0 but only for the vegetation shader 4.

I lied to you! It looks like Josh has added that at some point but doesn't have it documented yet. I can see from a lua global variable dump there is this command: Math:SeedRandom(float) EDIT-- just tried it and it appears to work properly. I get different numbers each time i run the program.

Usually, when a program starts, it initializes the generator with a fixed seed. That means that, every time you run your program, it generates the same sequence of pseudo-random numbers. ]LE's Math:Random() doesn't have a way to change the seed.

Just as an aside here - but Julio is not some random guy that has no experience with any other physics engines other than his own. He was (possibly still is) one of the main physics programmers for Planetside2 multiplayer that uses PhysX. Point being - the guy knows his sh.it. http://www.metacritic.com/person/julio-jerez?filter-options=games http://www.mobygames.com/developer/sheet/view/developerId,7571/

updated for latest beta: GlobalList_042517.txt

The screen is not being cleared each update. It would help if we could see the code you are using for your main loop or any script that may be drawing to the screen.

Its due to trying to Release() something twice... function Script:RemoveNums() for i = 1, #self.NumPrefabs do self.NumPrefabs:Release() end end function Script:MakeNums(num) for i = 1, #self.NumPrefabs do if self.NumPrefabs ~= nil then self.NumPrefabs:Release() end end ... ... Releasing the sprites did not make them nil. So just change the code to: function Script:RemoveNums() for i = 1, #self.NumPrefabs do self.NumPrefabs:Release() self.NumPrefabs = nil end end function Script:MakeNums(num) if self.NumPrefabs[1] ~= nil then self:RemoveNums() end ... ... ...

maybe this will help? http://www.leadwerks.com/werkspace/topic/7992-physics-oncollisionenter/#entry62987

Well it depends on how you are planning to do the blending inside your modeling app - by a fixed amount or via a mask/map. Based on the pics you posted, I would assume you will have some sort of mask/map that determines what texture is visible? If so, its a fairly straight forward shader where you draw the two textures based on the color of the mask texture. EDIT -- if doing a mask map, here is a quick version of a model shader that blends two diffuse textures based on the mask map's alpha: blend.zip

Just added the missing cubemap uniforms and code to an animated model shader and appears to work ok. Just add this as the material's shader and add a cubemap texture to the material's texture5 slot. diffuse+normal+specular+env.zip Edit- granted you could just use the normal model diffuse+normal+specular+env.shader for the material as well if the helmet is just an accessory to the animated model. If the helmet is a standalone model, you could always just parent it to the animated model's head bone.

That script posted in that blog is a WIP that is missing alot of features that its supposed to do - no check of team ID, no occlusion check, no rotating the turret... etc... Again, without an actual example or code to try, it makes it hard to troubleshoot. Edit-- I assume you are using the updated code shown here? http://www.leadwerks.com/werkspace/blog/1/entry-1673-building-turret-ai-part-2/ And if that is the case, then it performs a pick that may not see an enemy. Your example 'gif' has everything ontop of each other. Try spreading the turrets out and put the targets in the center to see if this helps your situation. Also note what Josh posted at the beginning of the blog: You may need to increase this time if you are performing so many picks.

How is the 'self.target' being set? If by pick, maybe some of the turrets do not have a target or only see a target occasionally if the pick's collisiontype is hitting the turrets? Hard to tell without actual example or code to try.

Currently you cannot get the surface of a brush (at least via lua) which means you cannot use Get/SetVertexTexCoords(). You can get the face of a brush via a pick and you can set the material but you can't set the vertex texcoords. You could try not applying script or mass to your Editor-created CSG/brushes. Then at runtime when the map is loaded, the CSG/brushes will be automatically converted to the Model class which will allow you to get the surface and set the vertex texcoords. Edit: you could change the texture scale / position through a shader

I kind of liked the random banner pictures that were made from people's games.

Scenes look great. Easily some of the best landscapes I have seen in LE. Interaction suggestions - maybe drop some hints about what to do? The ax, hammer, and saw interactions could use some visual hint on which keys/mouse buttons to use. Little clues like that can help in all the scenes - from the opening scene inside the cabin trying to understand why I cant open the door yet when its due to not picking up the bag, shoes, etc... to being the waiter trying to figure out who gets what food, etc...

The command is actually Texture::SetDetail(int quality) as shown on the second page of that first link: http://www.leadwerks.com/werkspace/topic/15206-texture-load/page__st__20#entry103547 and yes, it does work. example: window = Window:Create("texture detail example",0,0,800,600,512) context = Context:Create(window) world = World:Create() camera = Camera:Create() tex = Texture:Load("Materials/developer/bluegrid.tex") mips = tex:CountMipmaps() toggle = 1 while window:KeyDown(Key.Escape)==false do if window:Closed() then break end if window:KeyHit(Key.Space) then toggle = toggle + 1 if toggle > mips then toggle = 1 end Texture:SetDetail(toggle) end Time:Update() world:Update() world:Render() context:SetBlendMode(Blend.Alpha) context:DrawImage(tex,100,0,600,600) context:DrawText("Texture Detail: "..toggle,2,2) context:DrawText("Hit SPACE to change texture detail",2,22) context:SetBlendMode(Blend.Solid) context:Sync(true) end

Maybe, but surely any actual modeling application can create the UV's without too much difficulty? Perhaps, if its really a feature people want then maybe ask for it in the Suggestion Box forum? But I don't think the World Editor was meant to become an actual modeling application - I mention this because I have seen a post complaining about the lack of UV mapping because they were using the LE Editor to create objects to export and to be converted to B3D that had to be for something else other than LE4. Do people think that LE4 is a replacement to 3DWS? Edit- tryed out the obj fixer - works great. Create the obj asset, use the fixer, open in modeling app and create UV's for the individual meshes. Pretty straight forward.