KungFuCharlie
Member
This site has been a great resource for digging into ArmA2 scripting and modding DayZ servers. There are a lot of good ideas and well implemented modifications floating around. After digging through the site for a few weeks and implementing various mods (either as a copy/paste or re-writing a mod from scratch because I didn't like how it was implemented), I came up with a list of things that I think will make the quality of the mods being released even better.
It is my hope that this will get stickied and others will list their suggestions as well since I definitely do not have all the answers (I'll try to edit this post to add any good suggestions to the list as the thread grows). But, being the Internet, there is a significant chance that this could result in a massive flame war and a locked thread. We shall see which way this one goes...
Note: I'm going to start posting my scripts / mods soon so be sure to give me a hard time when I don't follow my own suggestions.
Server Admins
Suggestion #1: Learn at least the basics of ArmA scripting and how the game engine / mod interface is architected before trying to add any mods your servers. This will eliminate so much of your frustration and server down time trying to get things to work. Mod writers want to spend their time coding and making really cool features come to life, not holding your hands walking you through the fixes to very simple problems. CommanderRetra already simplified doing exactly this; read / watch every Guide and Specific Guide he listed in this thread: http://opendayz.net/threads/arma-scripting-guides-examples-tools-and-resources.11313/
Suggestion #2: When you post a reply to a mod thread asking for help installing it, list all the things that you've already tried doing. No one wants to help someone who didn't first put forth any effort to figure it out on their own. Make people want to help you!!
Suggestion #3: When you post a reply to a mod thread stating that it doesn't work on your server, provide as much information as possible to include your server DayZ version, any other mods you're running, detailed in-game actions and results from those actions indicating there is a problem, and most importantly any errors or related entries from your server log files. Make it easy for people to help you!!
Mod Writers
Suggestion #1: Write your code such that it is very easy for people to read and figure out what it does. This will decrease the amount of support you need to provide for your mods as it will be much easier for people to figure out and fix any problems they are having themselves. The best practices that will accomplish this are as follows.
Suggestion #3: Optimise your code!! Read this (Code Optimisation) and then live by it!!
Suggestion #4: Update your original post (#1 post in the thread) whenever you release bug fixes or any other modifications to your code. On more than one occasion I've seen bug fixes posted many pages down in the thread but the code in the first post (what everyone grabs first) was not updated. That led to questions about the bug being left AFTER the bug fix was already posted because the server admin missed the post with the bug fix in it.
Suggestion #5: Track versions of your mod files and list the version at the top of every script in a comment file header along with the change log (with date of release), credit for any derived work, and so forth. Again, Krixes self blood bag script is a decent example of this. If you don't know what I mean, just use the following template with your mod information in it.
Suggestion #6: For the first version or two of your script, put diag_log calls with descriptive messages into the code wherever actions are being conducted or complex code is being run. This way if a server admin has a problem running your script, they can post not only any error messages that appear in their log but also any of your debug messages as well to help you troubleshoot the problem.
Beginning Mod Writers
Suggestion #1: Go through every Guide and Specific Guide that CommanderRetra listed in this thread (http://opendayz.net/threads/arma-scripting-guides-examples-tools-and-resources.11313/) multiple times until you understand them fully.
Suggestion #2: When you're implementing or changing someone else's mod, do not use their files or copy/paste into a new file. Go through each line of their script and type it manually into your own file. As you do this, look up every function and scripting command that is used in the ArmA2 Scripting Command list on BI's wiki and understand what it does, what its argument are, what data it returns, and so forth.
Suggestion #3: Follow the suggestions listed above for mod writers when you start implementing your own mods.
It is my hope that this will get stickied and others will list their suggestions as well since I definitely do not have all the answers (I'll try to edit this post to add any good suggestions to the list as the thread grows). But, being the Internet, there is a significant chance that this could result in a massive flame war and a locked thread. We shall see which way this one goes...
Note: I'm going to start posting my scripts / mods soon so be sure to give me a hard time when I don't follow my own suggestions.
Server Admins
Suggestion #1: Learn at least the basics of ArmA scripting and how the game engine / mod interface is architected before trying to add any mods your servers. This will eliminate so much of your frustration and server down time trying to get things to work. Mod writers want to spend their time coding and making really cool features come to life, not holding your hands walking you through the fixes to very simple problems. CommanderRetra already simplified doing exactly this; read / watch every Guide and Specific Guide he listed in this thread: http://opendayz.net/threads/arma-scripting-guides-examples-tools-and-resources.11313/
Suggestion #2: When you post a reply to a mod thread asking for help installing it, list all the things that you've already tried doing. No one wants to help someone who didn't first put forth any effort to figure it out on their own. Make people want to help you!!
Suggestion #3: When you post a reply to a mod thread stating that it doesn't work on your server, provide as much information as possible to include your server DayZ version, any other mods you're running, detailed in-game actions and results from those actions indicating there is a problem, and most importantly any errors or related entries from your server log files. Make it easy for people to help you!!
Mod Writers
Suggestion #1: Write your code such that it is very easy for people to read and figure out what it does. This will decrease the amount of support you need to provide for your mods as it will be much easier for people to figure out and fix any problems they are having themselves. The best practices that will accomplish this are as follows.
- Format your code to match the coding standard of all the built-in standard scripts. Please, for all of our sakes, indent your code properly!!
- Comment your code! Remember that code comments are normally not for you but for the people who have to use your code. Don't just comment what the code is doing... also comment WHY you've implemented it the way you have. A very good example of commenting what the code is doing is Krixes self blood bag script. A few more comments mixed in detailing the WHY would make it a perfect example all around. But so far it is the best one on this site I've found so far in terms of code commenting practices.
- Give your variables descriptive names. Instead of _ctr use _counter. In one mod I saw someone using _countr in multiple scripts. Why leave out just one letter? It accomplishes nothing! To go one step further, instead of just _counter you should use a name that describes what the counter is for. Another example is the use of _unit, _oldUnit, and _newUnit. A better option would be to use _oldDeadBodyToDelete and _newDeadBodyToSpawn.
- Don't name your variables and scripts after yourself. That is just ego and not helpful in keeping your code clean and readable for others. The sooner you grow out of that the sooner you will be viewed as a professional (which could land you a really good engineering job in the future if you don't already have one).
Suggestion #3: Optimise your code!! Read this (Code Optimisation) and then live by it!!
Suggestion #4: Update your original post (#1 post in the thread) whenever you release bug fixes or any other modifications to your code. On more than one occasion I've seen bug fixes posted many pages down in the thread but the code in the first post (what everyone grabs first) was not updated. That led to questions about the bug being left AFTER the bug fix was already posted because the server admin missed the post with the bug fix in it.
Suggestion #5: Track versions of your mod files and list the version at the top of every script in a comment file header along with the change log (with date of release), credit for any derived work, and so forth. Again, Krixes self blood bag script is a decent example of this. If you don't know what I mean, just use the following template with your mod information in it.
Code:
//--------------------------------------------------------------------------
// Title or name of this script - [title of the mod that this script is part of]
// High level description of the features that this specific script implements (i.e. what it does).
//
// DayZ Version(s): list dayz versions and maps that this script has been tested and proven to work on
//
// Author: Name (your contact info)
// Mod Info: Link to a page with information about the mod and install instructions
//
// Contributors:
// List any contributors or people you want to thank for helping with it
//
// Change Log:
// Version x.y.z [July 06, 2013]
// Indented list of things changed in this version
// Version x.y.z-1 [June 01, 2013]
// And so on for each previous version
//--------------------------------------------------------------------------Suggestion #6: For the first version or two of your script, put diag_log calls with descriptive messages into the code wherever actions are being conducted or complex code is being run. This way if a server admin has a problem running your script, they can post not only any error messages that appear in their log but also any of your debug messages as well to help you troubleshoot the problem.
Beginning Mod Writers
Suggestion #1: Go through every Guide and Specific Guide that CommanderRetra listed in this thread (http://opendayz.net/threads/arma-scripting-guides-examples-tools-and-resources.11313/) multiple times until you understand them fully.
Suggestion #2: When you're implementing or changing someone else's mod, do not use their files or copy/paste into a new file. Go through each line of their script and type it manually into your own file. As you do this, look up every function and scripting command that is used in the ArmA2 Scripting Command list on BI's wiki and understand what it does, what its argument are, what data it returns, and so forth.
Suggestion #3: Follow the suggestions listed above for mod writers when you start implementing your own mods.