Author Topic: Package/Parent Syntax Tutorial  (Read 32886 times)

Uh whoops, use ::autoAdminCheck instead...



Is there any way we might be able to protect our own functions created in scripts from being packaged, or is that unique to functions written in C++ that have been exposed to the scripting engine?
« Last Edit: December 08, 2009, 05:40:35 PM by BobAndRob »

Is there any way we might be able to protect our own functions created in scripts from being packaged, or is that unique to functions written in C++ that have been exposed to the scripting engine?
Pointless, someone can just read your code, extract said function, and overwrite your function altogether with their new methods.

Pointless, someone can just read your code, extract said function, and overwrite your function altogether with their new methods.
There are certain functions which we can not redefine, regardless of whether it's in a package or not, like the auth stuff.

I'm not just talking about protecting them from being packaged, but overwritten in any way.

This is very important and caused me hours of frustration:

Wrong (capitalized package):
Code: [Select]
Package mypackage
{
};

Correct (no capitalization in the word package):
Code: [Select]
package mypackage
{
};
Note that the correct one did not capitalize package. Apparently, this is case sensitive.


No, this isn't a bump, it's a sticky. Just thought someone might be having the same problem.

What do you mean by code blocks?

Code Blocks is code contained inside { and } characters.

Also, function != method
function = normal function
method = function that is in the namespace of a object

method = function that is in the namespace of a object
function GameConnection::autoAdminCheck(%this)

:cookieMonster:


We all want to be able to make our own modifications to Blockland, whether to add new features, set or work around limitations, or change the way the game is played.  The problem is that all of the code that controls game play is stored in encrypted files.  One great feature that Blockland, and the Torque Game Engine it's based on, supports is encapsulation.  For those of you that are new to programming, encapsulation at its most basic level means storing one item within another.  Take a plastic Easter egg for example.  The plastic egg is the container (the 'Parent') and the pieces of candy within are its children.  You can't really change the way the egg (or 'Parent') works without destroying it, but you can change its candy (or children).

In Blockland, the Parent is the main game code.  All the code stored in those .dso files cannot be changed.  Now, when someone creates normal add-on code that does not overwrite any of the game's built-in functions, the creator's code becomes part of the main game code.  If you overwrite a built-in function (serverCmdPlantBrick), you might lose a very important piece of functionality.

How do we get around this?  Packages!  Here's an example package:

Code: [Select]
package NewPackage
{
function paintProjectile::onCollision(%this,%obj,%col,%fade,%pos,%normal)
{
                <any special actions you want performed when this projectile collides>
Parent::onCollision(%this,%obj,%col,%fade,%pos,%normal);
}
};

In the above example, our NewPackage includes a method that adds to functionality of the paint can's projectile collision.  Note that, after inserting our own, new code, we call the Parent (main game code) to run its normal collision code.  We pass to the Parent::onCollision() method the exact same number of parameters that our method receives.

Now, before you run off to try this on your own, there's one very important line of code you'll need to add here:

Code: [Select]
activatePackage(NewPackage);
Packages in Blockland or TGE can be enabled or disabled using activatePackage(<package name>) or deactivatePackage(<package name>).  If a package if not activated, you cannot make use of its specialized methods.

Well, those are the basics.  Just remember:

Parent (main game code.)
{
     Packages (collections of our methods that extend the ones built into the game.)
     {
          Methods (individual functions that we create.  must call Parent to retain original functionality.)
     }
}
    is how you do it

Thanks this helped a lot.



Nice copypasta from Mr. Wallet's scripting class.
More like the first reply to this thread

More like the first reply to this thread
Oh wow, person didn't know how to quote