PointAtTarget

[Canardia]

This should work theoretically, but I don't have LE3 yet so I can't test it.

It will make the model turn at its target.

 

When used in along with the Mover script, it will make the model follow another model.

For example if this script is applied to an enemy model, and the target set to the player model, then the enemy will follow the player:

function actor:Start()
self.target=nil
self.turnspeed=0.01
end

function actor:Update()
if self.target~=nil then
	self.entity:Point(self.target,self.turnspeed*AppSpeed())
end
end

[Josh]

That looks right. Then in the editor you would drag the desired entity into the "target" parameter to set it.

 

Alternatively, you could do this in C++:

int i = entity->AttachScript("Scripts/actors/pointat.lua");
entity->SetObject("target",targetentity,i);

[Rick]

Just wondering, where do you plan on putting that glue code that the editor will create?

[Josh]

It will just get loaded from the scene.

[Rick]

So you plan on having a separate lua file that the editor creates and maintains and has all that glue code and have it automatically loaded with the scene?

[Josh]

It doesn't need glue code. My understand of the term is that is code I use to expose engine C++ classes to Lua. I'm not sure what you're referring to.

 

The scene file will probably look something like this:

entity

{

script "Scripts/pointat.lua"

{

target = 487567493 // entity ID in the scene

speed = 3

}

 

}

[Rick]

Where would entity->SetObject("target",targetentity,i); command be executed? That's the glue code that actually links the variable target of the script to an actual ID. The script itself wouldn't have this in it as all it does is expose the target variable. In the editor is where you are making that link and so even in your scene example file that doesn't actually set the variable UNLESS you are thinking of embedding the actual lua scripts inside the scene file? That would seem weird to me.

[Canardia]

That is pure C++ code, it just calls the already glued Lua engine commands and runs a lua script which uses those.

[Josh]

The command would be executed when the scene is loaded, because the scene would list that entity in the scene as the value.

 

Here's a version of your script I have actually working. Now my teapot changes color AND faces the camera!

function actor:Start()
self.axis = 2
self.speed = 0.01
end

function actor:DrawEach(camera)
self.entity:Point(camera,self.axis,self.speed)
end

[Josh]

Okay, now I have an Actor C++ class that gets created when a script is attached to an entity. You can set and get values on the Actor itself:

 

Actor* actor[2];
Model* teapot = LoadModel("teapot.mdl");
actor[0] = teapot->AttachScript("ColorOscillate.lua");
actor[1] = teapot->AttachScript("PointAt.lua");
actor[1]->SetObject("target",camera);

[Rick]

That seems backwards. I would think it would be:

 

Actor* actors[2];
Model* teapot = new Model("teapot.mdl");

actors[0] = new Actor("ColorOscillate.lua");
actors[1] = new Actor("PointAt.lua");

teapot->AttachActor(actors[0]);
teapot->AttachActor(actors[1]);

//or
teapot->AttachActors(actors);

 

I still think your naming convention is messed up with "Actor". They are scripts and you even have the method called AttachScript yet they return actors? Just seems strange.

[Josh]

I presume the reason for this would be to attach multiple entities to the same actor, in which case there would be no per-entity values in the script. The script would only have values shared across all entities it was attached to. Can you think of a situation where this would be useful? I mean, you could use this so you could just control the values of one actor and have it affect all the entities it is attached to, but it would be very limited because it would only allow shared variables in the script.

[Rick]

Well actually the main thing I was thinking was that you still have some C mannerism is your design and this would make it more C++ like, but now that you mention it that would be something that you COULD do if you wanted to. I guess the only thing that comes to mind currently is that you could have your "player" script be attached to another entity if you wanted your player to be able to control a different entity off and on at run-time.

 

If you did it this way you are giving more options while keeping your ways functionality. Just because we can't think of a reason to use this doesn't mean there isn't, or someone will think of it later. If you wanted to keep your design then you can overload your AttachScript to take an Actor class and that would be another way to get that functionality while still holding your design.

 

Actor* actor;
Model* teapot = LoadModel("teapot.mdl");
Model* teapot1 = LoadModel("teapot.mdl");
actor = teapot->AttachScript("ColorOscillate.lua");
teapot1->AttachScript(actor);

 

Generally methods don't create objects unless you are using the factory design so that's what I was mainly talking about.

[Canardia]

The best would be if the LE function would use internally alloca() instead of new or malloc(), because then they would be using stack memory which is much faster than heap memory, and CPU uses also parts of the stack memory as CPU registers which makes it even faster.

But maybe I can make my own LE3 version which uses only stack memory.

[Josh]

Now I've actually got a LoadScript() command, and a script and an actor are NOT the same thing!

 

Load and run a script:

script = LoadScript("mygame.lua");
script->Run();
script->Run();
script->Run();

Attach a script to an entity:

script = LoadScript("Mover.lua");
actor = new Actor(entity,script);
actor->SetVec3("turnspeed",0,1,0);

The script must have a Main() function to be run, and it must contain actor:whatever() functions to attach it to an entity.

 

It's complicated, but the script loads all the actor functions into a table, and then the functions get copied to each actor. That way the engine isn't calling DoString() each time and creating a bunch of unique functions in the virtual machine. So if you have an actor script that is attached to 100 different entities, there is only one set of shared functions, but the actor userdata is not shared, so each one can have different values. It also means you can load a script once and run it multiple times, and that will be faster than executing a file each time, because the parsing step will be skipped.

[Canardia]

Alternatives for Actor:

• Activity
  
• Movement (like in classic musical compositions: 1st Movement, 2nd Movement, etc...)
  
• Action
  
• Task
  
• Job
  
• Intelligence
  
• Process
  
• Program (like in washing machines)
  
• Thread
  
• Daemon
  
• Subscript (new meaning for the word!)