Josh

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.

I think the time is past where making the GUI fit in the same space is a good idea. People have different monitor ratios and multiple monitors. Valve's windowed GUI is the best approach, I think.

What folder is your program located in?

Name meaning the field set for "Name" in the property dialog? It would show up as "name" in the keys. You can open the .sbx file in a text editor to verify this.

The way you are looping through all the entities to find the target is kind of backwards. You know you want your plane to have a propeller. You don't need to place it in the editor every time you want a plane. It's far easier just to do this in the spawn function: Function Spawn(model) entity=base_Spawn(model) entity.propeller = LoadModel( "abstract::propeller.gmf" ) If entity.propeller~=nil then attachmentposition=TFormPoint(Vec3(1,0,1),model,nil) entity.propeller:SetPosition( attachmentposition ) CreateJointHinge( model, entity.propeller, attachmentposition, Vec3(0,0,1) ) End End Make sure you get rid of the propeller in the Kill function: Function Kill( model ) entity=entitytable[ model ] If entity~=nil then If entity.propeller~=nil then entity.propeller:Free() entity.propeller=nil End End base_Kill(model) End I used this kind of automatic subobjects in the train cars to attach wheels to the car.

Yes.

Example?

Can you give an example of what you are trying to do?

The pin is the vector around which the joint rotates. Do not confuse this directional vector with a position.

AppTerminate is a variable you are initializing in the loop. It would not have any effect. Try Notify("Hit!"). Make sure you are including the keycodes script that defines all the key constants.