Josh

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.

entity:SetCollisionType(type,recursive=0)

You should never parent one body to another. Why are you trying to do this?

Now that we have Lua, these kind of tutorials are more feasible.

I just tried Print() and it worked. I added a hook so this command will automatically write to the log file, though AppLog() was left for compatibility with existing code.

Why are you using a non-normalized vector for the pin?

SetGlobalNumber() sets a value in the engine. GetGlobalNumber() retrieves it. I don't have any plans to change the way the states are set up. It would require all the scripts to have their functions renamed like "light_directional_Update()" and who knows how else the scripts would interfere with one another.

The Lua commands match the BlitzMax methods, but you are right they are not completely documented yet.

The Lua command set exposure is a little tricky when you get into multiple levels of command sets, like when you have the engine command set, and you want to expose something else beyond that, like the Framewerk commands. The attached example shows how Lua command set generation works. To expose types, all you have to do is add an "expose" tag in the meta data. To expose procedural functions, you add the functions as a method in a type with the "noclass" setting. To generate your command set file, do this: generateGlueCode("lua-gluefunctions.bmx") End To run your program with the command set, do this: Include "lua-gluefunctions.bmx" I just include all three lines together, and comment them out depending on what I am doing: Include "lua-gluefunctions.bmx" 'generateGlueCode("lua-gluefunctions.bmx") 'End 'Include "lua-gluefunctions.bmx" generateGlueCode("lua-gluefunctions.bmx") End Any time you make changes to any of your exposed class commands, you have to generate a new lua command set file. Otherwise your program might not even compile, because it will have function declarations that don't match the commands you changed. Does this make sense? I could pull the Lua commands out of the engine and make this a requirement of any BlitzMax program that uses Lua. It's a little more complicated, but it allows you to change the commands I have exposed, add ones that may be missing, or expose your own types. For example, if you imported the framewerk module and generated the command set, you would have access to all the framewerk commands in Lua. This is how the editor and interpreter do it. MyGame.zip