[Solved] Actor questions

[digiot]

GEs concept with the regions, actors, actions and events I really like, and
I'm understanding it in its basic forms.

But when it comes to a more advanced usage of actors, I'm missing some information.

Generally, there is a gap in GEs docs and tuts between the very basic ones, and
the more experienced stuff.

In many example code snippets for example, I noticed the usage of the dot-operator,
but I never saw any struct declaration, or at least a reference in the text.

So I got puzzled, what is that dot thingie at all, maybe any special GE feature, or
what...

But since I'm constantly in GE, last time, one of the "Actor Control" tooltips
discloses the secret for me, with one simple phrase :

Every actor in GE is a member of a struct.

It does not go into details, but that's all I must know.
Surely, there are more infos hidden in all the docs and tuts, before I've found
all of them, maybe you can help out here.


Here are my questions :

When I'm right, the "Creator Actors" are only existent for actors, which are created
directly in the global code, maybe also in any event script.

So, for every actor I create per script, I will get an additional "Creator Actor",
but all the gui created actors don't have any "Creator Actors" ?

And I read different suggestions, what to do with the "Creator Actors", some
for using their events/actions, others for destroying them, after they have done their work.

What is the benefit for using the "Creator Actors", compared to the normal actors ?

And if you don't need the "Creator Actors", what are the benefits and the drawbacks,
whether you kill them or not ?


When you are cloning actors, the actor from which you are cloning is not actorname.0,
is it ?
So, when I want to use the clonenumbers in a script, I can't have access to the initial
actor in that way ?


Thanks in advance for your help !

P.S.: Just noticed, the initial actor is actorname.0, so, if it's a clonenumber or not, you
can count through the clones, down to the initial actor !

[skydereign]

P.S.: Just noticed, the initial actor is actorname.0, so, if it's a clonenumber or not, you
can count through the clones, down to the initial actor !

Here's a clarification in terms. When people say an actor, they usually mean a specific instance of an actor (a clone). This is because actor can mean all clones of the same name. For instance if you use DestroyActor("enemy"), it will destroy all actors/clones named enemy. Again, a clone is a specific instance of an actor, indexed by an integer cloneindex. So clones are more specific actors. Even if there is only one instance of an actor, it is still a clone (usually actorName.0).

In many example code snippets for example, I noticed the usage of the dot-operator,
but I never saw any struct declaration, or at least a reference in the text.

As you mentioned, it says actors are structs. The declaration of the Actor struct is built into the engine, and therefore you don't have access to it. That means you can use the dot operator if you have an Actor struct. For each actor name, there is a default actor struct (also provided by the engine). I say default because there exists only one of this struct per actor, and it usually is the struct for the clone with the lowest cloneindex.

It does not go into details, but that's all I must know.
Surely, there are more infos hidden in all the docs and tuts, before I've found
all of them, maybe you can help out here.

The Actor struct we have access to is a struct with all the actor variables inside. These are listed in the script reference.

When I'm right, the "Creator Actors" are only existent for actors, which are created
directly in the global code, maybe also in any event script.

"Creator Actor" is a term used for the actor that created the "Event Actor". So what do you mean by that term? Are you talking about the initial actor (the 0th clone)?

Going back to the default actor struct, the lowest indexed clone is the one it represents. So changing its values will change only the values of that one instance. If there happens to be only one of that actor, then obviously it will represent the correct one. You can't rely on this for actors that have many clones.

When you are cloning actors, the actor from which you are cloning is not actorname.0,
is it ?

In a way you are cloning actor.0. If you set the transparency of actor.0 in the stage, any clones you create in game will share that initial transparency. So that means the lowest indexed clone in the stage defines the default settings which are used when creating new clones.

So, when I want to use the clonenumbers in a script, I can't have access to the initial
actor in that way ?

The initial actor is actorName.0.

[digiot]

The concept of cloning I understand, but I was not sure, if the actorName.0 counts as
first clone, or the "0" just means, it's the initial actor at all.

The Actor struct we have access to is a struct with all the actor variables inside. These are listed in the script reference.

The next puzzle solved !

"Creator Actor" is a term used for the actor that created the "Event Actor". So what do you mean by that term? Are you talking about the initial actor (the 0th clone)?

Idk, that's exactly my question, where and what this "Creator Actor" is.

In the docs, the "Creator Actor" is one of the special actors, and it will only exist,
if the actor is invoked through a script.

And I read different suggestions, what to do with the "Creator Actors", some
for using their events/actions, others for destroying them, after they have done their work.

and

...what are the benefits and the drawbacks, whether you kill them or not ?

Maybe, they are just existing in the code, but then, howto access the events/actions of them ?

[digiot]

Ha, maybe, the "Creator Actor" is just the actor, on which the "CreateActor" script command
was used ?
But then there are two of them ?
I haven't got that to work yet, so I can't check it.

[skydereign]

Ha, maybe, the "Creator Actor" is just the actor, on which the "CreateActor" script command
was used ?
But then there are two of them ?

I told you what "Creator Actor" is supposed to be. It is a way of targeting the actor that created the event actor. So as you realized, the actor that ran the CreateActor function that actually created it. So actors that exist on the stage, that weren't created by a CreateActor function call, do not have a creator.There is also a struct you can use to access the creator actor, aptly named creator.

Code: Select all

creator.x = 100; // sets the actor that created this one's x to 100

[digiot]

Yes, I've had to see that in action !
After I've purged the garbage in the code, now I have it running.

Seems, this is like the cloning, but without inheritance, can I think of it like that ?

Changed to the "MoveTo" anyway, but there appears an obscure behaviour :

I thought, it's smart, to position top-left of the screen and the view at the game center,
to avoid any problems with the coordinates.

But just that happens, with "game Center", and also with "view" in the "MoveTo",
the actors are getting displaced a bit in the minus directions.

The same happens with or without any safe margins.

What's going on here, where must I fix ?

[skydereign]

Seems, this is like the cloning, but without inheritance, can I think of it like that ?

Inheritance has nothing to do with cloning, so technically yes. All a clone is, is an instance of the actor struct. No one clone defines the actor struct, you aren't really making copies of another actor/clone. I think you are too caught up in the term clone. Remember clones are created from the CreateActor function. Inheritance on the other hand is where one actor type inherits events from another actor type. So for instance, sword_enemy inherits from base_enemy.

Changed to the "MoveTo" anyway, but there appears an obscure behaviour

I personally avoid MoveTo due to the array of bugs that happened to be associated with it. This is only the case if you have other forces messing with the moving actor's position, such as physical responses.

But just that happens, with "game Center", and also with "view" in the "MoveTo",
the actors are getting displaced a bit in the minus directions.

The same happens with or without any safe margins.

What's going on here, where must I fix ?

Safe margins have nothing to do with this. They are only for out of vision events. And if I understand you right, you are using MoveTo on the view, which means the view is changing positions. If you have the view move right on the screen, everything in view would look like it was moving left.

[digiot]

And soon, we are in a mess of terms...

No, what I mean with "no inheritance" is, that the created actor does not take anything
from its "Creator Actor", except its existence, and the knowledge of its "Creator Actor".
No events, no actions, no positions, nothing.

The clones are sharing actions and animations from its "cloner".

...Remember clones are created from the CreateActor function...

I wasn't aware of that, but from somewhere they must be created, at least there is no
script action like "CloneActor".

Lastly, the parents, which childs are getting their movements from them.

That's, how I understand it yet, hope, I'm on the right track.

I personally avoid MoveTo due to the array of bugs that happened to be associated with it. This is only the case if you have other forces messing with the moving actor's position, such as physical responses.

Hopefully, just an 1-dimensional array !
So, using "MoveTo" on its own is recommended, also with "angel" it may bug ?


But coming to something more serious...:

Safe margins have nothing to do with this...

Yes, but to be on the safe side, I tested it.

...And if I understand you right, you are using MoveTo on the view, which means the view is changing positions...

No, I have fixed the view and the background actor at the game center, their top left
positions are 0,0.

I tried to place a row of button actors with "Create Actor", "MoveTo" and by altering the
x/y values, which all gave me ill success :

With "Create Actor", I had a large x plus, and a medium y minus.

"MoveTo" gave me a little minus each, x and y.

And now the best, with the simplest, most natural approach, changing myactor.x and
myactor.y, nothing happens, the actors don't leave their starting positions !

All the example .geds are working as expected, what I noticed is, that the "snap to
grid" seems not to work properly, but I placed the actors manually on the grid.

How could I have messed up this simple coordinate settings ?

[digiot]

All the buttons are working now, also their actions, but their placement issue resists.

I've tested with the pure x/y from inside the "Event Actor", that works, these actor
was placed where expected.

But the actorname.x/actorname.y don't even move the actors one pixel wide, I have them
in sight.

Do I have to activate the actors in any way, to get access to their actorname.x/actorname.y
coordinate settings from outside of them ?

P.S.: Forgot, the view.x/view.y also doesn't work, but the view obviously changes its position.

[skydereign]

But the actorname.x/actorname.y don't even move the actors one pixel wide, I have them
in sight.

That's because that uses the default actor struct. That can only change one clone's position, usually the actorname.0 (or whatever is the lowest indexed clone).

Lastly, the parents, which childs are getting their movements from them.

Actually they only inherit position. A child actor in gE uses a local coordinate system, where (0,0) is the parent actor's position. So if the parent moves 5 pixels to the right, the child will also move, because its entire coordinate system shifted. The child actors don't register that they were moving with any velocity in this case.

No, what I mean with "no inheritance" is, that the created actor does not take anything
from its "Creator Actor", except its existence, and the knowledge of its "Creator Actor".
No events, no actions, no positions, nothing.

Right. The actor only retains information from the base actor (the actor of the same name defined in the stage). All actors of the same name all have the same events.

And now the best, with the simplest, most natural approach, changing myactor.x and
myactor.y, nothing happens, the actors don't leave their starting positions !

It may be simple, but it just doesn't work in a lot of cases. I definitely would not consider it the best approach. Now that you hopefully understand the distinction between clones and actors, you should realize being more specific is always better. If you mean to target an individual clone, do so. For instance, I see this a lot.
player -> KeyDown right -> Script Editor

Code: Select all

ChangeAnimation("player", "run_right", NO_CHANGE);

The string "player" is not clone specific, as that function would change all player clones animation to run_right. While there probably will never be two player actors at any given time, it is much better to use "Event Actor". There are cases where this is important. Similarly, you are trying to use actorname.x. You should only ever do that if you know that there is only one actorname clone created. Any more and you are probably not doing what you want. You need to specify each clone individually, that way the game actually knows exactly what you are trying to do. I suggest you look into getclone2 and Actor*. Clone specificity is rather important.

P.S.: Forgot, the view.x/view.y also doesn't work, but the view obviously changes its position.

Doesn't work doesn't help me. You have to describe how it doesn't work and what you are trying to do. Also usually it is helpful to see code, as I can see what you are actually doing, and what assumptions you might be getting wrong.

[digiot]

Actually they only inherit position. A child actor in gE uses a local coordinate system, where (0,0) is the parent actor's position. So if the parent moves 5 pixels to the right,
the child will also move, because its entire coordinate system shifted. The child actors
don't register that they were moving with any velocity in this case.

That's exactly what I tried to state.

...The string "player" is not clone specific, as that...

Is "player" one of the inbuild actor names, never saw it ?
Or is it just a custom actor name, as an example ?

...you are trying to use actorname.x...

Yes, but I was not aware, that I can only access clones with actorname.x/actorname.y !

All that cloning stuff I brought up, to distinguish between the different manifestations
of the actors.

I don't like to play around with these more advanced technics, like clones and pointers,
before I have mastered the more basic ones.

So I'm not using clones, because it seems, I need pointers to adress them.

No, I'm just using very simple single actors for everything.
Take my six buttons, every buttons normal and active states are one independent actor,
with two animations.

For the button management, I use an init_actor.

These buttons must not move, I'm only trying to place them one time, and here I have the
posted problems.

Also trying to move the view to another background fails, the view leaves the startscreen,
but does not appear at the intended position, it is sent to nowhere.

The game.ged + data is attached, but be warned ! Since I haven't figured out, how to loop
through clones and actor-arrays, the code is bloated with repetitions, don't spit your coffee through your nose into your keyboard !

P.S.: Nothing is attached, how to ?
I have 2 .geds, game.ged.undo and game.ged, the "undo extension is not allowed" I got !

[skydereign]

That's exactly what I tried to state.

Okay. It sounded like you also meant they inherit movement, which isn't strictly true.

Is "player" one of the inbuild actor names, never saw it ?
Or is it just a custom actor name, as an example ?

It's a custom actor name used for the example. player is a common actor name you'll see in gE examples.

Yes, but I was not aware, that I can only access clones with actorname.x/actorname.y !

All that cloning stuff I brought up, to distinguish between the different manifestations
of the actors.

Right. To reiterate, the default struct actorname only points to the lowest cloneindexed clone. It does not apply to all actors of the same name.

No, I'm just using very simple single actors for everything.
Take my six buttons, every buttons normal and active states are one independent actor,
with two animations.

If that is the case, then the default struct should work just fine.

The game.ged + data is attached, but be warned ! Since I haven't figured out, how to loop
through clones and actor-arrays, the code is bloated with repetitions, don't spit your coffee through your nose into your keyboard !

P.S.: Nothing is attached, how to ?
I have 2 .geds, game.ged.undo and game.ged, the "undo extension is not allowed" I got !

The .ged.undo file is not necessary. Typically if you are posting your game files, you zip up a directory that has the data and game file and upload that.

Also trying to move the view to another background fails, the view leaves the startscreen,
but does not appear at the intended position, it is sent to nowhere.

It really does sound like you have some issues with some actors being parented. I'll have to see in your game though.

[digiot]

It really does sound like you have some issues with some actors being parented.

There should not be any parenting...

Nice, that you will take a look at it.

[skydereign]

Nice, that you will take a look at it.

I don't currently have access to my linux boot, as my computer underwent some technical difficulties that are still being patched up. As such, I don't have a working version of 1.4.1 to load the game file.

[digiot]

Hope, it's nothing serious !
And now, you have no GE at all, or do you have alternativ equipment ?

Here is all going well, I have now solved the problems, what a mess !

Actor positioning : It turns out, that the coordinate system inside GE takes the
centers of its actors as the 0/0-positions, and not, what I suspected, the topleft
corner (home) !

Actor accessing : Really, I had to activate all the button actors with "Activation Events",
to get them alive !

Once you have your maschinery fixed, you might look into the 2 .geds, maybe,
you'll have some fun...

I don't know, is it common practice here, to mark solved threads ?