macklebee

this seems to work ok: mymodel = Model:Load("Models/crates/crate_large.mdl") model = {} mat = {} mat[0] = Material:Load("materials/developer/bluegrid.mat") mat[1] = Material:Load("materials/developer/greengrid.mat") mat[2] = Material:Load("materials/developer/greygrid.mat") for i = 0,2 do model[i] = mymodel:Copy() model[i]:SetPosition(1+i,0,0) model[i]:SetMaterial(mat[i]) end and this way as well: mymodel = Model:Load("Models/crates/crate_large.mdl") material = mymodel:GetSurface(0):GetMaterial() model = {} mat = {} tex = {} tex[0] = Texture:Load("materials/developer/bluegrid.tex") tex[1] = Texture:Load("materials/developer/greengrid.tex") tex[2] = Texture:Load("materials/developer/greygrid.tex") for i = 0,2 do model[i] = mymodel:Copy() model[i]:SetPosition(1+i,0,0) mat[i] = tolua.cast(material:Copy(), "Material") mat[i]:SetTexture(tex[i]) model[i]:SetMaterial(mat[i]) end

not sure why adding a script to a model would have made any difference - but with the CSG primitives, if it has mass or a script then it isn't collapsed into the scene when loaded in your game.

hmmm the problem there is probably due to the fact that the material itself is not an individual copy... you have the same material being applied to all the copied bricks, so just changing the texture would just apply the last texture change to the same material thats being used on everything. This should work if you apply different materials to each model copy. Or create your own material via code and then make an individual copy of it to be applied to each individual brick that you want to have a certain texture.

yeah that seems to be the issue. I added mass to some of the csg primitives and now they only change material by themselves. I assume adding an empty script will do the same. Edit-- yes, adding an empty script or mass will prevent this issue with CSG objects.

Well, thats what he is showing in his second code example. It works in lua so it should work in c++. The only suggestion would be to try to create the copy from the original loaded model reference instead to see if it makes a difference. model1 = Model:Load("Models/brick.mdl") model2 = model1:Copy() model2:SetPosition(1,0,1)

The only thing i could suggest is to remove the doors and place it back it the scene between saves. Then try re-attaching the script to make sure the 'manual activate' was not enabled on the door.

hmmm thats weird... it does seem to be random on which ones it picks - but it consistently picks the same ones to change. At first i thought it had something to do with which material was used during its creation but that doesn't seem to be the case.

The pictures posted don't match what the video shows is weird. The video shows the hand icon on the "door" as well as the controlpanel. The hand icon is enabled by the "Manual activate" being true which in this case I would assume you wouldn't want on the doors. Is the video from playing via the editor or from a published/exported game? Asking because it looks like the map in the editor is not what is being shown in the video - unless you have changed the default scripts. Also, it would probably be helpful to see the flowgraph logic between the controlpanel and the door.

Some of this I am sure is the results of avoiding , but what is interesting is that it doesn't cause the reverse rotation if you use local coordinates in SetRotation(). That in itself seems weird to me because I thought LE3 was the same as LE2 in regards to if an object doesn't have a parent then local = global. Perhaps the problem is due to all the objects are now a child of the scene root in LE3? But in any case, to see the effects of avoiding gimbal lock, rotate the model in 'local' coordinates and show the rotation value you are setting versus the actual entity's rotation. When rotating just the X-axis, the Y&Z will need to auto adjust from -180 to -0/+0 to +180 to avoid gimbal lock. When rotating on just the Y or Z axis, the other axis only need to change from a +0 to -0 to avoid gimbal lock. I assume its due to the order in which eular rotations are being applied. function Script:UpdateWorld() self.rot = self.rot + 1 if self.rot == 360 then self.rot = 0 end self.entity:SetRotation(self.rot,0,0) end function Script:PostRender(context) context:SetBlendMode(Blend.Alpha) context:DrawText("self.rot: "..self.rot, 0, 450) context:DrawText("entity rot: "..self.entity:GetRotation(true):ToString(), 0, 470) context:SetBlendMode(Blend.Solid) end

1) cant comment since i dont use it 2) for counting number of graphic modes: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/system/systemcountgraphicsmodes-r857 for returning the graphic modes based on count: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/system/systemgetgraphicsmode-r858

Playing around with a script that allows the user to pick a color from the object panel to be used with a shader. Setting the initial value of the color works as expected and fills out the property panel correctly: Script.MyColor = Vec4(1,0,0,1)--Color "MyColor" But if the color property is modified via the panel, then it will return a number based on the 0-255 scale which will fail in the shader. In an attempt to work around this, I changed my initial value to: Script.MyColor = Vec4(255,0,0,255)--Color "MyColor" which results in this: which gives weird property panel results and still would be unuseable in my shader without dividing each component by 255. Since I have no viable method to determine if the color is being set by default or by the color picker, the returned color needs to be on a 0-1 scale to work properly. example script: Script.MyColor = Vec4(1,0,0,1)--Color "MyColor" function Script:Start() local color = self.MyColor System:Print(color.r..", "..color.g..", "..color.b..", "..color.a) self.entity:SetColor(color) end

Marley and I played around with this in LE2... there are probably several other and more efficient ways to do it, but the two methods we used were: 1) multiple images of the circle/segments and draw as needed based on health/mana level 2) sphere mesh drawn in ortho mode in other buffer with a shader than only applied the texture based on level (y-axis) looking back now i suppose you could get the similar results by just drawing the circle on a quad and then just use a similar shader to control how much in the y-axis to draw

you have to make sure you use proper capitalization with lua commands... so its not: entity:setPosition(spawnPos) is should be: entity:SetPosition(spawnPos) edit: yes, rick beat me to it Also, if you are using the internal script editor for your lua scripts, then LE commands will be blue when spelled correctly:

http://www.leadwerks.com/werkspace/page/tutorials/_/script/

This looks like the issue is due to at what point the physics take over. By using the editor to place prefabs, you are setting the position of the prefab and its children before the App loop (physics updates/rendering) occurs. When you load a prefab via code in the update loop and the prefab's child object has mass, then physics/gravity immediately takes over the positioning of the child - using the initial position from the prefab load to start from. Physics will break the positional relationship between the parent and child. Whether or not this is intentional in this case of loading a prefab, it follows with how it works in the rest of the engine. Two ways I see around it until Josh does something about it (assuming he sees it as an unintentional effect and makes it more newb/beginner friendly): 1) Add mass to the prefab and children after it is loaded/position is set or 2) Set the position of the prefab and the children components

hmmm i think there is a mixup somewhere... you are loading the 'dwarfmale_run' model but you are trying to find the 'dwarfmale_stand_bone'. In the model you posted there are no 'stand_bones' - only 'run_bones'. I am able to find the 'run_bone' no problem... I think you are just loading the wrong version of the dwarf in the editor to find the bone you want, but then are loading a different dwarf model via code that doesn't have that naming convention - therefore its not finding the bone...

Is this a problem with prefabs or models? or models/prefabs with mass/physics? I am curious because I have been parenting items through code/editor and I am not experiencing the same problems.

We would probably need to see your code/model as I just renamed the hand bone on my model to 'dwarfmale_stand_bone_RFingerPinky" and was able to find it and parent a weapon to it with no issues. I suspect maybe a typo somewhere or since maybe 'child' is a local variable, you are trying to access it out of scope? Edit -- and fyi, it appears you have to match capitalization... so make sure the string matches exactly as shown for the bone name.

The default scene name for a model has always been the internal top mesh name (by conversion or user-defined) and is not the name of the file. The merits of that can be debated, but since you have the ability to rename each part of the hierarchy I don't understand how you are considering this a bug in this report or your other report of similar topic.

The picture on the left shows that you named the model when you had the model and all of its hierarchy selected. The General tab's name property would have shown as '<different>' prior to you renaming. Writing over this will rename the model and every child component selected in the scene. The picture on the right shows that you hadn't pressed 'enter' yet after renaming the selected item. Also clicking onto another item in the scene browser will perform the same function as pressing enter.

post the material file for the smoke - suspect it doesn't have z-sort and/or depth testing enabled.

it can be done via Model:GetSurface() and Surface:SetVertexPosition() but may be easier to just do it via an animation also look at the code example here: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/model/modelcreate-r351

in the lua math module, its lower case: z = math.random(-10,10) but this will have the same effect as you are getting now that it returns the same number. To vary the returned number, use the random seed: math.randomseed(Time:Millisecs()) z = math.random(-10,10) see here for more details: http://www.lua.org/manual/5.1/manual.html#5.6 Edit- hankinator beat me to it

I see a couple of spots after i had recalculated the normals and turned the 'castshadows' on - and yes it does look like z-fighting in those areas. Without a fbx file though I cannot tell if there are actually multiple faces laying on top of each other. But within the model editor, I do see a couple of errant faces with normals flipped or just serve no purpose that I can see in other places on the model.

creating and adding a normal map to the layer makes those go away