macklebee

slimwaffle - is this resolved or are you still having issues getting a terrain to deform? If so, post your example so we can try to replicate the issue. It's called being friendly. - macklebee

The advice that was given was that models can be converted to other formats and ways to do conversions when my only concern was that I didn't want to waste time doing conversions? Like I said, Josh answered my question from his very first reply - it was all good from there. And actually that "couple of years" is over 15 years closer to 20, but just as tinkerer/hobbyist, but thanks for being a arrogant, *******, ******, ***************.about your credentials. Glad to have you here. Artists of your experience and skill level are few and far between around these parts as most do not want to program. You are a breathe of fresh air. We look forward to your input on all things artistry related. Anyways - I cannot wait to use the new format. It sounds really cool and I think it will be a great addition to LE in the future as I hear it can let you export an entire scene (geometry, materials - including full PBR support, animations, and more) in one shot. Neat-O! The Windows 10 built-in model viewer sounds promising as its one of those things you don't realize that's been missing from your life until you hear about it! Love you all as well, It's called being friendly. - macklebee

Doing some LE VR promotions?

Sorry to hear that you had issues when you updated to the beta. It was my understanding that the first time that you installed Leadwerks that it should have installed all the files you needed, including the VC++ redistributable? So I am surprised this is the first that this has come up since you have been using LE for some time now. Did you perhaps delete and re-install LE recently? If so, maybe the redistributable did not install properly during that time? This does apparently happen from time to time according to the posts I see on the Steam forum. As for the screen issues, hopefully Josh will be able to replicate the problem so he can resolve it. Being over seas away from his main development equipment sometimes makes it hard to troubleshoot. "It's called being friendly. " - macklebee

Thanks - I didn't know what the word "batch" meant! jeebus... That's fine and dandy - and if it comes to it, it's definitely something that i will try even though I think I would look for some commandline batch converter instead of trying to load thousands of assets into a blender scene. And speaking of key words, you are missing the key point repeated in all my posts: The only concern was having to spend a lot of time converting assets that currently work in LE to another format to work in the newer version of LE - not that I didn't know how to do conversions. And Josh answered exactly what I had hoped. That's all that I needed to hear. No alternatives were requested and none needed at the moment, but thank you. But let's point out that all I requested was that some other format still be provided due to not wanting to spend time doing conversions (been there and done that) and then you decided to give a dissertation or sales pitch for this format when it wasn't requested or required. I have been playing around with game engines and 3d models for at least a couple of years, so I don't need an explanation that models can be converted from format to format. But thank you for your input. But knowing Josh, I wouldn't be surprised to see him make this upcoming gtfo format be obtainable by auto-conversion when the editor is opened. Since you are relatively new here, I will share a little Leadwerks history with you. One of the biggest hurdles new people had when first using LE2 was getting assets converted properly over. We had several commandline model converters for OBJ, FBX, 3DW, DAE, (and UU3D's converter), commandline texture converters for TGA and DDS, and a commandline converter for creating physic bodies, PHY. Josh finally fixed this by narrowing down his allowable formats and by automating the conversion process when the editor is opened. The amount of newbie posts about conversion questions/problems was halved immediately due to this, so I suspect something similar will be implemented or we will be reliving LE2 all over again. While you think this new format is hot and you want to date it, the simple fact is that new people (and old people) will complain about having to use a 3rd party software to get their models into LE. That was one of the old complaints about having to use UU3D or having to use blender for the GMF export. FBX is a hot mess but unfortunately its the most common format available. Until such time that the gtfo format becomes more common, considerations should be made for the old standards.

Or you know, I don't have to do anything because Josh is for the time being supporting other formats... and honestly, that doesn't sound very feasible at all. Trying to navigate a scene with hundreds or thousands of models to determine what to export, not to mention it doesn't sound very practical from a memory / file size standpoint, but to each his own. Still it would be time consuming endeavor to setup which was why I asked Josh about supporting other formats and he said he was going to...

Yeah, man I know that you can convert models from one format to the other. I get it. I've done it. I will do it again in the future. The angst is not wanting to spend the enormous amount of time trying to convert a decades worth of files over to this format, if Josh decided to only support this format. Since Josh has stated he will be supporting other formats at least for the time being, I am satisfied. As it stands right now, essentially 90% of my assets are automatically accepted by LE by just simply starting the editor - that alone is an enormous benefit to any user.

jeez dude... i hope they are paying you for this... I get it - you are a fan of this new format. The conversation was directed at Josh and he answered exactly what I wanted to hear. It's all good. We are both getting what we want.

ooph - you don't have the source! that blows donkeys. Great that you are looking into new and exciting things - no complaints here about that. I just wasn't looking forward to having a decades worth of a models and textures asset catalog basically become useless in LE unless I convert it over to this gtfo format.

Just as long as you keep some other format import options available other than this random GTFO format that until posted here most of us have never heard of - including yourself.

hmmm. This still seems to be saving the same way as the Editor does where it overwrites the existing mipmaps. I am not seeing a difference when viewing with the above program. The second mipmap should look like this:

Just a quick and dirty script to view the mipmaps saved inside a TEX file: window = Window:Create("texture detail example",0,0,800,600,Window.Titlebar+Window.Center) context = Context:Create(window) world = World:Create() camera = Camera:Create() tex = Texture:Load("Materials/beach_dirt_b.tex") mips = tex:CountMipmaps() while window:KeyDown(Key.Escape)==false do if window:Closed() then break end Time:Update() world:Update() world:Render() context:SetBlendMode(Blend.Alpha) for i = 0, mips-1 do Texture:SetDetail(i+1) if i <= 4 then context:DrawImage(tex,155*i,150,150,150) else context:DrawImage(tex,155*(i-5),305,150,150) end end context:DrawText("Number of Mipmaps: "..mips,2,2) context:SetBlendMode(Blend.Solid) context:Sync(true) end

I wonder if its due to the default settings for the editor when converting an image to TEX that it automatically saves it as DXT1 and with the 'Generate Mipmaps' option selected? Is it overwriting your mipmaps because of this? These have always been settings i wish we had control over instead of them just being hard-written as the defaults.

Did you try my example? Does it work for you? You are not giving us enough information to determine if its something you are doing wrong or its a problem with LE. What version are you using? Give us a simple example to try. And again, the height value is on scale of 0 to 1. This simple example works for me: window = Window:Create("terrain example",0,0,800,600,Window.Titlebar+Window.Center) context = Context:Create(window) world = World:Create() camera = Camera:Create() camera:SetPosition(0,30,-30) camera:SetRotation(45,0,0) camera:SetMultisampleMode(8) light = DirectionalLight:Create() light:SetRotation(35,35,0) terrain = Terrain:Create(64,true) terrain:SetLayerTexture(0, Texture:Load("Materials/Developer/Bluegrid.tex"), 0) terrain:SetScale(1,10,1) math.randomseed(Time:Millisecs()) while window:KeyDown(Key.Escape)==false do if window:Closed() then break end if window:KeyHit(Key.Space) then terrain:SetHeight(math.random(0,64),math.random(0,64),1) terrain:UpdateNormals() end Time:Update() world:Update() world:Render() context:SetBlendMode(Blend.Alpha) context:DrawText("Press SPACE to raise a random terrain point",2,2) context:SetBlendMode(Blend.Solid) context:Sync(true) end

The height value in SetHeight() is normalized from 0 to 1 where 1 is equal to the max altitude of the terrain. Altitude of the terrain is set by SetScale() via code or via the Editor terrain settings, so you would need to normalize the height you want in regards to the max altitude being equal to 1. Another thing to keep in mind: a terrain position is not the same as the world position. For example: on a 64m x 64m terrain, the world origin (0,0,0) would be located at X=32 & Z =32 on a flat terrain when using SetHeight(). Example showing SetHeight() in action: window = Window:Create("terrain example",0,0,800,600,Window.Titlebar+Window.Center) context = Context:Create(window) world = World:Create() camera = Camera:Create() camera:SetPosition(0,5,-5) camera:SetMultisampleMode(8) skybox = Texture:Load("Materials/Sky/skybox_texture.tex") camera:SetSkybox(skybox) light = DirectionalLight:Create() light:SetRotation(35,35,0) terrain = Terrain:Create(64,true) terrain:SetLayerTexture(0, Texture:Load("Materials/Developer/Bluegrid.tex"), 0) terrain:SetScale(1,100,1) ball = Model:Sphere(32) ballmat = Material:Load("Materials/Developer/Orangegrid.mat") ball:SetMaterial(ballmat) ball:SetScale(4,4,4) shape = Shape:Sphere(0,0,0, 0,0,0, 1,1,1) ball:SetShape(shape) shape:Release() ball:SetCollisionType(Collision.Prop) ball:SetSweptCollisionMode(true) ball:SetPosition(24,6,0) ball:SetMass(1) camera:Point(ball) while window:KeyDown(Key.Escape)==false do if window:Closed() then break end pos = ball:GetPosition(true) camera:SetPosition(pos.x,6,pos.z-10) camera:Point(ball) if terrain~=nil then for x = 0, 64 do local y = Time:Millisecs()/600 for z = 0, 64 do local height = math.sin(y+x) / 40 terrain:SetHeight(x,z,height) end end terrain:UpdateNormals() end Time:Update() world:Update() world:Render() context:Sync(true) end

Without seeing this in action and the rest of your code, its hard to tell what exactly the issue could be. Why are you aligning the entity by 90 degrees in the X-axis as well? Seems like what you are trying to achieve based on your description could be solved just by setting the 'self.otherEntity' rotation by using SetRotation()? But again, just a guess since no example to test.

weird. yes no one is going to do a direct export to xbox with LE. This would require your code to be engine independent and that all your assets are of a common format and not just LE formats. Even then the licensing and the game developer kit itself has always been restrictive. Great that you have these dreams, but you should probably focus on just getting something first that works on a pc before worrying about publishing.

At this point, I think its the code the OP isn't showing us that is the problem or at least maybe how the pick is working for camera collision. The code he posted doesn't do anything but set the camera at the 'chassis' position and allows the user to rotate the camera.That code does not point the camera at the car, it does not automatically move the camera if behind a wall, and it doesn't allow the user to move the camera closer or farther away from the 'chassis' like what is shown in his videos. The jitter, since he is making us guess, is probably due to the pick hitting the wheels briefly instead of the chassis causing the camera to move slightly. So it's probably more of collision type setup issue more than anything where the camera pick needs to ignore the wheels.

Yes, the LE API is for LE commands. And yes, potentially (depending on the script and its function) you could adapt other lua scripts into a LE lua script.

The only lua commands that will only work in LE are the LE API commands listed in the API Reference and obviously the Script class that is available for LE scripts. Actual inherent lua commands can be used wherever lua is used (with obvious considerations given to the different versions over the years). Refer to actual lua programming sites for reference: http://pgl.yoyo.org/luai/i/_ http://lua-users.org/wiki/TutorialDirectory http://www.lua.org/pil/contents.html

Impossible. In your videos, the camera is changing positions if behind walls and is allowing you to move the camera close and away from the vehicle. The code you posted only allows the user to change the rotation of the camera and not the position. EDIT - you can make as many videos as you want, but without an example we cannot troubleshoot your issue.

Thanks - but I think Marcousik has that file. I am looking for the script and now i cannot find it either. Oh well, I think the bigger issue above is that it appears the OP has two sets of code setting the camera position and possibly fighting each other. Or at least the collision code and however the pick properties are set is causing it to bounce position.

There's been a lot of iterations apparently. I was going to use the 3rdPersonFollow script as an example that has similar code but that's no longer supplied with the software.

You need to interpolate the camera's position to the next position over time or you will get quick jumps like that in movement. Use the Math:Curve() to smoothly transition between positions. Now if some of the jerkiness is due to the pivot bouncing with the stuttering vehicle joints, that might be another problem. EDIT--Also - it appears you have implemented some sort of camera collision/pick which is not a part of the code you posted above that is moving the camera as well. If this is the case, then you need to show that code as well or even better post an example that shows the problem. If you have the code above and some sort of camera collision code setting the position of the camera as well, I can see the two causing a jittery effect as they work against each other.