Josh

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

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

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.

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.

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.

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

I think at some point you should just work within the bounds of what you have. Eventually you will have more options to do stuff like this, and writing workarounds in the meantime will likely cause unforeseen problems like what Red Oktober mentioned. You'll walk up the stairs and find a lot of fish flopping around in your living room, or something.

It makes sense because camera range is a per-map setting. Small indoors scenes need a short range, and outdoors scenes vary depending on fog range and other factors.

I want to make sure the system can handle complicated interactions. Here is an example where a bullet shoots an enemy. I added an imaginary extra "sender" parameter to make it easier: Bullet/player script: enemy:SendMessage("hurt",0,"-5") Enemy script: function ReceiveMessage( message, extra, sender ) if message="hurt" self.health=self.health-tonumber(extra) if self.health<=0 then self:Kill() sender:SendMessage("addscore")--Add to the killer's fragcount else self.model:EmitSound(sound_ouch) end end end What other scenarios can you think of that might be difficult? As far as I can tell, this system can handle everything, but I want to make sure.

It would hurt something, because it would cause more bugs for me to spend time on. The biggest problem would be if two models have the same name, and then one is freed, there would be no model for that name, even though it exists. You can have up to 8 targets. I can raise that if needed, but it seemed like enough for now. You can loop through all entities with the world entity list: for entity in iterate(CurrentWorld().entities) do end Or: for entity in iterate(CurrentWorld().models) do end Or: for entity in iterate(model.reference.instances) do end

You can even write a little script in the property editor and make the model execute that code. There's an option in the text property to open a multiline text editor in a separate window. I didn't use this feature, but it is an example of just how flexible Lua is.

The point of targets is so you don't have to type in unique names and find them later. Just click and drag between two models. Unique names are more error-prone. Target relationships won't run into problems with redundant names. You can set up one system of objects, then copy and paste them, and the copied group will behave the same, with targets intact. If you copy and paste named objects, their names will be identical, and they will interfere with each other.

Targets. You can link objects by clicking on one and dragging the mouse to another, then releasing. There are 8 target indexes you can select in the menu. You can retrieve the targets with entity:GetTarget().

Can you give an example?

There's an oildrum.phy file in 2.3 which can be used to replace the one that comes with the tutorial.

People are starting to use Lua, which is good. Initially there was some confusing, but in each case it turned out to be a small misunderstanding. I spent a few hours editing the wiki to add Lua syntax to the commands. I'm going to start working on Lua demos and more high-level stuff, in addition to fixing any bugs that exist. I'm not too interested in adding new features right now. This engine has plenty of features. Tons. It's time to use them to make something.

Regarding the weapons, I am very interested in seeing some tracers. It seems like gunfire is a combination of a lot of different things, and it's hard to pull it all together to make a convincing gunfight.

At the moment you can't, because water is not contained in a volume.

1. Create an entity called "func_endgame". 2. When the player hits the trigger volume, send a message with a 5 second delay to the func_endgame entity. 3. When the func_endgame entity receives a message called "activate", it calls SetGlobalNumber("gameover",1). 4. Your main loop has this code: if GetGlobalNumber("gameover")==1 then return end

Every entity does not have its own state. Every model class has its own state, which means all instances of any model share a state and can access everything about each other. For communication between different kinds of models, I recommend the messaging system.

entity:SendMessage( message, delay, extra ) Extra can be the sender, or something else since not all messages will have a "sender" entity. I just looked over the docs, and it looks like they are all correct. If you find any discrepancies let me know.

That's not true. Textures do not require mipmaps or DXTC5 format. Cubemaps do require mipmaps on NVidia hardware. When making a post like this, please post the relevant files. Otherwise we are just speculating about what the cause might be.

My point was that if you try to make your GUI appear the same on every resolution it will be more complicated and buggy than if you used a fixed sized for your controls.

The default BlitzMax installation folder has been changed to C:\BlitzMax because of this. So I guess the Program Files folder convention is now useless.

If the propeller isn't going to be interacting with any physical objects, there's no need to bother using a joint.