Josh

We're having problems with the host cutting off downloads: http://leadwerks.com/werkspace/index.php?/topic/2065-lesdk-232-r5-link/

To do that properly, we really need 3.0. The goal with LE2 is to provide the commands you need to write a game. If we take it further than that, there will be problems. I learned from when I used to provide a more complicated FPS script that any code I release tends to get treated as final game stuff, when I just intended it as an example of what you might do. If I were to make a more complete game example, the next step would be feature requests for everything to be added to that example. I also don't think it would gt modified much, so it wouldn't be that useful to many people. When we're dealing with really high-level game behavior, the ability to exchange and share code becomes important. We've made a lot of progress in that direction with Lua, but I think Rick's idea about attaching multiple scripts to entities will really finish that off, along with the flow graph editor. We'll provide a framework of interactions you can work within, so it will be easier for people to write and share code.

One of the things I like about this community is it is very positive, and criticism is almost always constructive. Please be nice to each other. I understand there are some frustrations right now, but let's not let that make us lose our cool.

You're probably right about that.

Theoretically, this should not occur with swept collisions, but I wouldn't be surprised if there was a way for it to happen. If you want to produce an example I can show it to Julio. I often see this sort of thing occur in FPS games. I saw a video on YouTube yesterday where a gun fell through the floor. That's a smart approach.

I've been working on it, and just had to make the versions with alpha channels. There's a dark edge on the bottom of the light version; not sure if I like it, or if it looks like an error.

It's just the way the graphics card works. It is using whatever texture is left in that slot.

Here you go: http://leadwerks.com/werkspace/index.php?/files/file/148-leadwerks-logo-kit/

File Name: Leadwerks Logo Kit File Submitter: Josh File Submitted: 30 May 2010 File Category: Materials Resolution: 64x64 License: Use freely. High-resolution Leadwerks logos. Click here to download this file

I have no plans right now to implement destructable physics. I think stability is more important right now than adding more features. I don't know what the parameters of the .phy format in v3.0 will be, since it is pretty far away. It will probably be more a matter of creating the shape in the editor with adjustable parameters, or converting an .obj or .gmf in the editor to a .phy file. It will be easy. Enabling swept collisions is the way to deal with this. I agree. It sucks to change code. I figured having the engine call two script functions would ultimately lead to more confusion and potential problems than just renaming it. I also thought the Draw() function wasn't used that frequently. Sorry for the inconvenience.

So this is not a problem?

There were numerous small issues related to the 2.32 release, but I am chipping away at them: http://leadwerks.com/werkspace/index.php?app=tracker&showproject=1&catfilter=2 I'm not going to add any new features until every bug is fixed. Remember that the more complete and easy to reproduce a report is, the faster it will be to fix. Thanks for the feedback!

Probably the biggest inconvenience we have had was caused by relying on the serialized physics files that change format occasionally. Newton 2.20 is stable and supports everything I want, so I don't see any reason to upgrade if a newer version comes out. In version 3.0 we will have our own .phy format that doesn't change, and I don't plan on upgrading to any new versions of Newton for LE 2.x. There are only three open issues in the bug tracker right now, BTW.

What API changes have their been in the last 6 months? Entity view range changed, because the new system allows much greater distance culling optimization. The sky background color started affecting the sky in 2.32, so you can adjust the background to make day/night changes. The "Render" script function was renamed to "Draw" to match the internal functions, again a consequence of the scenegraph system (cameras have a Render() method, and all entities have a Draw() method, so you can see why this is). It's always hard to make a decision that effects existing code, but these had some significant benefits, so it was deemed worthwhile. The internal optimizations in 2.32 have made it a difficult release, so you may want to stick with 2.31 a while longer. The end result will be much better for your games, which is what I care about most. I can understand if you would feel disoriented at first, especially when 2.32 was first released with some bad bugs that had to be fixed. For the rest of 2.x, all I have planned is bug fixes and minor feature additions. Once all bugs in the tracker are resolved, I consider 2.x finished, and any features on top of that are just icing.

I knew focusing on the internal scene management was going to produce some temporary bugs with no immediate visible gain for most users, but I did it anyways because it will allow your games to run a lot better when they get big and complex. The improvements made in 2.32 are expressly for the purpose of allowing better published games. Version 2.x is not being dropped or discontinued. I just spent three months on stuff that ensures you can make large games with 2.x. I spend about one weekend a months twiddling around with version 3.0 code, and I am asking for input well in advance so I can have it available when I am ready to start.

+1 I also think an editable hierarchy (just for organization) and checkboxes would help.

Yeah, you can actually just edit the script to raise it. The only reason is it limited is that if you make the numbers too high, the slider gets hard to use.

The only difference is the amplitude and texture scaling of the effect. The second shot uses a different texture for the water normal.

There's nothing wrong with the refraction effect. If you want it to be different than it is now, you need to edit the shader yourself. It isn't hard to change the amplitude of the refraction and the scale of the refraction texture mapping, but it's your responsibility to change if you want the look to be different. I can't say when 3.0 will be available because I don't know when production will start, because there are factors outside my control.

Tessellation makes so much sense for waves. I know a way to get really fast high-quality waves, but we're going to have to find some company that writes fluid simulations and have them make the data for us.

Is the second image a photo or an in-game shot?

No. 3D waves will be implemented in version 3, using hardware tesselation.

Turn off SSAO and godrays.

I'm not sure why people think Leadwerks 3.0 will only be programmatic or point and click. It won't be just me working on it. I will probably end up writing very little of the code, and spend most of my time instead documenting how I want the programmers to write it. When you see how it works, I think you will understand how the programming, script, and design mode work together. There's the step of programming game behavior, but there is also game production, where you are setting up interactions that are unique to one level. That's a stage we haven't really gotten to, and this will make it easier to achieve that, without taking away your freedom to focus on more basic aspects.

At that point, I would probably assume you are a competent programmer, and are able to copy and paste code. The whole point of multiple scripts is for people who aren't able to understand what a block of code is doing, and copy and paste it without causing a problem. To you and me this may seem completely trivial, but if you think about the last time you looked at a wall of incomprehensible code, it makes sense. Not saying Rick is in this boat. I think he has seen systems like this in action, and they probably are fun and nice to work with. So basically this moves the burden of using copy and paste from the novice to the expert. I don't really see this script system working with class hierarchies, and I think that is okay. AI is probably the only real use of hierarchical classes I would use, and how hard is to make some basic AI functions and call them from another script? Traditional object-oriented programming is great for a game engine, but I think it breaks down in higher game logic design, and becomes more trouble than it's worth. You can get the same benefits without making derived classes.