05.04.2017, 00:35
(
Last edited by iiNzTicTx; 05/04/2017 at 01:47 AM.
)
These concepts will help with other languages as well.
SAMP has a bad history for many terrible scripts, mostly the first gamemodes till it was later introduced: organization and efficiency. This thread outlines the challenges in PAWN. Yeah, this thread is probably a bit late, but I'm sure some may still benefit from it.
The following threads/posts are useful to get your head around before starting any major script.
https://sampforum.blast.hk/showthread.php?tid=570883 (y_hooks)
https://sampforum.blast.hk/showthread.php?tid=580289 (efficiency)
http://forum.sa-mp.com/showpost.php?...27&postcount=6 (organization)
http://forum.sa-mp.com/showpost.php?...8&postcount=12 (organization #2)
https://sampwiki.blast.hk/wiki/Debugging (debugging)
https://sampforum.blast.hk/showthread.php?tid=631607 (naming conventions)
Things to consider for efficiency:
1) how may I minimize the amount of steps in a loop?
Examples: only loop through the amount of players that are online, rather than all possible player slots. Loops are generally a big problem as the longer the loop takes the longer the server hangs. Another approach is to remember how many houses have been modified: then only saving the houses that contain modified data (I use this for x so on average only a few houses save instead of 500, every x).
2) consider using more variables to eliminate more use of loops for example storing the player's house ID in some player variable, rather than looping through every house to find the owner.
Things to consider for testing & how bugs arise:
1) debugging is important. Debugging each section of code you've worked on will allow you to gain understanding of how the script works. Personally I use YSF to send "console messages" ingame, as one example provided with YSF contains a command: /consolemsgs (as it adds the "ability to send console messages to players").
2) Keep code simple. Simple code can be understood by others, also follow the a consistent organized method to your code layout so others can navigate without hassle. Otherwise, miscommunication can cause bugs.
3) Reduce repetition. Reducing repetition will reduce the amount of code a developer would have to update if something changes, and if they missed something, this would also cause bugs. A rough example would be to use functions rather than repeat, or loops.
For a vehicle system a function: DestroyPlayerVehicle is called many times through commands or other functions, it saves the vehicle data before destroying it and resets the appropriate variables. I'd consider this a core function belonging to a main script file, as other functions depend upon it (see "Organization"). Much better than having lines of code that do the same thing!
Things to consider for organization:
1) creating new project folders, for a new system such as a fire system. Then corresponding files that have meaningful names such that you would know exactly where a function should be when you're looking for it. Example file structure:
/firesys
-> commands
->->putout.inc
->->create.inc
->->admin.inc
-> main.inc (saving/loading/managing core functions, variable data & definitions)
-> hooks.inc (hooking callbacks)
In other words the project is split into categories, such that each category contains a reasonable amount, and makes it easy to navigate around, is user friendly for other developers and is easy to develop. Using "static" can avoid namespace error as this changes the scope to the current file, or function.
2) use a different editor to pawno, I would recommend notepad++ (tutorial) and it's important to take advantage of the "folder workspace" feature that allows you to display files/folders in a defined project folder.
Using organization methods can keep you focused on your current project, rather than having a ton of irrelevant code in the same file.
3) comments & documentation: what will this loop accomplish at each iter (loop invariant), what should be accomplished at the end of this function (post condition), what variables or input data is being passed to the function (precondition) and what is it used for? Comments can help others understand your code, but also yourself. Don't forget to use headers, I just use a ASCII generator, and assure they can be read, rather than looking cool.
4) separating log files, always good having a separate file for debugging especially. Many issues arise otherwise such as a large log file to search, or of containing irrelevant logs to what you're looking for.
oneOCT3T (iiNzTicTx).
SAMP has a bad history for many terrible scripts, mostly the first gamemodes till it was later introduced: organization and efficiency. This thread outlines the challenges in PAWN. Yeah, this thread is probably a bit late, but I'm sure some may still benefit from it.
The following threads/posts are useful to get your head around before starting any major script.
https://sampforum.blast.hk/showthread.php?tid=570883 (y_hooks)
https://sampforum.blast.hk/showthread.php?tid=580289 (efficiency)
http://forum.sa-mp.com/showpost.php?...27&postcount=6 (organization)
http://forum.sa-mp.com/showpost.php?...8&postcount=12 (organization #2)
https://sampwiki.blast.hk/wiki/Debugging (debugging)
https://sampforum.blast.hk/showthread.php?tid=631607 (naming conventions)
Things to consider for efficiency:
1) how may I minimize the amount of steps in a loop?
Examples: only loop through the amount of players that are online, rather than all possible player slots. Loops are generally a big problem as the longer the loop takes the longer the server hangs. Another approach is to remember how many houses have been modified: then only saving the houses that contain modified data (I use this for x so on average only a few houses save instead of 500, every x).
2) consider using more variables to eliminate more use of loops for example storing the player's house ID in some player variable, rather than looping through every house to find the owner.
Things to consider for testing & how bugs arise:
1) debugging is important. Debugging each section of code you've worked on will allow you to gain understanding of how the script works. Personally I use YSF to send "console messages" ingame, as one example provided with YSF contains a command: /consolemsgs (as it adds the "ability to send console messages to players").
2) Keep code simple. Simple code can be understood by others, also follow the a consistent organized method to your code layout so others can navigate without hassle. Otherwise, miscommunication can cause bugs.
3) Reduce repetition. Reducing repetition will reduce the amount of code a developer would have to update if something changes, and if they missed something, this would also cause bugs. A rough example would be to use functions rather than repeat, or loops.
For a vehicle system a function: DestroyPlayerVehicle is called many times through commands or other functions, it saves the vehicle data before destroying it and resets the appropriate variables. I'd consider this a core function belonging to a main script file, as other functions depend upon it (see "Organization"). Much better than having lines of code that do the same thing!
Things to consider for organization:
1) creating new project folders, for a new system such as a fire system. Then corresponding files that have meaningful names such that you would know exactly where a function should be when you're looking for it. Example file structure:
/firesys
-> commands
->->putout.inc
->->create.inc
->->admin.inc
-> main.inc (saving/loading/managing core functions, variable data & definitions)
-> hooks.inc (hooking callbacks)
In other words the project is split into categories, such that each category contains a reasonable amount, and makes it easy to navigate around, is user friendly for other developers and is easy to develop. Using "static" can avoid namespace error as this changes the scope to the current file, or function.
2) use a different editor to pawno, I would recommend notepad++ (tutorial) and it's important to take advantage of the "folder workspace" feature that allows you to display files/folders in a defined project folder.
Using organization methods can keep you focused on your current project, rather than having a ton of irrelevant code in the same file.
3) comments & documentation: what will this loop accomplish at each iter (loop invariant), what should be accomplished at the end of this function (post condition), what variables or input data is being passed to the function (precondition) and what is it used for? Comments can help others understand your code, but also yourself. Don't forget to use headers, I just use a ASCII generator, and assure they can be read, rather than looking cool.
4) separating log files, always good having a separate file for debugging especially. Many issues arise otherwise such as a large log file to search, or of containing irrelevant logs to what you're looking for.
oneOCT3T (iiNzTicTx).
