Josh

I did something kind of dumb when attempting to implement a separate raycast algorithm for thick raycasts.

Then you are in the same boat as before. The problem is getting Lua and C++ to interact. Right now you have limited means to do this. This can be improved if I add the following: -Add a command to retrieve the Lua state (virtual machine) from a world. -Expose the entire Lua command set in the DLL. Then you can call framewerk and your own C++ commands from Lua.

Particles are a good choice for localized fog.

I've been revising the Lua design a bit. Ideally this should have been done six months ago, but I did not realize how popular it would be. During beta testing there wasn't much interest in it. That's understandable, because no one likes using beta software. As soon as it was released, suddenly there was some very advanced stuff being implemented immediately. This is great, and I can see my thoughts about how it would benefit us were correct. It also made me want to implement a single-state system so that we could really use Lua to its full potential. I spent all day on it, and I think it's done. I just have to finish making the changes to the class scripts. This wasn't my ideal way to develop, but if changes are to be made, they should be made now, not in three months.

Well, I started reading, and even if I can make sense of it, if it isn't immediately obvious my users won't get it. And the whole point of Lua is to be easy. With a single-state system, here is what the directional light script looks like: require("scripts/base") --Initially set all the functions we might want, so we --don't have to keep track of which ones we actually declare. light_directional_InitDialog=base_InitDialog light_directional_Spawn=base_Spawn light_directional_GetKey=GetKey light_directional_SetKey=SetKey light_directional_ReceiveMessage=base_ReceiveMessage light_directional_Kill=base_Kill function light_directional_InitDialog(grid) base_InitDialog(grid) group=grid:AddGroup("Light") group:AddProperty("Resolution",PROPERTY_CHOICE,"256,512,1024,2048") group:AddProperty("linearoffset",PROPERTY_VEC3,"0,1,2","Linear offset" ) group:AddProperty("shadowdistance",PROPERTY_VEC3,"","Shadow distance" ) group:AddProperty("Range",PROPERTY_FLOAT) group:Expand(1) end function light_directional_Spawn(model) local entity=base_Spawn(model) entity.model:SetKey("resolution","2") entity.light=CreateDirectionalLight(entity.model) return entity end function light_directional_Kill(model) local entity=entitytable[model] if entity~=nil then if entity.light~=nil then entity.light:Free() entity.light=nil end end base_Kill(model) end function light_directional_GetKey(model,key,value) local entity=entitytable[model] if entity==nil then return value end if entity.model==nil then return end if entity.light==nil then return base_GetKey(model,key,value) else if key=="linearoffset" then return entity.light:GetShadowOffset(0,0)..","..entity.light:GetShadowOffset(0,1)..","..entity.light:GetShadowOffset(0,2) elseif key=="shadowdistance" then return entity.light:GetShadowDistance(0)..","..entity.light:GetShadowDistance(1)..","..entity.light:GetShadowDistance(2) elseif key=="range" then return entity.light:GetRange() elseif key=="shadowresolution" then resolution=entity.light:GetShadowmapSize() if resolution==256 then return 0 elseif resolution==512 then return 1 elseif resolution==1024 then return 2 elseif resolution==2048 then return 3 else return -1 end else return base_GetKey(model,key,value) end end end function light_directional_SetKey(model,key,value) local entity=entitytable[model] if entity==nil then return 1 end if entity.model==nil then return 1 end if entity.light==nil then return base_SetKey(model,key,value) else if key=="resolution" then if value=="0" then entity.light:SetShadowmapSize(256) elseif value=="1" then entity.light:SetShadowmapSize(512) elseif value=="2" then entity.light:SetShadowmapSize(1024) elseif value=="3" then entity.light:SetShadowmapSize(2048) end elseif key=="range" then entity.light:SetRange(value) elseif key=="shadowdistance" then local offset=string.Explode(value,",") x=tonumber(offset[1]) y=tonumber(offset[2]) z=tonumber(offset[3]) if x==nil then x=0 end if y==nil then y=0 end if z==nil then z=0 end entity.light:SetShadowDistance(x,0) entity.light:SetShadowDistance(y,1) entity.light:SetShadowDistance(z,2) elseif key=="linearoffset" then local offset=string.Explode(value,",") x=tonumber(offset[1]) y=tonumber(offset[2]) z=tonumber(offset[3]) if x==nil then x=0 end if y==nil then y=0 end if z==nil then z=0 end entity.light:SetShadowOffset(x,1.0,0) entity.light:SetShadowOffset(y,1.0,1) entity.light:SetShadowOffset(z,1.0,2) else return base_SetKey(model,key,value) end end return 1 end

I have no idea what a kg is. I know it's 1000 grams, but I don't know how much that weighs.

If you want framewerk to be a C++ source code you will have to work with it and Lua. There is a way to expose your C++ classes to Lua, which could make this work very nice and seamlessly, but we need to take one step at a time.

2.3 is the same as 2.28, with extra features. There isn't a new way to render water because it hasn't changed.

Brucey on the BlitzMax forum would be the best person to talk to. I think compiling in BMX would be best because then I could add this functionality into the editor. I don't know enough about how it works yet, so your experimentations are really helpful.

Use a third-party lib.

Oh, I am very impressed with what you have done so far.

Yes.

When I think about the single state with renamed entity functions, it makes sense when I consider the resulting combined source with the main program, and all the included model scripts. The source code the engine makes by doing different script files would look something like this: Graphics(800,600) while KeyHit()==0 do update() render() flip() end function light_directional_Spawn(model) --do some stuff end function light_directional_Kill(model) --do stuff end function vehicle_truck_Spawn(model) --do some stuff end function weapon_gun_Spawn(model) --do stuff end It looks a lot like a C program, like the Quake 3 source for example. It makes sense and seems like a good approach.

Lua inheritance seems extremely workaroundish to me: http://lua-users.org/wiki/InheritanceTutorial

If that's the model I think it is, I did not pay to have it made, I only asked him if I could use it with Character Shop.

There are other ways of doing inheritance, but my function renaming approach seemed the simplest to understand. One consideration was that if I was having trouble understanding table inheritance, many of my users would too, and that would have a negative impact on their experience and my sales.

The function calls for an object, so an integer would not work. Lua is a little different because integers, strings, objects, and tables can all be used in the same parameter. This function has to work with C++ and every other language, so the flexibility of Lua is not something it can support.

SendMessage() is an engine command, so it handles data native to the engine, which doesn't include Lua tables. I mean, does Lua consume an amount of memory significant enough to worry about? It seems we want some data to be shared, but we don't want other data to be. Entities should be able to communicate and call each others' special functions, but we also want model scripts to be simple to write. There are two ways this can be solved with only small modifications: 1. Rename all model script functions with a prefix of the model file name. Instead of Update() you would write light_directional_Update(). 2. Make the engine automatically rename these function names by running a short source code after the script file is run: light_directional_Update=Update Update=nil I am leaning towards option 1. It's more explicit and there are no issues of trying to call a special function later only to find it has been set to nil automatically. The entire combined source code of the state can be printed out, and it is clear where everything occurs. I don't like ambiguity as a general thing. Option 1 is not as cool as just writing "Update()" in each script, but it seems like the most explicit and understandable approach.

This is the biggest advantage. This is not a concern, since no game engine can call random commands on separate threads without locking everything. Is memory use by Lua even an issue? Is it more expensive to run multiple GCs with a small amount of data, or one GC with a lot of data? I have not seen any definitive data on this. I've demonstrated that almost every interaction can be done, but it is awkward, and I do think it will cause problems further down the road. This is the single best argument for a single state. I don't think this is a big issue unless you are trying to store complex sets of data. I could see it coming up during advanced AI implementations. Can't comment on this. True. Are you sure? Where is the proof of this? I have seen the opposite asserted. Is memory consumption of Lua even an issue? The biggest con is duplicate function names and garbage collection. Right now cleanup is simple because when all instances of a model are freed, the lua state for that reference is freed. Cleanup becomes more important when a single-state is used, especially as individuals scripts are saved and re-run by the state in the editor. (When you are real-time coding a model). Not a concern. So the big issues are memory leak prevention, especially when a script is being re-run over and over as it is edited and saved, and sharing data between scripts.

The speed of drawing a line is not a bottleneck. The command you wrote is the same thing the engine does internally.

I assume you are working with the visual geometry, not the physics geometry. This must make the raycasting and other algorithms an order of magnitude slower than if you had the physics data?

Agreed. What have you been hiding?

More force does not mean greater speed. More force is exerted, but because the heavier object has more mass, more force is required to move it. Barring air resistance, a heavy object and a light object fall at the exact same speed. When you consider air resistance, the shape and mass of an object become factors. For example, a person wearing a parachute is much heavier than a brick, but the brick will fall faster.

I'm not sure I understand this. Maybe you should consider logic entities, where you are basic dragging an If statement into the scene.

It's the same in 2.28.