Josh

The idea is we might be writing a rocket script right now, but some time in the future we might come up with an entirely new entity behavior that we want the rocket to interact with, without altering the original rocket script. Maybe I'll want to make a special button you shoot to activate, so it has to detect when a rocket hits it. A good case could also be made for having two scripts attached of the same type. A lot of oscillating and gradual motions might use two or three script attachments of the same type, with various settings adjusted to produce a combined output. For example, my vegetation waver code is the combination of a few different sine curves with different frequencies and amplitudes. You wouldn't want to do that in a script, but that's an example of the idea. Each script could just be appended to the end of an entity.scripts table, in which case you could just do this: for script in entity.scripts do if script.Hurt~=nil then script:Hurt(5) end end Then you could just call the function for all attached script, without knowing or caring what other scripts are doing. I need to come up with some more usage examples and see how they would work out.

If that were the case, we'd be looking at something like this for the mover script: function script:Start() self.movespeed=Vec3(0) end self.turnspeed=Vec3(0) end end function script:UpdateMatrix() Print(self.entity.position.x..","..self.entity.position.y..","..self.entity.position.z) end function script:Update() if self.movespeed~=nil then self.entity:Move(self.movespeed) end if self.turnspeed~=nil then self.entity:Turn(self.turnspeed) end end It's not bad, although the extra .entity table is not preferable. Let's say you have a rocket script, and it collides with some entity. If all functions were stored on the entity, you could do this: function script:Collision(entity,position,normal) if entity.Hurt~=nil then entity:Hurt(5) end end But if all information is stored in script subobjects, you would only be able to interact with some classes: function script:Collision(entity,position,normal) if entity.player~=nil then entity.player:Hurt(5) end end

I had to adjust the settings in WHM, instead of a php.ini file. It works for me now. Those two files will each take a while to download, as they are 16 mb apiece. Uploads should also be fixed now.

I believe this has the same cause as the problem uploading files more than a certain size. I filed a ticket with WiredTree. I have set the php.ini file, and the max file size is detected in the system, but it doesn't appear to be working.

I considered something like that, but I'm not convinced it's that great:: function door:Open() self:Turn()--Oh wait, we can not do that, because this is the door... --What if we say "entity" is a value in "door"? It would be entity.door.entity: this.entity:Turn()--Okay, this works alright end function door:Update() this.health --wait, that does not work, unless you want the value contained within "door", in which case GetString("health") would not return it this.entity.health = 100--okay... end It seems like a lot of mess for something that is supposed to be as simple as possible. I really do not like the infinite recursive loop of tables. I suppose you could do something like this in C++: entity->SetInt("door.openstate","1") Which doesn't look too bad. Of course, you could simple add a prefix to all your functions and attributes you don't want messed with, and achieve the same exact outcome with a lot less complexity: function entity:Door_Open() this:Turn(1,0,0) this.door_openstate=1 end

I don't know because it depends on what I am able to fit in before the release. If I predict too high, then people get upset because the things they read in my blog don't justify the price. If I say too low, then people get upset when the price turns out to be higher. There are still a lot of unknown things I am researching.

I've got iterators working, so you can do this: for child in entity.kids do Print(child.name) end Unfortunately, the Entity returned by the iterator does not match the lua object the main program uses, and so you can't set attributes from the main program and detect them elsewhere. This is pretty complex stuff.

With Luabind, it turns out we don't even need a table associated with an entity. We can just add values and functions straight to Lua's representation of that entity in the virtual machine! So instead of this: object.health=100 object.entity:SetPosition(1,2,3) You can just do this, which is much nicer!: entity.health=100 entity:SetPosition(1,2,3) So there's no object/actor nonsense, you just work directly with the entity itself. Entity KeysThe Get/SetKey convention from Leadwerks Engine 2 is going away, to be replaced with more direct entity access functions. You can still store "keys" with strings, but this will directly set the values of the entity table in Lua, so they can be access from script more easily: void Entity::SetString(const std::string& name, const std::string& value); std::string Entity::GetString(const std::string& name); void Entity::SetFloat(const std::string& name, const float& value); float Entity::GetFloat(const std::string& name); void Entity::SetInt(const std::string& name, const int& value); int Entity::GetInt(const std::string& name); void Entity::SetObject(const std::string& name, Object* o); Object* GetObject(const std::string& name); Here's a sample "mover" script that performs simple movement and rotation each frame: function entity:Start() self.movespeed=Vec3(0) self.turnspeed=Vec3(0) end function entity:Update() self:Move(self.movespeed) self:Turn(self.turnspeed) end And this is how we would set an entity up in C++ to turn 2 degrees on the Y axis each frame: Entity* box = CreateBox(); box->AttachScript("Scripts/Entity/Mover.lua") box->SetObject("turnspeed",Vec3(0,2,0)) Getters and SettersLuaBind does support getter and setter functions, and I decided it would be nice if we could have an object-oriented command set for the surface commands (even though vertices are NOT an object-oriented structure, at all!). If I can get vectors to be accessible in Lua, then we will be able to write code like this script, which performs a "breathing" effect on any model, ala Quake 3 Arena: function Entity:Start() this.speed = 1 this.amplitude = 0.1 end function Entity:Update() local n,v.d --Make sure this is a model entity before calling commands if this.class = CLASS_MODEL then --Get the distance the vertex should move d = math.sin(AppTime() * speed) * amplitude - amplitude --Apply movement to all vertices for n = 0,this.surface:length()-1 do for v = 0,this.surface[n].vertex:length()-1 do this.surface[n].vertex[v].position += d * this.surface[n].vertex[v].normal end end end end Multiple Script AttachmentsThis is a very tricky thing to handle, because the behavior is so hard to define. Right now I have it set up so predefined functions will be called, in order of their attachment. As for user-defined functions, that's a lot hard to pin down. If two scripts contain a function called "Kill()", and the script itself calls the function, should both functions be called? It will take more time and testing to see how this should work. A big problem is if the user defines a function that returns a value, and two scripts contain the same function. If another script calls the function, what should be returned? So then I start thinking about separate spaces for each script attachment, with their own set of members and functions, and I realized how incredibly hard to understand that would be, if you were accessing this entity from an outside script. In the absence of any compelling technological advantage, simple is best. For now, only the predefined functions get executed in sequence, and none of those return a value. My prediction is multiple script attachments will be used primarily by non-programmers who just want to combine a few behaviors and see results without touching any code. When you get into more complex behvior I think script programmers will generally use one script per entity that does what they want. It's still only 1:30 in the afternoon, so I am going to go get lunch and spend the rest of the day working bug reports. The model reloading issue that's active is a tough one. There's also a PHP issue uploading files to the site, so I will try to get that resolved.

Buying the beta gets you the finished 3.0 release.

I am guessing you have an ATI 5000 series GPU? There is a bug report in the tracker that is similar.

We use Lua. That isn't going to change.

Talk to Dave Lee about this, he was recently doing something similar.

You can't write an engine in C#. It would be horribly slow. If the end user could only use C# for XNA programming, that would be okayish, but there's no way I can rewrite the whole engine just for one platform. I doubt they would allow Lua either, and that it is pretty bad. The consoles are sort of a chicken/egg problem, but I predict once we have a mature LE3 product, it won't really be that hard to gain access to the dev kits. It's a harder sale when I have a product that's in development, and no history of console game development. I would have preferred to include consoles in development from day one, but I think it will work out okay. I can use the initial sales from LE3 on other platforms to hire console specialists for the port when we're ready.

Okay, I think what they are doing, is they have wounds that are modeled on the character specially. This is a lot of work, and the wounds always end up looking the same, but it can work. Their problem was they didn't want the wounds to just sit on top of the character like a bad make-up job. They wanted the characters to actually have gaping holes. So they modeled the wound to go inside the character mesh, with a lip around the edge to meet the character mesh. But if they didn't do anything else, the wound would be inside the model, and you would not be able to see it. So, they gave the shader an equation for the position of the wound mesh, and said "if the pixel occurs within this shape, discard it". This let them make those pixels invisible, which allows you to see through the character mesh and see the wound mesh they specially modeled. So a special shader could handle the discard part, but it will take a lot of trial and error to get right.

It's the same story on XBox. Do you have a developer license? It's too bad they only offer pure C# programming on XNA. C# would be fine for game code, but so many underlying libraries are written in C++. You'd think the console makers would learn from the success of the iPhone and open up their platform to developers.

Buying the PS3, or a dev license? You can't get a dev license unless you meet certain requirements.

Even if it was supported, how would you possibly use that? Do you have a PS3 dev license?

I don't have a PS3 developer license so I can't do this, but it's certainly a possibility in the future.

Why not make the emitter follow the camera around and use a smaller number of particles? You won't even see most of those if they are far away.

That looks great, but I believe it's vaporware. Now that's a valid example of irony. I've been attempting the same thing using Vue.

BTW, there is no restriction from anyone sending you the original free pack that was posted. I worked a deal out with Michael for those to be free to the community. But again, he made the effort to rework the assets for the commercial pack, which should not be distributed.

When they say they are using an ellipsoid to cull pixels, what they mean is they are giving the shader an equation for that shape and discarding pixels in a mathematic test that checks if their position is inside the volume. So it's perfectly possible without interfering with the rest of the rendering pipeline. The gore in L4D2 is pretty extreme, although I love the game.

The beta will be for sale only to existing LE2 developers, at a substantial discount.

At some point last year I decided I wanted to let Michael fix his models up and sell them, and I removed the free versions because I didn't think new users would really understand the fixes he made, and why they were better than the free ones. (I did give a warning of several months.) I believe this is one of the issues he resolved, but I'd ask him confirm that is correct. This was before the asset store came around, but that's what it eventually morphed into. Sorry for the inconvenience, but it sounds like you'll be better off with his commercial packs that resolve this and some other issues.

Which results in less code? There's your answer.