Josh

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.

This is how I did vertex lighting in very old versions of the engine. Each instance had a unique color array that was switched when instances were drawn. This is not part of the design of the modern engine.

You can delete the scilexer DLL and the editor will use a different method of rendering text. It won't look as nice, though. There were earlier problems with scintilla crashing, but they seem to have been fixed, or so I thought.

Fixed, thanks.

Well, they're probably just going to write documents and use email for those machines.

I would not be surprised if 70% of computers have an Intel integrated graphics chip. Don't know if that is correct or not, but it sounds reasonable.

That's not a bad idea.