[Hooks]

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.

[Hooks]

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?

[Rotating Particle Billboards]

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.

[Rotating Particle Billboards]

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.

[Single-state Lua]

I'm all for this, but is it really that simple? Won't you run into other issues with how lua scripts are currently used? entitytable for example will now be global and all entities loaded will be in it not just the entities local to one class model. Plus all scripts currently need to dofile() to base to use constants and stuff. That won't be needed because it'll only needed to be called once to load all that stuff.

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.

 

I don't want this to happen. My vote is no.

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.

[Rotating Particle Billboards]

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.

[Single-state Lua]

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.

[Forces local & global?]

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

[SendMessage Syntax?]

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

[Community Gun Fun]

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

[Switch and Fan in Tunnel.sbx]

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

[Forces local & global?]

AddBodyForce( force, 0 )

[Switch and Fan in Tunnel.sbx]

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.

[Advanced interactions]

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()

[Sandbox Editor (bloom)]

It's in the configuration settings.

[Advanced interactions]

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.

[Waterplane Questions]

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.

[Wiki command wrong?]

Yes. Or if you just want the local rotation use this:

entity.rotation.x

 

These members should be treated as read-only.

[Shadows cast on invisible floor?]

Use alpha blend with an all-zero alpha texture.

[Existing C++ project converting to 2.3]

It would be nice if the sbx file had a classname in for atmosphere and ambient light otherwise I haven't got anything to look for against the model.

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

[Wiki command wrong?]

You can use the procedural command, just as you did above.

[Advanced interactions]

That example is just a lot of different things going on, but nothing itself is very complicated:

 

Trigger sets a key in the player model:

SetKey("controlmode","auto")

 

Trigger sets the camera model's target to the player. The camera script follows the target, when one exists.

 

Trigger sends a message to a sound entity to play the music.

 

Player moves to his target until he reaches it, and some more events are triggered.

 

...and so on.

 

 

A bullet hitting a player, hurting them, and updating the owner's score was about the most complicated single interaction I could think of. Any other ideas? One advantage of this system is it encourages you to create a defined set of actions with the messages, instead of making spaghetti code.

 

One disadvantage is when you have something like the roads, and you want to tell if a wheel of a car lies on the road. You need to communicate with the road script, but how do you get that info back? That is where it gets sticky.

[Wiki command wrong?]

I think that command was missing internally. I am going through the docs and I find a few missing methods that I fill in as I document it. So sync in a couple days and it will be available.

[calling methods by name]

Maybe enter this text in the property editor:

function CustomBehavior(entity)
Notify("Hello!")
end

 

Then in SetKey add this:

function SetKey(key,value)
if key=="customscript" then
	dostring(value)
end
end

 

So now at this point the new code has been evaluated and the function is usable in Lua.

 

Now add this to the message receive function:

function ReceiveMessage(message,extra)
if message=="custombehavior" then
	CustomBehavior(entity)
end
end

 

I don't know if this is a great idea, because it is confusing, and the state is shared across all instances of the model, but it's interesting that it works.

[GetEntity() feature request]

Don't use it in real-time, because iterating through the whole model list will be slow when there are lots of models.