Josh

There are other ways of doing inheritance, but my function renaming approach seemed the simplest to understand. One consideration was that if I was having trouble understanding table inheritance, many of my users would too, and that would have a negative impact on their experience and my sales.

The function calls for an object, so an integer would not work. Lua is a little different because integers, strings, objects, and tables can all be used in the same parameter. This function has to work with C++ and every other language, so the flexibility of Lua is not something it can support.

SendMessage() is an engine command, so it handles data native to the engine, which doesn't include Lua tables. I mean, does Lua consume an amount of memory significant enough to worry about? It seems we want some data to be shared, but we don't want other data to be. Entities should be able to communicate and call each others' special functions, but we also want model scripts to be simple to write. There are two ways this can be solved with only small modifications: 1. Rename all model script functions with a prefix of the model file name. Instead of Update() you would write light_directional_Update(). 2. Make the engine automatically rename these function names by running a short source code after the script file is run: light_directional_Update=Update Update=nil I am leaning towards option 1. It's more explicit and there are no issues of trying to call a special function later only to find it has been set to nil automatically. The entire combined source code of the state can be printed out, and it is clear where everything occurs. I don't like ambiguity as a general thing. Option 1 is not as cool as just writing "Update()" in each script, but it seems like the most explicit and understandable approach.

This is the biggest advantage. This is not a concern, since no game engine can call random commands on separate threads without locking everything. Is memory use by Lua even an issue? Is it more expensive to run multiple GCs with a small amount of data, or one GC with a lot of data? I have not seen any definitive data on this. I've demonstrated that almost every interaction can be done, but it is awkward, and I do think it will cause problems further down the road. This is the single best argument for a single state. I don't think this is a big issue unless you are trying to store complex sets of data. I could see it coming up during advanced AI implementations. Can't comment on this. True. Are you sure? Where is the proof of this? I have seen the opposite asserted. Is memory consumption of Lua even an issue? The biggest con is duplicate function names and garbage collection. Right now cleanup is simple because when all instances of a model are freed, the lua state for that reference is freed. Cleanup becomes more important when a single-state is used, especially as individuals scripts are saved and re-run by the state in the editor. (When you are real-time coding a model). Not a concern. So the big issues are memory leak prevention, especially when a script is being re-run over and over as it is edited and saved, and sharing data between scripts.

The speed of drawing a line is not a bottleneck. The command you wrote is the same thing the engine does internally.

I assume you are working with the visual geometry, not the physics geometry. This must make the raycasting and other algorithms an order of magnitude slower than if you had the physics data?

Agreed. What have you been hiding?

More force does not mean greater speed. More force is exerted, but because the heavier object has more mass, more force is required to move it. Barring air resistance, a heavy object and a light object fall at the exact same speed. When you consider air resistance, the shape and mass of an object become factors. For example, a person wearing a parachute is much heavier than a brick, but the brick will fall faster.

I'm not sure I understand this. Maybe you should consider logic entities, where you are basic dragging an If statement into the scene.

It's the same in 2.28.

Nilium does know a lot more about Lua than I do. I'm not sure if Lua can pass a pointer to a table back to the main program. Everything I have searched for and read indicates otherwise. Maybe there is a way, but I couldn't figure it out. In the end, the way I ended up associating a table with a BMX object was to put them both into a Lua table. That's why every function starts with a lookup in the entitytable to retrieve the table associated with a model.

http://leadwerks.com/wiki/index.php?title=Vehicles

This game?: Sorry, couldn't resist. This looks really interesting. Maybe I can integrate it into the engine.

Default gravity in the engine is -9.8 units/s^2.0. Gravity on Earth at sea level is -9.8 meters/s^2.0. Since you can change the gravity value, it's all relative, but I recommend using 1 unit = 1 meter. However, you should understand there is no such thing as real units in a computer program. One spatial unit could be an inch, a meter, a mile, or a light year. One weight unit could be a gram, a pound, or a ton. It's all relative. Gravity affects all objects the same regardless of their mass. A piano and a feather will fall at the same speed in a vacuum.

Good point.

The jury has spoken.

That's why you have the source. Lua is just another language to access all the same commands with as you do in C++, C#, or any of the other supported languages. However, it is a free easy to use popular language, so supporting it gains me a lot of new fans. It can also be used with other languages on a per-entity basis. If you're comfortable with C, you've got everything you need already to make a game. A problem we found is that people can get through the tutorials and understand everything, but still don't know how to structure a game. And my response has always been that I can't write their game for them. With Lua, yeah, to a degree I am writing your game for you. But everyone is writing functionality, and it's easy to mix and match components. So it depends on your skill level. Some people use C++ and make games. Some people use BlitzMax and make games. Some people say they want to use C++, but they have trouble making anything with it, and are better off with Lua. Some people just like Lua because it is fun. My personal preference is BlitzMax, but I am finding Lua to be a lot of fun.

Framewerk handles all the effects. You can implement them yourself one at a time, but it is difficult, even for me, to get all of them working together. So most people just use Framewerk instead of struggling with basic rendering effects. It handles DOF, water, bloom, HDR, god rays, SSAO, and a bunch of other stuff, with simple on/off behavior. Lua is quite new, and the integration with C++ is something we have to explore further. This will evolve, but I would not start writing a large amount of code in Lua just yet. I think it is possible to expose all your own C++ classes to Lua and call engine and C++ functions from the script, but we still need to work it out.

This is presently not supported, but rest assured it will be soon.

It just means you can turn functionality on and off with a single include file.

I think you will find the results are not as good when you try to apply a texture to fade them along the length, when a cylinder is used.

You can add update loops to the main loop while keeping all the code contained in one file. Let's say you include a script that has to update something every frame. Instead of adding extra code in the main loop, you can add a hook in the included script, and that way you only have to include a single file. It just makes it easier to mix and match components.

What do you think?: AddHook(hookname,function) RunHooks(hookname) Example: AddHook("UpdateHook", UpdateBullets() ) AddHook("UpdateHook", UpdatePlayers() ) Then somewhere in the main Lua loop: RunHooks("UpdateHook") This can be coded entirely in Lua. Does gmod do anything fancier than this?

I would. Load it from a file so it is instanced. Or you could create a mesh manually and copy it for each tracer. I don't think you will ever have more than 10-20 onscreen at a time, so performance isn't a concern. In the final version, I would have a cache of tracer mesh instances you just hide and show as they are needed, instead of creating things dynamically, but there's no need to worry about that until the basic version is working. Oh hey, here's one example where a single lua state helps, because the tracer cache can be shared across multiple guns. I think your hook suggestion from gmod is a good one, too.

Why would you want the particles facing up? If you looked at the particle from the side it would become invisible. You want it to face the camera, and be aligned in the direction of travel. Is there any particular reason you want to use a particle emitter for tracers? It seems like an individual mesh would be easier to control.