Difference between revisions of "Scripting for Beginners"
Jump to navigation
Jump to search
→Comments: I can't believe that I forgot to mention comments...
imported>Cipscis m (Minor cleanup. Major thanks to BonzoFSP for translating this to Wiki markup!) |
imported>Cipscis (→Comments: I can't believe that I forgot to mention comments...) |
||
| Line 242: | Line 242: | ||
As you can see, [[GetIsReference]] is called by the reference that has its RefID stored in our rContainer variable, and uses the refID that it is being compared against as a parameter. For this function, we could swap these two around (e.g. "player.GetIsReference rContainer) and it would work just fine. | As you can see, [[GetIsReference]] is called by the reference that has its RefID stored in our rContainer variable, and uses the refID that it is being compared against as a parameter. For this function, we could swap these two around (e.g. "player.GetIsReference rContainer) and it would work just fine. | ||
==Comments== | |||
As your scripts become longer and more complex, they may become difficult to follow. In order to help make scripts easy to understand, it is important to annotate them using comments. Comments are basically text that is part of the script's source code, but is completely ignored by the compiler - it has no effect whatsoever on how a script works. | |||
Comments in Fallout 3 scripts are specified by the use of a semicolon (;) - all text on a line that comes after a semicolon is a comment, and will be ignored by the compiler. This type of comment is known as a line comment, as the comment extends from the specifying character to the end of the line. Many other computer languages also allow a type of comment known as a block comment, where another specifying character or string is used to signify the end of a comment, but Fallout 3 scripts do not allow this. | |||
One particularly useful way to utilise comments is to explain what a certain value represents. For example, the function [[GetOpenState]] uses different values to represent different "open states" of a door. On their own, they do not particularly make sense, so it is usually a good idea to use a comment to explain the meaning of the value. For example: | |||
if GetOpenState == 3 ; Closed | |||
... | |||
elseif GetOpenState == 4 ; Closing | |||
... | |||
endif | |||
As you can see, the comments here help to explain the true meaning of the conditions. If the comments were absent, then someone reading the script would need to look up the documentation of [[GetOpenState]] in order to understand what the conditions really mean. The same concept applies to variables - if you use a variable in which different values represent different states, it is a good idea to use comments when you declare the variable in order to explain what each value represents. | |||
Another good way to use comments is to describe the function of a script. For example, if you have a script that uses some complicated calculations to place a reference in front of the player, then it would be a good idea to explain this in a comment at the top of the thread. That way, anyone reading the thread will only have to read this comment, instead of trying to understand your calculations in order to determine how they work. | |||
Whenever you write scripts, you should always annotate them wherever you think it is necessary. If you think that any part of your script would benefit from a little explanation, don't hesitate to add a comment nearby. Even if it's only one or two words - a little clarification can go a long way, and scripts that don't contain any comments can sometimes take a long time to fully understand. | |||
==Glossary== | ==Glossary== | ||