This is another rewritten tutorial, the original being lost at the database crash a while ago... I think it's a very basic, yet vital thing to know if you're using RMXP, and if newbies won't keep their hands away from the search function, it'll actually help... I hope ^_^ Well, here we go...
Part I :: Introduction
This tutorial's purpose is to show the new RMXP users how to get scripts to work right, and where to place them in the script editor...
Part II :: The Script Editor
The Script Editor is the main place a scripter works... well, as long as he doesn't write scripts in external programs, of course
If you're not a scripter, you most likely have to use it nevertheless, for example if you want to apply a custom script. To access the script editor, click on the option in the menubar (Tools > Script Editor), the icon in the toolbar (third icon from the right / http://img340.imageshack.us/img340/9791/iconge3.png[/img] ), or simply press F11.
If you opened up the editor, you can see several essential parts. First, below the black box showing 'Script', you can see the script list. This shows all scripts in your current project, by default starting with Game_Temp and ending with Main. If you click on an item in the list, the script will show up in the script window on the right, which is pretty big, so you should have problems identifying it... well, the list with the script names only are 'script containers' in a way, for you making the part of scripting easier. In theory, you could copy all scripts from that list into a single container, and they'd still work.
Below the script list, you can see the name box. This is where you can name your script containers, but only them - how you name your scripts has nothing to do with how they work, it's just a tool to ease it up for you.
Finally, thescript editor itself is the big text field on the right, as said above. This is where your scripts are shown. It's not a regular text editor, though, it's specifically designed for a scripting language. Several features like intendation (two spaces) and coloring different functions (take a look at the list below for an explanation of the colors) are included and are very useful for scripters and editors. The colors have the following meanings:
â– Normal coding, like variable names, method names, ...
â– Statements, expressions, tags, ...
â– Mathematical operators, punctuation, ...
â– Comments
â– Strings (surrounded by quotation marks, single or double), also RegExp (regular expression) values
â– Numeric values
A very helpful feature are the several search functions build in: One for searching all scripts at once (right-click on the script list and click on Search, or simply press Ctrl+Shift+F to make the respective window appear) and one for searching the currently show script (right-click into the script editor window and click on Find, or press Ctrl+F). Make sure you use this function whenever you're looking for a specific string, as it not only takes longer to look through every line by yourself, but increases the chance of missing an instance of the searched string.
Part III :: Script Execution
To properly insert a script, you need to put them in the right location. To know what this location is, you need to know in what order the scripts are executed.
As the name says it, Main is the main script everything is about. You can see the two tags 'begin' and 'end' surrounding this scripts' methods. 'begin' is where the first line of script is actually executed (contrary to defining stuff up to that point), so in here, everthing that should be in your game should already be defined. This is why all of the default scripts are above Main - they wouldn't get executed elseway. Aside from knowing that you better place your scripts above the Main script, you can put use of this as you can 'store' scripts below the Main container to temporarily disable them.
Before your game starts, everything in it has to be defined. This includes classes, methods, modules, variables, stuff like that. While your game's running, some of those can be redefined, but most of the coding will stay the same. One way or the other, you need to define each class above Main for reasons explained below. Also, if you want to define something using methods from another class or module (e.g. a superclass or a referenced class or module), you need to have that class and/or module above the script using it. For example, Window_Selectable's superclass is Window_Base (if you select Window_Selectable in the script list, one of the first lines in the script editor you can see is "class Window Selectable < Window_Base", which sets Window_Base as the superclass of Window_Selectable and thus making the methods defined inside Window_Base usuable in Window_Selectable... it's common sense that the methods need to be defined before they can be used, so that's why you have to place Window_Selectable below Window_Base... of course, this isn't the only case).
'begin' and 'end' define what's shown in you game... the thing that first triggers the other scripts in your project is the second line after the 'begin': $scene = Scene_Title.new, which initializes Scene_Title (which you can also find in your script list) and 'starts' the game part of your game. Because the word 'begin' triggers this behaviour, you can of course insert as many main scripts as you like, one after another, everyone only using the scripts already defined up to this point. For RMXP's main purpose - creating RPGs - that doesn't make sense most of the time, though.
Part IV :: Handling Submitted Scripts
There are several things you could get troubles with by trying to integrate a submitted script in your project. There's the correct position of that script, the setup, and the actual call - if needed. Because everything but the first of those strongly depend of the type of script you want to integrate, I'll focus on that first point. I've told a lot of script locations before, but here's specifically what you need to pay attention to...
You might encounter the instruction to 'insert a new script above [a certain script] and paste [a script] in it'. That simply means you right-click on the script list's item that equals [a certain location] and click on 'Insert'. That'll place a new empty script container in the list, directly above the script you clicked on. You might give that script a name (though not necessarily needed, even if the instructions say 'name it Part V :: Script Compatibility
In general, scripts are compatible to eachother as long as every method, class, module, and variable only appaer once. If that is not the case, several scripts might want to use the same methods, which are only specifically written in order to work with one of those. For example, if two of your integrated scripts define the method this_is_an_example, the one below the other will overwrite the one above. Because you don't insert methods for fun, of course, one of your scripts using that method will not use the first one, which is specifically designed for the script, but the second one, which belongs to another one. This may cause errors, and you'd need to merge those scripts - i.e. combine the functions of each method - to work with each other. Simply renaming the method (and also change the referer, of course) will suffice, too, but you should take advantage of the search function to make sure you didn't miss a method call. All in all, you shouldn't use more than one script for one and the same purpose, e.g. two custom battlesystems, because even if they wouldn't use the same methods or similar, you couldn't use two battle systems at the time anyway.
An easy way is to alias scripts, which means that only the part of the method neede dto be changed actually is changed, while the rest of the method can still be whatever it needs to be, even the default. Aliased scripts will have a higher compatibility change compared to unaliased scripts. There are a couple of aliasing tutorials out there, so if you want to merge scripts or increase their compatibility chances, check Me(tm)'s Aliasing Tutorial or vgvgf's Aliasing Tutorial, which is for advanced users, though.
Another thing I need to mention if I talk about compatibility is of course the SDK developed by some skilled RMXP users, which purpose is to increase script compatibility. Refer to the SDK Thread for more information.
Part VI :: Conclusion
That's it for now, the basics are covered. If anyone has something in mind that could be added, please feel fre to say so. I'd also like to get feedback on how understandable that tutorial is, as that's a basic necessity for it to be effective in it's purpose. Of course, I don't mind you just saying "Man, that's one nice tutorial you have there" ^_^
Thanks for the attention!
Part VII :: See Also...
Trickster's General Scripting Conventions Tutorial
BlueScope's Script Commenting">
Part I :: Introduction
This tutorial's purpose is to show the new RMXP users how to get scripts to work right, and where to place them in the script editor...
Part II :: The Script Editor
The Script Editor is the main place a scripter works... well, as long as he doesn't write scripts in external programs, of course
If you're not a scripter, you most likely have to use it nevertheless, for example if you want to apply a custom script. To access the script editor, click on the option in the menubar (Tools > Script Editor), the icon in the toolbar (third icon from the right / http://img340.imageshack.us/img340/9791/iconge3.png[/img] ), or simply press F11.If you opened up the editor, you can see several essential parts. First, below the black box showing 'Script', you can see the script list. This shows all scripts in your current project, by default starting with Game_Temp and ending with Main. If you click on an item in the list, the script will show up in the script window on the right, which is pretty big, so you should have problems identifying it... well, the list with the script names only are 'script containers' in a way, for you making the part of scripting easier. In theory, you could copy all scripts from that list into a single container, and they'd still work.
Below the script list, you can see the name box. This is where you can name your script containers, but only them - how you name your scripts has nothing to do with how they work, it's just a tool to ease it up for you.
Finally, thescript editor itself is the big text field on the right, as said above. This is where your scripts are shown. It's not a regular text editor, though, it's specifically designed for a scripting language. Several features like intendation (two spaces) and coloring different functions (take a look at the list below for an explanation of the colors) are included and are very useful for scripters and editors. The colors have the following meanings:
â– Normal coding, like variable names, method names, ...
â– Statements, expressions, tags, ...
â– Mathematical operators, punctuation, ...
â– Comments
â– Strings (surrounded by quotation marks, single or double), also RegExp (regular expression) values
â– Numeric values
A very helpful feature are the several search functions build in: One for searching all scripts at once (right-click on the script list and click on Search, or simply press Ctrl+Shift+F to make the respective window appear) and one for searching the currently show script (right-click into the script editor window and click on Find, or press Ctrl+F). Make sure you use this function whenever you're looking for a specific string, as it not only takes longer to look through every line by yourself, but increases the chance of missing an instance of the searched string.
Part III :: Script Execution
To properly insert a script, you need to put them in the right location. To know what this location is, you need to know in what order the scripts are executed.
As the name says it, Main is the main script everything is about. You can see the two tags 'begin' and 'end' surrounding this scripts' methods. 'begin' is where the first line of script is actually executed (contrary to defining stuff up to that point), so in here, everthing that should be in your game should already be defined. This is why all of the default scripts are above Main - they wouldn't get executed elseway. Aside from knowing that you better place your scripts above the Main script, you can put use of this as you can 'store' scripts below the Main container to temporarily disable them.
Before your game starts, everything in it has to be defined. This includes classes, methods, modules, variables, stuff like that. While your game's running, some of those can be redefined, but most of the coding will stay the same. One way or the other, you need to define each class above Main for reasons explained below. Also, if you want to define something using methods from another class or module (e.g. a superclass or a referenced class or module), you need to have that class and/or module above the script using it. For example, Window_Selectable's superclass is Window_Base (if you select Window_Selectable in the script list, one of the first lines in the script editor you can see is "class Window Selectable < Window_Base", which sets Window_Base as the superclass of Window_Selectable and thus making the methods defined inside Window_Base usuable in Window_Selectable... it's common sense that the methods need to be defined before they can be used, so that's why you have to place Window_Selectable below Window_Base... of course, this isn't the only case).
'begin' and 'end' define what's shown in you game... the thing that first triggers the other scripts in your project is the second line after the 'begin': $scene = Scene_Title.new, which initializes Scene_Title (which you can also find in your script list) and 'starts' the game part of your game. Because the word 'begin' triggers this behaviour, you can of course insert as many main scripts as you like, one after another, everyone only using the scripts already defined up to this point. For RMXP's main purpose - creating RPGs - that doesn't make sense most of the time, though.
Part IV :: Handling Submitted Scripts
There are several things you could get troubles with by trying to integrate a submitted script in your project. There's the correct position of that script, the setup, and the actual call - if needed. Because everything but the first of those strongly depend of the type of script you want to integrate, I'll focus on that first point. I've told a lot of script locations before, but here's specifically what you need to pay attention to...
You might encounter the instruction to 'insert a new script above [a certain script] and paste [a script] in it'. That simply means you right-click on the script list's item that equals [a certain location] and click on 'Insert'. That'll place a new empty script container in the list, directly above the script you clicked on. You might give that script a name (though not necessarily needed, even if the instructions say 'name it Part V :: Script Compatibility
In general, scripts are compatible to eachother as long as every method, class, module, and variable only appaer once. If that is not the case, several scripts might want to use the same methods, which are only specifically written in order to work with one of those. For example, if two of your integrated scripts define the method this_is_an_example, the one below the other will overwrite the one above. Because you don't insert methods for fun, of course, one of your scripts using that method will not use the first one, which is specifically designed for the script, but the second one, which belongs to another one. This may cause errors, and you'd need to merge those scripts - i.e. combine the functions of each method - to work with each other. Simply renaming the method (and also change the referer, of course) will suffice, too, but you should take advantage of the search function to make sure you didn't miss a method call. All in all, you shouldn't use more than one script for one and the same purpose, e.g. two custom battlesystems, because even if they wouldn't use the same methods or similar, you couldn't use two battle systems at the time anyway.
An easy way is to alias scripts, which means that only the part of the method neede dto be changed actually is changed, while the rest of the method can still be whatever it needs to be, even the default. Aliased scripts will have a higher compatibility change compared to unaliased scripts. There are a couple of aliasing tutorials out there, so if you want to merge scripts or increase their compatibility chances, check Me(tm)'s Aliasing Tutorial or vgvgf's Aliasing Tutorial, which is for advanced users, though.
Another thing I need to mention if I talk about compatibility is of course the SDK developed by some skilled RMXP users, which purpose is to increase script compatibility. Refer to the SDK Thread for more information.
Part VI :: Conclusion
That's it for now, the basics are covered. If anyone has something in mind that could be added, please feel fre to say so. I'd also like to get feedback on how understandable that tutorial is, as that's a basic necessity for it to be effective in it's purpose. Of course, I don't mind you just saying "Man, that's one nice tutorial you have there" ^_^
Thanks for the attention!
Part VII :: See Also...
Trickster's General Scripting Conventions Tutorial
BlueScope's Script Commenting">