UGX-Mods Login

or login with an authentication provider below
Sign In with Google
Sign In with Twitter
Sign In with Discord
Sign In with Steam
Sign In with Facebook
Sign In with Twitch

Abnormal202 Scripting Tutorial 6: Properties

broken avatar :(
Created 6 years ago
by qwerty195
0 Members and 1 Guest are viewing this topic.
1,155 views
broken avatar :(
×
broken avatar :(
Location: usU.S.A! U.S.A!
Date Registered: 10 June 2015
Last active: 3 years ago
Posts
86
Respect
Forum Rank
Rotting Walker
Primary Group
Community Mapper
My Groups
More
My Contact & Social Links
More
Personal Quote
Abnormal202
Signature
-Abnormal202
×
qwerty195's Groups
Community Mapper Has released one or more maps to the UGX-Mods community which have been added to the UGX Map Manager.
ABNORMAL202 SCRIPTING TUTORIAL 6: PROPERTIES
See ALL Tutorials

DESCRIPTION

Properties are very similar to variables, and I probably would've talked about them in the variables tutorial, however I thought that one was long enough and didn't want to overwhelm.

Properties are just more ways we can store information into a variable, and you'll see them quite a lot.


CREATING A PROPERTY

You can create a property on a variable simply by putting a "." at the end of it and then adding the name to your property, and finally defining it.

andrew = GetEnt("andrew","targetname");

andrew.gender = "male";
In the above example, I made a variable andrew (with some ent in radiant stored in it), and then gave it the property of "gender", which I defined as "male".
Just like with variables, properties can store numbers, strings, booleans, and even entities.
andrew.clip = GetEnt("andrew_clip","targetname");
We can do all the same things we can do with variables with properties. For example using in functions:
andrew.clip Delete();
It's important to note if this code was executed, the entity in radiant with targetname: "andrew_clip" would be deleted, not the entity with targetname: "andrew", because the property is being sent to the Delete() function, not the actual andrew variable.
Properties are also often used to check for certain conditions in If Statements:
if(isdefined(andrew.gender) && andrew.gender == "male")
{
   IPrintLnBold("By golly, you're a man!");
}
Really the sky is limit. You can even make properties of properties:
andrew = GetEnt("andrew","targetname");
andrew.clothing = "on";
andrew.clothing.top = "t_shirt";
andrew.clothing.top.color = "red";
It should be noted that passing a variable that has properties on it will retain all properties on it in the function it is being passed to.
for example:
   andrew = GetEnt("andrew","targetname");
   andrew.clothing = "on";
   andrew.clothing.top = "t_shirt";
   andrew.clothing.top.color = "red";
   andrew thread clothing_appraisal();
}
function clothing_appraisal()
{
   if(isdefined(self.clothing) && self.clothing == "on")
   {
      if(isdefined(self.clothing.top) && self.clothing.top == "t_shirt")
      {
         if(isdefined(self.clothing.top.color) && self.clothing.top.color == "red")
         {
            IPrintLnBold("I think red looks rather nice on you");
         }
      }
   }
}

LEVEL PROPERTIES

Remember that variable I talked about earlier, that can be accessed from anywhere and is the same entity according to all scripts? that variable is called level, and there's a reason Sublime highlights it in purple.
Because it's the same everywhere, setting properties on the level variable makes it easy to access said properties wherever, from any script/function/you name it. Using level properties is the quick & easy solution to passing data, without having to call, thread, or pass arguments.
However there's a reason I've introduced this a bit late, in tutorial #6, because I see a lot of novice scripters overuse to death the level properties, myself included. Because of how easy it was to use, I used it for a bunch of things that using self, or arguments would have done fine for, and that led to me not knowing how to pass data in other ways than level properties.
Other than that, Why shouldn't you use level properties?
- You don't want to accidentally create a property that has the same name as one already defined in Treyarch scripts, as you could really break stuff by overriding a Treyarch property, or having yours overridden. (though this is also a problem with setting properties on players, or any common entity that's going to be in the game regardless of the map)
- Setting tons of level properties (for things that don't need it) can make your scripts a lot harder to follow, for other people or yourself later. 
See ALL Tutorials


 
Loading ...