macklebee

Just open windows explorer (assuming you are using windows), and copy the generic model and the fps script over to your blank project.

Refer to the 'Collision' section of the 'Models and Animation' tutorial: http://www.leadwerks.com/werkspace/page/tutorials/_/models-and-animation-r8#section6

LE2 had EAX effects at one time but were eventually phased out. For LE4, you would have to create the sounds with another program to played as a WAV file (which for the life of me I have not figured out why we are still having to use WAV). You can affect the sound if it is associated with a source and you change the volume or pitch.

FBX only (kind of) - http://www.leadwerks.com/werkspace/page/tutorials/_/models-and-animation-r8#section1 or if you use blender, then you can try the plugin to export directly to Leadwerk's MDL format. or if you have Ultimate Unwrap 3D, you can save as MDL as well.

You could convert it to an *.OGG video file and play the video using the LETheora scripts located here: http://www.leadwerks.com/werkspace/topic/10460-letheora-by-niosop/#entry76917 Granted this will not have sound unless you strip the sound out as well and save as *.WAV . Also, keep in mind that the LETheora scripts will only work if lua sandbox is disabled.

Actually all you did was change the interpolation value between frames and that typically is used to blend sequences from one to another or together. While this may work for what you are attempting, another way would be to not animate the bone in question. This would be determined by the skeleton hierarchy. If the bone you are wanting to manipulate is a child of another bone then just animate the parent bone and not the child by setting the recursive parameter in Entity:SetAnimationFrame() to false.

Works just fine for me. Other than the weird clamp you have on the camera rotations that prevent it from looking past certain angles, the camera only rotates based on mouse movement.

All I could suggest at this point is for you to post an actual working example of the problem so we can test for ourselves as the script you provided is not causing the issue that you are stating - at least not for me or genebris. Maybe just a simple Main.lua script with the camera script implemented in its code. Only other thing that I would have done is to use Math:Round() on the calculation on the variables 'cx' & 'cy' as this used to cause camera drifting without it in LE2 when calculating the screen center.

I have tried this and i am not experiencing the problems you are stating. For me, the camera doesn't rotate unless I move the mouse cursor.

Download shadmar's firepit from the workshop. It shows how to do this.

Listeners do not have a range, but sources do. Since currently to set a source in the editor scene you would have to script it, you could also create a sphere with its radius set by the range value. Or if Josh implements this: http://www.leadwerks.com/werkspace/topic/14667-radius-script-property-types/ then that would make it even easier.

If history repeats itself, it will be the same people that will complain about the editor crashing repeatedly due to poor programming. We had an active lua state in LE2's editor that allowed people to run scripts within the editor which opened a lot of possibilities for custom tools. But due to this ability, the editor repeatedly crashed when their object scripts would error/fail. It was not an enjoyable experience for the average user.

Post the model or all we can do is guess. But since all we can do is guess, I would say the model's key frame animations were not exported correctly so there are no animations in the MDL. Edit-- did you UV map this model? If not, try UV mapping before export, then when in LE add your animation material to that surface.

What options did you use to save? Just wondering because the alpha is there but it removed the color from the non-alpha parts when brought into the Editor as shown in the picture on the left. When I saved Josh's png using Gimp as a 32-bit A8 R8 G8 B8 bitmap, it looks like the one on the right when brought into the Editor. icon256_32bit.bmp

When you place the enemy within the editor and select it, the character should be facing the same direction as the global positive Z-axis (blue arrow). If it is not (like the crawler model), then you must set the character angle in its properties panel or via code when you load the model. If you set character angle via the properties panel then you can also set the Physics Mode to 'Character Controller', the Collision Type to 'Character', and the mass. Once you do that, then save the model as a Prefab. Then either load the prefab by placing it in the Editor's scene or by code via Prefab:Load(). Another way around that entire problem is to just load the FBX model into a modeling app or UU3D and rotate the model 180 degrees and save so it will be facing the right direction. Yes I suspect it does since the point on the entity it is looking at would be at its feet, where the character's origin is located.

Doesn't Entity:Follow() / Entity:GoToPoint() automatically point the character on its Y-axis the direction it needs to move? Why use Entity:Point() at all? Might even cause a jitter? Have not tried it but using the two commands seem like there would be a potential conflict. Edit-- or are you just using it to point the enemy at the character after it comes to rest after a Follow() as it seems to rotate the enemy away from the target?

The listener should be positioned wherever the player/camera/entity that should hear the sound is located. If you position the listener at (0,0,0), then it will report sounds based on hearing from that location

simple example that you can use to test your mono sound with: window = Window:Create("Source",0,0,400,300,16) context = Context:Create(window) world = World:Create() light = DirectionalLight:Create() camera = Camera:Create() box = Model:Box() box:SetColor(1,.5,0,1) box:SetPosition(0,0,5) sound = Sound:Load("Sound/doors/fdn_door_automatic_servo_driven_close_short_05.wav") source = Source:Create() source:SetSound(sound) sound:Release() source:SetLoopMode(true) source:SetRange(15) source:Play() toggle = 1 while window:KeyHit(Key.Escape)==false do if window:Closed() then break end box:Turn(.5,.5,0) if box:GetPosition().z > 20 then toggle = -1 elseif box:GetPosition().z < 3 then toggle = 1 end box:Translate(0,0,0.03*Time:GetSpeed()*toggle) source:SetPosition(box:GetPosition()) Time:Update() world:Update() world:Render() context:SetBlendMode(Blend.Alpha) context:DrawText("Position: "..box:GetPosition():ToString(),0,2) context:Sync(true) end It could be with the range being that high (60m) that its difficult for you to tell the difference in volume when you are 55m versus say 50m away? Whereas if the range was say only 25m, you could definitely tell the difference between 20m and 15m away. I am assuming that the volume is interpolated across the range. So moving 55m to 50m away (with 60m range) is only ~8.3% change in volume but moving 20m to 15m away (with 25m range) is a 20% change in volume. In both cases you only moved 5 meters, but had significantly different volume changes.

Camera:GetMultisampleMode() / Camera:SetMultisampleMode() World:GetLightQuality() / World:SetLightQuality() World:SetTerrainQuality() World:GetTessellationQuality() / World:SetTessellationQuality() Texture:GetAnisotropy() / Texture:SetAnisotropy() World:GetWaterQuality() / World:SetWaterQuality() Texture:GetTrilinearFilterMode() / Texture:SetTrilinearFilterMode() Camera:GetHDRMode() / Camera:SetHDRMode()

No, it is not resolved just yet: http://www.leadwerks.com/werkspace/topic/14362-cylinder-and-cones-not-loading-materials/#entry98429 Box and sphere in lua appear to work fine - cylinder and cone do not.

Works ok for me. Prints out -1. Granted I wouldn't use a pick with a radius as its not a precise pick, but it works in my test of the scripts. Keep in mind, you are setting the pick radius to be 0.5 meters. My suggestion would be to use System:Print()'s in your multiple if-statements to find where it is failing to get to the Print you want to see and to not use spherical picks, especially on small objects.

Simple example showing your supported resolutions: rescounter = System:CountGraphicsModes()-1 resolutions = {} for i = 0, rescounter do resolutions = System:GetGraphicsMode(i) System:Print("Resolution "..i..": "..resolutions.x.." x "..resolutions.y) end window = Window:Create("Supported Resolutions", 0,0,resolutions[rescounter].x,resolutions[rescounter].y,16) context = Context:Create(window) while window:KeyDown(Key.Escape)==false do context:SetColor(0,0,0) context:Clear() context:SetBlendMode(Blend.Alpha) for i = 0, rescounter do context:SetColor(1,0,0) context:DrawRect(0,0,resolutions.x, resolutions.y,1) context:SetColor(1,1,1) context:DrawText(resolutions.x.." x "..resolutions.y, resolutions.x-75, resolutions.y-15) end context:SetBlendMode(Blend.Solid) context:Sync(true) end

If I had to guess, I would say its not exposed or did not exist with the version of Leadwerks that the Game Launcher executable is using because it doesn't recognize it as a Leadwerks command. Just tested it in the editor, as a standalone, and in the Game Launcher. Only place it doesn't work is the Game Launcher. Again, not documented, so not supported and could go bye-bye at any time. Granted I would definitely prefer these to be supported.

I didn't see that he had posted a downloadable example, so I was going by the code he posted. But yes, if world was global in the main script, it should be useable elsewhere. Actually they are - that's how I found them by performing a class dump of '_G'. Now whether or not they work properly is another discussion. I have not had an opportunity to test. Since they are undocumented, they may not work or could be removed at any time.

Agree with your solution completely, except there are World:GetSkybox() and World:SetSkybox() commands. As with anything that is not in the official documentation though, it does not mean they work, or are supported, or could not disappear at any time. Honestly, I would have preferred that the skybox was set through World commands as it easier to just perform a World:GetCurrent() instead of cycling through the world's entities looking for your main camera. Edit-- Now looking back at his code, I wonder if his 'world' is properly defined. He just has 'world:SetSkybox(self.skybox)' inside a Script function, but he doesn't show if he defined 'world' anywhere in this separate script. Perhaps a 'world = World:GetCurrent()' would solve his issue, assuming its still not an issue with undocumented commands sometimes not actually working.