macklebee

Alpha curve slider works just fine for me. copied particle with only difference made on alpha curve

Would be hard to say without the model and textures. I would try looking at the diffuse and normal maps first - try them without mipmaps, uncompressed, different filter modes, etc...

http://www.leadwerks.com/werkspace/topic/11744-defining-new-collision-constantstypes/#entry84834

That code just calculates the Y rotation needed to make an entity face another entity based on their respective positions without regards to any differences in height. There is no angle for X. I guess you technically could do the math based on the entities' Y-positions to determine the X/Z angles. But if you need to rotate on multiple axis, then using the Entity:Point() command would be easier.

the specs on that card say it supports up to 24xMSAA... it might be worth removing all of the post effects and see if this still occurs.

It seems to work ok once I added an animated shader material to the Surface 0 - but its hard to tell since I have no idea what it is supposed to look like. The girl was already animated even without any textures and the briefcase/laptop(?) was animated once I added a material that had an animated shader.

Well the workaround for the scaling of models and the effects on its children can be solved by scaling the model to its proper size using a modeling app before bringing it into LE. Then the scale applied in LE will be (1,1,1). If you use the LE model editor to scale then you have to be aware of the scaling effect on any child's local position, which can be worked around by getting the global position instead. Edit -- And thinking about it, the initial code above was essentially doing that but in a convoluted way. It was finding the child's local position (assuming the parent scale was 1,1,1) and adding the local (global) position of the parent... which is the same as just finding the global position of the child.

Yes that is correct. But I prefer to think of it as the global just for making it simpler to think of the position in the overall context of the scene. But it probably is a local position based on the root just being at (0,0,0) of the world. But it begs the question why there is a button to toggle between global and local coordinates in the editor if this is the case. The problem that you will run into is between local/global rotation for standalone objects. These are not the same - or I should say will not return the same values. There is a recent bug report about this which mirrors the same question I asked about LE2 several years ago. This has been an ongoing issue in LE for as long as I can remember.

Except thats not how it works. Just the simple character controller's collision type will cause a collision response with any scene collision type (like terrain), just like nick is referring to. There will be items in the scene that will not have a name key that will cause a collision response based on the collision type assigned. The only suggestion would be to first perform a check to see if the entity has a name then perform the rest of your code.

that big GDC download of audio files that Josh had posted in his status had some animal sounds for a dog/pig/deer... you could try that and see if you like http://sonniss.com/GameAudioGDC.torrent

I expect to see a huge increase of downloads for your game Hayden. It will be interesting to see the exposure it gets from this.

Just pointing out that all the LE color features (SetColor, shaders, and even setting the color picker property) use the 0-1 scale except for the color picker's returned values. For consistency and to avoid problems as pointed out above, the color picker should return values scaled 0-1 instead of 0-255.

Something that at least would be useful for me is for the 'edit' button on an object's script property tab to also be able to create a new script or load a template if it is empty. I am constantly writing test code for objects and it requires me to either go back to the assets tab to create the new script or load an existing script and then save it as something else... then go back to the scene tab and that object's script tab to attach/edit the new script i just saved... etc... lots of unnecessary clicks.

no screenshot attached... but just a simple example: - Create the sphere and give it this for physics properties - Create a script and add the following code to it Script.camera = "" --entity "Camera" function Script:UpdateWorld() local window = Window:GetCurrent() if window:KeyDown(Key.W) then self.entity:AddForce(0,0,10,true) end if window:KeyDown(Key.S) then self.entity:AddForce(0,0,-10,true) end if window:KeyDown(Key.A) then self.entity:AddForce(-10,0,0,true) end if window:KeyDown(Key.D) then self.entity:AddForce(10,0,0,true) end self.camera:SetPosition(self.entity:GetPosition(true) + Vec3(0,1,-2)) end -Attach the script to the sphere -Drag the scene's camera into the sphere's script 'camera' textbox as shown in image above

Yes it appears the scaling of the model is affecting the child's returned local position. You can see the results of it by looking at each of the pivot's General tab position property (at least in the beta). I would call this a bug. You can get around this by changing the code to find the global position of just the pivots themselves. self.patrol[0]=self.entity:FindChild("Pivot0"):GetPosition(true) self.patrol[1]=self.entity:FindChild("Pivot1"):GetPosition(true) self.patrol[2]=self.entity:FindChild("Pivot2"):GetPosition(true) Edit -- Josh pointed out that a child's position would have to take into account the parent's scale to be placed properly. so if the parent is scaled then the child's local position values will be affected by this- so its probably safer to just use the global position like in the above code to avoid any scaling issues. Something to note that i never realized the editor was doing - the position shown in the general tab for a child entity is shown as the local position and not the global position like all parent or standalone objects,

That is caused by the fact that the script is trying to run the "Attack1" animation and your animation is named "Attack 1". So it doesn't find the animation and just hangs. Also the default script will randomly choose between multiple attacks, so rename all of the attack animations as "Attack1", "Attack2", etc... This updated script that uses the sequence name is a great improvement over the previous one that used the sequence number in my opinion because I think this makes it obvious what animation you are trying to set, but perhaps the default script needs a way to perform a check to see if the animation actually exists prior to setting it.

well my initial guess is that the calculated position of the Pivot#+entity position is not reachable via the navmesh or all 3 calculated positions are less than 1 meter away so it will just constantly cycle through the waypoints without ever moving.

you are going to have to provide the map and character you are trying to use this script with - because we can't tell where the 'Pivot#' + the entity's position is located.

Yes, repeatedly, by doing the above steps. First you have to narrow down the actual problem. Is it an animation or navigation problem? The default monsterAI script handles both but they are separate issues. If you have done everything as mentioned above then you need to provide the actual character and/or map for people to look at or we are all just guessing at what the issue could be.

Looking at the picture, he has renamed the animations to Run/Idle/Death - but the attack animations are named 'Attack 1' whereas the crawler's attack animations are named like 'Attack1' without the space. Looking at the video, he has built a navmesh or the crawler would have never tracked him down. Animation has nothing to do with navmesh navigating. There are several things that have to be performed to make sure the character can navigate through the scene. So a couple of things that need to be set up: Character's Physics property tab: - The Physics Mode needs to be Character Controller. - The Mass has to be greater than 0. - Also, make sure the character is pointing the right direction - need to be facing the model's +Z direction. Use the Character Angle to make adjustments if this is not the case. If character is faced the wrong direction, it will chase backwards and sometimes not react until you are behind the character. Without seeing a picture of your Physics tab I can't say which one you didn't do. Other than that, you also have to make sure that the character is actually on the navmesh. Without a screenshot with the navmesh visible, I can't tell but the character is placed close to the edge of the ground box. When a navmesh is built, there will be a deadband around the edges of the ground. If the character is not located in the navmesh then it will not move. And just a comment on the animations shown in that picture: Remove the first animation that you extracted all of the other animations from. This will cut that model's file size by half and its not really needed anymore if you are going to use the extracted named sequences.

I think thats the requirement though - background to be white if using the shade blend and you cant use the start/end color options because it will affect the white background. if using the alpha blend then you can use the start/end color options, as the color doesn't effect alpha. Same can be done with the light blend as the background would be all black and wont be affected by color changes as shown in shadmars post's example. Seems to be a matter of just picking which blend is best for you based on what your texture looks like.

Why would adding a script effect this - at least based on OP's last post? havent tried it yet myself.

yep - was that way in LE2 as well. Also, the global flag set to true for entity:GetRotation() will return an angle based on a flipped sign.

Yes, it appears that Entity:GetMaterial() only works if the material has been set via code with Entity:SetMaterial(). If not set via code, then Model:GetSurface(index):GetMaterial() has to be used.

I agree it seems confusing as it was something that stymied me on LE2 at one time as well. What I was alluding to above but somehow forgot to point out directly, was to use the local coordinates for setting and getting the rotation. This way when you set a rotation to (100,0,0), then the local 'get' will return (100,0,0) whereas the global 'get' will return (80,-0,0). Why the global cannot return in the same format - I do not know but the same situation existed in LE2.