Josh

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.

The movement technique sounds interesting. Maybe a more advanced physics version could be implemented as well. You have made some good arguments for a single-state system. See my post in the Lua forum.

The base file can be called once by the main program, or can be placed in the start folder. The entity table would be global, but it's easy to iterate through all instances of a model. Undoubtedly some small changes will have to be made to the model scripts, but we're still in the stage where that is acceptable. Can you elaborate why? The biggest disadvantage of the multistate system is when you have tables that have to be shared, it is impossible. We might be able to get around that for a long time, but I have a feeling it is going to come back and bite us in the future. For example, if I want to tell if a vehicle's wheel is on the road, I would want to be able to call a function from all nearby road entities that would be written in the road script. That's where it gets ugly, and I am afraid we will run into more cases like that as we make more complicated games. I won't do anything to the official release until I am sure this is a good idea. If I pursue this, it will start by posting some test versions of the interpreter so we can play around with the idea. Like I said, I don't like making changes, but if we are going to, it should be done now while it won't hurt anything.

Well you have two vectors to think about. One is the direction of the bullet. The other is the direction the camera is facing. You might want to solve this on the CPU, because it is a rather tricky problem to get right. You should be able to point the tracer in the direction the bullet is moving. Let's say the z axis of the tracer mesh is aligned to the bullet's velocity. Then find the camera xy position relative to the tracer and align another axis of the tracer to this vector. Fortunately the AlignToVector command lets you align any axis. Make sure you fill in all the parameters of this command, because they will all be 0 if you don't supply an argument.

For version 3.0 on the consoles and PC we will have to use C++ and Lua. Until then, it makes sense to use BMX for the PC, Mac, and Linux.

I can see already Lua is being very well-received, and it looks like some serious work is going to be done with it. I did not plan on making any revision to the system, but if we are going to make any changes, it should be done now, not later. I do know a way I can use a single state and still have our same function name conventions. Internally, the engine can just do this string before loading a new class script: Spawn=nil InitDialog=nil Update=nil ReceiveMessage=nil Then let's say light_directional.lua is run. After that, this code can be run silently by the engine: light_directional_Spawn=Spawn light_directional_InitDialog=InitDialog light_directional_Update=Update light_directional_ReceiveMessage=ReceiveMessage The engine would then call the functions prefixed with the model name, like light_directional_Update() instead of Update(). You could still call the functions the same thing in each class script, but the engine would be able to differentiate between them. Consequences: -You can access lua functions across scripts. -You can't call Update(), etc. yourself because the functions are internally renamed. -You have to clean up everything in the Cleanup() function since the state won't be deleted when all instances are cleared. -The Lua virtual machine will get bigger and bigger as more model classes are loaded. Maybe I can set all the class functions to nil when the class is deleted. I initially thought Lua would be good for tinkering around with and making some cute demos, but it looks like people like it and are very capable of using it. A single-state system might be better in the long run, and it's not that big of a revision.

Use TFormPoint and TFormVector to transform the position and force from local to global space.

Extra is a BlitzMax object, which includes strings. It cannot be an integer (unless it is converted to a string) or a Lua table.

You can send the damage value as a string. What is the hit info thing you are talking about?

A single model can only have one link on an index.

AddBodyForce( force, 0 )