Josh

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?

Yes. The environment_atmosphere script uses it.

I played this game on the PS3. When the car hits that ramp and knocks over the tower, the ramp has an animation that makes it "fall" on a pivot, but the tower is completely solid. Unless I remember wrong. I actually bought this game and studied it a bit because someone was interested in having us design something similar, but it didn't work out.

Just add this code and uncomment as needed: --[[ function object:Update() end ]]-- --[[ function object:UpdatePhysics() end ]]-- --[[ function object:Render() end ]]--

Motorstorm is just a generic racing game. That movie is mostly prerendered CG.

The only version sold now is 2.3. Keep in mind you still have to design gameplay yourself. The engine takes care of the technical foundation and lets you make the game.

The problem is Fuel is only a racing game. A game with weapons or more complicated interactions is a lot more complex. I definitely like their design, though.

All the old class functions are supported. Update() and UpdatePhysics() work a little differently now. They will be called once per model, when the world that model is in is updated or has a physics step. This was found to be the best approach. So it's a per-instance function; You don't have to loop through all the instances of a class or anything like that. There are also a few functions the engine will automatically call at certain points if they exist in the lua state: UpdateWorldHook( world ) --when the world is updated UpdatePhysicsHook( world ) --called for each physics step FlipHook() --can be used for drawing These are global functions not attached to a model. You can set up your own Lua hook system inside these functions, make them general functions for updating various things, or don't use them at all. You will notice the road_node script includes the "hooks" script, and calls AddHook() to add the road updating function. Now this is a hook system written entirely in lua. If you look in loop.lua, you can see this declares the UpdateWorldHook() function and uses the Lua hook system to call any Lua hooks the user added, including the road update function we added. Note that when the road class is freed (all instances of the model are freed) the lua hook is removed. It's actually not as complicated as it sounds, and it allows updating during the game loop on both a global and per-entity basis. One additional object method was added, Render(). This will only be called right before a model is rendered. This is useful for things like flickering lights, where you have a constant update but you don't want to clog up the engine performing a bunch of updates on objects that aren't even onscreen.

Copy the template.lua script: require("scripts/class") local class=CreateClass(...)

Wow, Fuel is awesome. I downloaded the demo. Can you travel across the whole world in the full game?

The engine uploads an array of matrices and draws a batch of like objects in one call. The texture offset idea is not bad. You could use the per-instance color to control the texcoords for it.

You can enable physics debugging so you can see where everything is.

Since it's all one state, you can just use a global lua variable.

This community rocks.

It's up.

An update is available if you rerun the update tool. The version is still 2.3. The Lua design needs to be talked about. You will notice the class scripts are an object-oriented single state system. It is possible for you to mess up the Lua state with a bad class script or a script you run in the integrated script editor. For example, if you do not free a class it will remain in memory and may interact in unexpected ways. If you follow the design of the template.lua script, you will be okay. Just contain per-class variables within the class object as I did in the examples. Whenever you load or create a new scene, the Lua state is recreated, so you start with a clean state. The class scripts syntax is as follows: An "object" in lua is the analog to the model instance in the engine. I decided to call the variable "object" instead of "entity" to avoid confusion with engine entities. The object is just a Lua table associated with a model in the engine. The object "Kill" method is renamed to "Free" because the OO design allows redundant function names (thus, object:Free won't clash with class:Free). A class is the table associated with an engine ModelReference object. This is a Lua table that is used to create all the objects. The class has a reference to the model reference, and has an instances table where all objects of the class are inserted into. So on the engine side you have a ModelReference with an instances list where all the models of that type are stored. On the Lua side you have the class table, which has an instances table (like a list) where all the objects of that class are stored. A function renaming trick in class.lua (the replacement to base.lua) makes it so you can call the base class' original functions in extended class functions: function object:Free() --do some stuff self.super:Free() end When you open or write a script in the integrated script editor, the Lua state is not recreated after the script runs. This allows you to modify internal values or set variables, but the editor will not clean up any damage you do. Conversely, when the "Switch to Game" mode is enabled, the editor reloads the scene from memory and creates a clean new Lua state when the you switch back to the editor. Whenever the lua state is created (at startup or with a new scene) all scripts in the "Scripts/start" folder are run in no particular order. Remember, these script are using the same lua state as the class scripts, so you can access information defined in the startup scripts. Finally, the single lua state allows class scripts to access each others' data. This allows for much deeper interactions between classes. This design is final. I'm sorry for the misstep in development, but I think you will agree this design will give the best results. Have fun and be safe. I am happily now going to focus on tutorials and examples for a few weeks.

There's a camera spline script in the editor that can make these movies much smoother.

Their system is basically a visual way of writing shader code. All the "input nodes" in their system are variables or texture lookups, and it probably uses that to generate a new pixel shader for each material created.