Josh

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.

What do you want to use this for?

Documentation and tutorials come next. I have a nice big chunk of time to work on them now. The terrain editing probem on SM3 cards was easily fixed, so the update will be available tomorrow.

Terrains in id tech are just a mesh made in a modeling program, so the geometry is very limited in size.

Is the Crysis AO calculation a step that has to be processed and saved, or is it dynamic?

From the technical specs I have read of RAGE, it doesn't even allow terrains as big as what we have.

I have no objection to a converter being made from gmf to another format.

I have to say, I love the idea of an infinite world streamed from the hard drive. It's a long way off, but I dream of a world like STALKER that's completely continuous.