Josh

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 )

Make sure "Show Helpers" is enabled so you can see links. If you don't see a link where you think you should, try changing the link index in the main menu. This sets the link index that is displayed, and if you create a link it is created on this index.

I think BlitzMax is the best language to use, but people won't use it because they have never heard of it. C/C++ is pretty hard for beginners, so Lua offers a good combination of what people want. It is a well-known name, so people won't reject it for being unknown, and it is a lot easier for them to achieve progress with.

I'm going to do some experiments with a single lua state. It will make scripting harder, and you will have to manually clean everything up yourself, but it would allow shared data like this: player.enemy.bullet:shoot()

It's in the configuration settings.

You're planning to write a unique script to make all those events occur? I think it makes more sense to have a set of rules so the artist can place objects and adjust settings without writing a new script for each map.

You'll walk upstairs, the basement will flood, and you'll hear a lot of objects banging around. Then you go back downstairs and things aren't in the same place you left them.

Yes. Or if you just want the local rotation use this: entity.rotation.x These members should be treated as read-only.

Use alpha blend with an all-zero alpha texture.

Why wouldn't it, if those entities have been added to the scene?