Josh

I thought it seemed sort of redundant when you have the member itself to access.

This is a good idea to keep in mind, especially with something like software development: "Don't judge each day by the harvest you reap but by the seeds that you plant." -Robert Louis Stevenson

That's true.

Thanks for making this. I added it to the sync folder.

Right.

Okay, there is a confirmed bug where the roads don't construct properly when meters per tile is other than the default value. The number 2 is probably hard-coded in the script somewhere, so I will find it.

How do I produce this result?

http://leadwerks.com/engine_tutorials.html

The world has a list of entities. You can also look for a specific class in the classnametable: local class=classnametable["light_directional"]

Messages with zero delay are sent immediately.

Try this: fw.main.camera:SetMatrix(object.cameraPivot.mat)

It looks like the filter needs to be moved to the end of the line, or added in the water shader as well.

Not free, but good: http://www.soundrangers.com

This command has been added to the DLL. It is experimental. It will return the lua state used in the engine. You might be able to import the lua library and perform commands on this variable. I don't know if it is okay to access one lua state with a separately intialized instance of Lua. If it isn't, then eventually we will expose the whole Lua command set through the engine DLL.

entity.matis a member where the matrix can be accessed. Rick, I need more information from you. I don't know if you are running something in the editor, a scripted app, a C++ program, etc.

Attacked? Did I chase you with a sharpened stick?

I think NVidia pursues these kind of things to raise their stock price. There is no way they are making a profit with this product, but it gives them something to show off and reinforces the idea that they are the leader innovating new technology. Cuda, PhysX, 3D vision, all of these projects lose money but they make NVidia look better to technically ignorant stockholders. When you see these grand web pages on NVidia's site talking about some new technology, it isn't aimed at the consumer. They are courting stockholders and potential stock buyers. After thinking about it, I really believe the decision to pursue these things was based on the desire to raise stock price even though it lowers profits. It's not really a good or bad thing, but it would be a mistake to get suckered into technology the proprietor themself doesn't even believe in.

We already have mostly procedural environments. You can distribute grass and trees based on certain parameters. You don't have to paint every spot of ground because you have parameters for the different layers. You can generate the terrain in L3DT and get a procedural heightmap. The dream is an infinite world with easy tools to procedurally generate most of it, then go in and adjust the things you specifically need by hand. That's pretty close to what we have now. But the whole streamed infinite world is a developmental nightmare, especially for an open-ended engine not locked to a simple racing genre. So let's make the most of the mature technology we have now, and everything we develop in the current engine might someday be useful in a version 3.

I don't have any such errors with those objects, and Lua is much less prone to hardware differences than graphics are.

The Lua command DoFile() simply executes all the code in the specified file. Require() only executes the code if it has not yet been run in the lua state. With a multi-state system this is not much of an issue, but in a single-state system it has a few ramifications. Let's consider the light_directional.lua class script. Pretend we want to make a change in the class.lua script and have this change seen by re-saving the light_directional script. We make our changes to class.lua and save it. Then we re-save the light_directional script. The changes in class.lua will not be apparent, because the light_directional script calls Require(), not DoFile()! The lua state sees that class.lua has already been run, so it doesn't bother re-running it. There is a way around this. Simply open the integrated script editor and type in "DoFile("Scripts/class.lua")". The script will be re-run. Then you can save light_directional.lua and the changes in class.lua will be apparent. Re-running a script will re-create any tables that were created in that script, and any values added to them will be lost. So if you were to run a script like core.lua, where the class and object tables are created, the results will be unpredictable. Hopefully this helped you to understand better how scripts in the engine work. Remember, you can always save and reload the scene if you think you did something bad to the lua state. Live programming is by its very nature a touchy matter, so if you are doing "heavy" coding you might want to stick to the standalone script editor until you have something stable.

FileSystem.lua

Well, the single-state lua update is out and I am ready to start making tutorials again. Someone in the forum pointed out the game Fuel to me. This is an offroad racing game with a nearly infinite world. The data is streamed off the hard drive, basically like its treating the drive as if it were extended RAM. The game got bad reviews, but I think it's great. I went driving for at least 30 minutes and covered mountains, desert, redwood forests, and ravines. I'm in love with the terrain engine. If only they had used that to make S.T.A.L.K.E.R... There's much to do with our existing technology before I start inventing new technology again, but the possibilities are intriguing.

Ah, you are right. I uploaded your fix to the server. You can probably guess what happened. I used to call the Refresh() function Update(), but then changed it because I didn't want it called each frame.

Well, for terrain at least it makes sense. I bought Fuel. What an amazing game. Can you imagine if they had made an FPS with that?

What would commented-out code you add to template.lua have to do with the waterplane script?