"self" in CRPL

Started by Grauniad, February 07, 2013, 11:26:43 AM

Previous topic - Next topic

Grauniad

Can you please give a verbose description of this code snippet from the image rotation example?


$imageToRotate:"main"

# Make a part spin around
Self <-imageToRotate GetImageRotation ->currentRotation


Does "main" have a meaning in relation to the current core, or ...

If I'm running the code in a specific core, why do I need the "self" assignment?
A goodnight to all and to all a good night - Goodnight Moon

UpperKEES

It's not an assignment. GetImageRotation just needs a UID as its first argument and in this case you pass the UID of the core calling this function. If you would write it in Warp notation it would be:

GetImageRotation(Self <-imageToRotate) ->currentRotation
My CW1 maps: downloads - overview
My CW2 maps: downloads - overview

knucracker

Yeah, those image functions can operate on any CRPLCore you have the UID for, so "self" just returns the UID of the current unit.

All images attached to a CRPLCore have a name.  You can add more images and call them anything like you like ("beam", "thing", "radar", etc.)  If you call one "main" all that means is that you are manipulating the same image that the game's editor let's you set.

When you double click a CRPLcore to edit it, there is an image you can set using the game's editor (no scripting needed).  The name of that image is "main" from the scripts perspective.  The reason I do this is to allow folks to change the image of a core using just the game editor and not have to crack open some code to do it.  But naturally you want to be able to access this same image from the script, so I auto name that image set by the game's editor to "main".  Other than this, that "main" image is no more special than any other image you might attach to a core.

Lastly, the reason that "main" is a good default value for the input var on the ImageRotation example script is that much of the time a map maker might just create a core, pick an image for the core using the game's combo box, then attach the ImageRotation script.  In that simple case, the only  image attached to the core is "main", so that is exactly what you want the script to rotate.


Grauniad

OK, let me see if I have it. "main" is just a name, it's not anything like the "main" in Java or C.

The "self" overrides that with the UID of the executing core.

Right?
A goodnight to all and to all a good night - Goodnight Moon

knucracker

They are two separate arguments in this example, though you are right that "main" is just a name.

So:
Self "main" GetImageRotation
or
GetImageRotation(Self "main")

This means to get the rotation of the image called "main" on the current core.

Take the following example:

"CRPLCORE" 10 10 CreateUnit ->unitUID
<-unitUID "main" GetImageRotation


This creates a new Core at coordinates 10,10 on the map.  The UID of that new core is storesd in "unitUID".  The second line gets the rotation of the image called "main" on that newly created core.

So argument 1 is the UID of some core,  argument 2 is the name of an attached image.


Grauniad

OK wait, so you have named images. And one rotates the named image on the UID... I think I have it.
A goodnight to all and to all a good night - Goodnight Moon

knucracker

Exactly....

There could be another image attached to a core called "barrel", and you might want to move or rotate that image.  In fact there might be 10 images all with different names attached to one core (like legs on a walker).  The only thing special about the image called "main" is that it is there by default when you make a new core, and you can change it using the game's editor.

While I'm at it, that this more advanced example:


$RATE:0.1

do (GetCoresWithVar("ShouldRotate" TRUE) 0)
->unitUID
GetImageRotation(<-unitUID "main") ->currentRotation
SetImageRotation(<-unitUID "main" <-currentRotation add(<-RATE))
loop


You can attach this script to a single core in the game. Perhaps this core doesn't have an image, doesn't take map space, and also doesn't interact in any way with units (you can set all of that using the game's editor for a core).  This script looks at all cores on the map looking for ones that have a variable called "ShouldRotate" on any script that is set to a value of true.  If so, this script will rotate that unit's main image.

This is an example of a master script that controls the look of a bunch of other objects. 

This is another topic, but it is also an example of a complex return value since GetCoresWithVar returns multiple items on the stack.