SA-MP Forums - Tutorials

[Tutorial] Virtual world and interior system explanation

CreativityLacker — Sun, 19 May 2013 10:47:16 GMT

Virtual world
and
interior system

NOTE: This tutorial is a sequel/prequel to the Coordinate-system-explanation

1. Interiors - what are they?
Interiors are basically a different VIEW towards the default GTA. You remain in the same world, but you cannot see the world, although you can still feel it.

Interior 0 => The default GTA world
Interior 1 to infinite => The same GTA world, but different view.

How are they useful?

The default GTA SA world objects are only visible in INTERIOR 1
BUT
Script-added objects are visible in ALL interiors, thus making it possible to create different worlds, creating different custom interiors. There are endless ways to utilize the interior's, but that gets even better with virtual worlds.

Also, vehicles exist in all interiors as they are, but they're invisible in every other interior except the one that they're created in (This can be solved by linking the vehicle to interior)

2. Virtual worlds - what are they?

Virtual worlds are completely different worlds, although with the SAME point of view (The point of view can be altered with the help of interiors). Objects remain same throughout all the virtual worlds, but the same cannot be said for vehicles.
Vehicles must be in the same virtual world as the player who wants to see them in order to be visible (SetVehicleVirtualWorld)
This can be used for creating RACES (wouldn't want to get rammed by non-racers while you're racing, would you?), but that's just one idea, there are endless possibilities to what you can do with these 2!

P.S: I know that this tutorial is not very informative, but I think it explains the basic concept of what virtual worlds and interiors are, and what they can be used for

Conclusion

This concludes with 3 type's of data of LOCATION for EACH player

In simpler words, if all these 3 are utilized in an innovative and efficient way, you can create a number of dimensions (Although virtual worlds are limited to 2,147,483,647, and there's no limit mentioned to interiors but I guess there is one)

Quote:

Originally Posted by BigETI (Post 2533046)

Coordinates and interior IDs are basicly GTA SA game engine inbuild features. Interior IDs just changes the way the game engine renders the scenes, still the collision calculations remain the same. Virtual worlds are a feature from SA:MP to change the way how players stream players, vehicles, pickups etc. so basicly someone in the 1st virtual world won't see someone in the 2nd virtual world even, if they are almost at the same position, since the server only streams players, vehicles and pickups, if the virtual worlds equals the entity uses. Virtual worlds can't be manipulated using cheating engines.

[Tutorial] How to make a very simple Anti-Spawn Kill

Lagger321 — Sat, 18 May 2013 17:17:40 GMT

Okay, so I'm getting bored ATM so, I've decided to make this very simple tutorial about Anti-Spawn Killing.
Basically its only 9 Lines.
Okay, lets get started.
-------------------------------------------------------------------

First :
We need to put it on the OnPlayerDeath callback.

pawn Code:

public OnPlayerDeath(playerid, killerid, reason)
{
   return 1;
}

Second :
We will use the IsPlayerInRangeOfPoint, but, instead of playerid, we will use Killerid.
Then find the Spawn coordinates of each teams.

pawn Code:

IsPlayerInRangeOfPoint(killerid, Float:size, Float:SpawnX, Float:SpawnY, Float:SpawnZ);

Third :
Then, we will now merge it in the OnPlayerDeath callback.

pawn Code:

public OnPlayerDeath(playerid, killerid, reason)
{
   if(IsPlayerInRangeOfPoint(killerid, Float:Range, Float:SpawnX, Float:SpawnY, Float:SpawnZ))
   {
    // do whatever punishment you want to do with the Spawn Killer here.
   }
   return 1;
}

Example :

pawn Code:

public OnPlayerDeath(playerid, killerid, reason)
{
   if(IsPlayerInRangeOfPoint(killerid, 20, 1587, -1693, 7)) // It means that if the player is within 20 meter range some around the Garage of LSPD the following will happen :
   {
    SetPlayerHealth(killerid, 0); // my punishment for the Spawn Killer is Death.
    SendClientMessage(killerid, Red, "SERVER : You can't spawn kill!"); // then sends him a message that he can't spawn kill
   }
   return 1;
}

Suggestions of all types are open.
Please help me improve if anything is wrong in the tutorial!

[Tutorial] How to add a player to your script

Lagger321 — Sat, 18 May 2013 07:03:53 GMT

Today I will show you how to add a skin to your script.
To start off, Open up Pawno and click new.

Now look for "AddPlayerClass"

When you have found that... Read the following information:

What is this line Used for?

pawn Code:

AddPlayerClass(0, 1958.3783, 1343.1572, 15.3746, 269.1425, 0, 0, 0, 0, 0, 0);

This line is used for adding ped's into your script/Server:
The Meaning of that line is:

pawn Code:

AddPlayerClass(Player model, X, Y, Z, A, Weapon 0, Ammo 0, Weapon 1, Ammo 1, Weapon 2, Ammo 2);

Infomation about the script line:
Player model
The player Model, Is the players skin ID. To use a Rich means skin, Use skin ID=59.
To use a Sureno gang banger skin, Use skin ID=175.
So if you wanted to use a rich man skin you would have your code like this:

pawn Code:

AddPlayerClass(59, X, Y, Z, A, Weapon 0, Ammo 0, Weapon 1, Ammo 1, Weapon 2, Ammo 2);
X,Y,Z,A

X Y Z Are the Coords Aka Coordinates, This tells the script when the person picks his player, To spawn that player were the coords were set to.
The A is the facing angle of the player, So if you want your player to be facing somewere, Use this.
Soo, If you wanted the player to start at Unity Station and want him to have a rich man skin, You would have this:

pawn Code:

AddPlayerClass(59,1799.7964,-1867.6007,13.5700,347.3619,Weapon 0, Ammo 0, Weapon 1, Ammo 1, Weapon 2, Ammo 2);

Weapon 0-2 And Ammo 0-2
Weapon is the weapon that the player gets when he spawns. Weapon ID=24 Is an Deagle And Weapon ID 30 Is an AK-47.
Ammo is the bullets that the weapon has. So if you want a player to start a Unity station with a rich man skin and an AK-47
With 300 bullets you would put in this:
AddPlayerClass(59,1799.7964,-1867.6007,13.5700,347.3619,30, 300, 0, 0, 0, 0);
Reminder: If you want a player with no weapon, Just put a 0 for the Weapon and put a 0 for the ammo.

Ok, That tells us what the script line means. Now lets tell you how to get Coords.
Open up your GTA:SA Folder and there should be something called "samp_debug.exe". Ok, Open it up.
You should see that GTA:SA started with nothing Only Cj running around with no weapons.

Now go to the place were you want your player to start, Then Press "T' Or 'F6' to type in the command "/save".
HINT:Next to save you can wirte something that would let your rember that you just saved so do this:
/save New Player Spawn.
Ok, Now you have saved the place were you want the player to start. Now got into your GTA:SA folder and there should be something named:
"Savedpositions.Txt"
Open that up and you have the Coords of were you want your player to start, All you have to do now is copy the X Y Z and A from the "Savedpositions.Txt"
file and just replace it with the one you have on your script.

So there you go, You made your first player in your script with a gun.

[Tutorial] Beautiful, Readable Code II (Indentation Styles)

RvGamers — Fri, 17 May 2013 16:06:58 GMT

Beautiful, Readable Code II - Indentation Styles

Foreword

The idea for this thread was brought to me by Vince in the previous thread, Beautiful, Readable Code I. If you haven't seen that thread yet, I would recommend you read it first by clicking here. In my previous thread I went through several key characteristics of writing readable code including indentation (in general), white space, and comments. That being said, I neglected to touch on indentation styles. I tried to keep my previous thread as "one size fits all" as possible as to not conflict with the different styles of indentation (although inevitably I did). I am creating this thread to explain (in as much detail as necessary for SA-MP scripting purposes) the different styles of indentation and their benefits. I will only be touching on certain popular styles that lay the groundwork for other styles, so to gain a more complete knowledge of indentation styles you may desire to do some reading on your own.

Oh, and one more thing! In the examples I provide I will be creating a simple command using the most popular command processor, ZCMD. If you aren't familiar with the processor, you can read about it by clicking here. Keep in mind that the example command is simply meant to demonstrate indentation.

Benefits

One common misconception is that the length of a script determines how well that script will perform. This is simply not true. The only reason this generalization exists is because of the poorly-written nature of some of the most popular scripts in the community. Somewhere along the line, members of the SA-MP community began to associate a lot of lines in a script with that script being poorly written. While it is possible that a long script is poorly written, on the other hand a script is not poorly written just because it is long. This is an important distinction to understand.

Because of the obsession with line count in the SA-MP scripting community, the choice of indentation styles has been heavily influenced as of recent. As you will see in the examples below, some styles of indentation will produce more lines than others. Keep in mind that despite what indentation style you choose, your script will perform at EXACTLY the same rate. More lines does NOT mean less performance. Instead of focusing on which indentation style creates the least amount of lines, the sole purpose of indentation is readability. Each indentation style affects readability in one way or another, and I will cover these in detail below. While you are reading, focus on which style suits you best and is most appealing. The only benefit that one indentation style provides over another is readability factor, so the indentation style which you find most readable is the one you should use.

One final benefit to understanding indentation styles is flexibility. Although you may find one style more readable than another, you are not always going to be working with code you have written. If, for example, you begin to edit another person's script, chances are they may be exercising a different indentation style. It is important that you are not only able to interpret the style they are using, but you actually must be able to use it yourself! It is vital that the same style of indentation is used throughout an entire script to ensure continuity. This is simply a matter of standards, and while neglecting it won't produce any errors or affect the script itself, continuity of indentation can make a script more readable should a third party ever need to intervene and read a script edited by more than one person. Be flexible!

Allman Style

I have elected to begin this tutorial with the Allman style of indentation because it seems (to me at least) to be the most prominent in the community. Named after Eric Allman, this style of indentation requires the placing of any brace related to a control statement to be placed on its own line. This includes opening and closing braces. See the example below.

ALLMAN STYLE

pawn Code:

COMMAND:heal(playerid, params[])
{
    if(IsPlayerAdmin(playerid))
    {
        SetPlayerHealth(playerid, 100);
    }
    else
    {
        Kick(playerid);
    }
}

This style of indentation allows nests to be clearly defined, which makes modifications to nests significantly more fluid. If you aren't sure what a nest is, refer to my previous thread's basic explanation of indentation. The amount of white space surrounding different nests provides excellent readability and the matching indentation of the opening and closing braces serves as a clear barrier to define the end of a nest. The visibility of the braces also decreases the possibility of leaving out a brace, one of the most frustrating errors that an inexperienced (or experienced alike) scripter can come across. Some would say that the "disconnected" nature of nests from their control statements actually hurts readability as opposed to the styles below.

This style of indentation has more recently come under fire in the SA-MP community because it generates more lines than the styles below. Once again, I would like to reiterate that line count in the case of indentation does not affect performance in the slightest. Your main focus in choosing an indentation style should be readability.

Stroustrup Style

As the second most prominent form of indentation in this community (as I see it), we have the Stroustrup style of indentation. This style is identical to the Allman style, except for the placement of the opening brace on the same line as the initial statement. See the example below.

STROUSTRUP STYLE

pawn Code:

COMMAND:heal(playerid, params[]) {
    if(IsPlayerAdmin(playerid)) {
        SetPlayerHealth(playerid, 100);
    }
    else {
        Kick(playerid);
    }
}

As you can initially see, this style takes up considerably less space than the Allman style. The placement of the opening brace on the same line as the initial statement defining the nest allows nested elements to feel more "connected" to their control statements. Some would argue that this makes reading code more effective in terms of determining cause and effect patterns. On the other hand, the lack of white space has been claimed to hurt readability and make the modification of large nests more difficult.

This style, once again, has become more prominent in the SA-MP community with the obsession of line count. While it is perfectly fine to utilize this method of indentation, make sure that you are using it because it is more readable in your eyes, not because you want to save on line count. Once again, line count in terms of indentation has no effect on performance.

K&R Style

Finally we have the K&R style, which is actually the style which the Stroustrup style is derived from. The K&R style is similar to the Stroustrup style in that it places the initial brace on the same line as the initial statement and places the final brace on its own line. The exception comes when else or while are used, where the K&R style places the closing brace on the same line as the else or while keyword. See the example below.

K&R STYLE

pawn Code:

COMMAND:heal(playerid, params[]) {
    if(IsPlayerAdmin(playerid)) {
        SetPlayerHealth(playerid, 100);
    } else {
        Kick(playerid);
    }
}

As you can see, the K&R style uses up the least amount of space of all of the styles showcased thus far. The question becomes, is this a good thing or a bad thing? Once again, it is a matter of readability in your eyes. Considering the fact that I rarely see K&R on these forums, I would not recommend using it for a new project if at any point someone else may be required to read and modify your existing code. This style of indentation is arguably the most susceptible to leaving out a brace, which is, once again, a very annoying experience.

Summary

I tried to remain as objective as possible throughout this thread; however, it's probably already clear to you which style of indentation I favor. Try not to let my commentary sway you. If you find K&R to be the most readable and you don't mind knowing that the majority of people on this forum who may be working with your code have no experience with the style, then go for it! To once again reiterate the point of this thread (I know I'm beating a dead horse), readability is the most important factor to consider in choosing an indentation style.

[Tutorial] Howto: Properly handle rcon login spam

JernejL — Fri, 17 May 2013 06:09:30 GMT

This contains:
- Automatic ban of external console logins that fail to login (most of this type of attacks).
- Warning system (will warn all players from same ip not to try to login if they are not admins)
- Flood control - too many false attempts -> ban

Code:



OnRconLoginAttempt(ip[], password[], success) {

        

        #pragma unused password

        

        if (!success) {

                

                new hasplayers = 0;

                

                new pip[16];

                for (new PlayerID=0; PlayerID < MAX_PLAYERS; PlayerID++) {

                        

                        if (!IsPlayerConnected(PlayerID))

                                continue;

                        

                        GetPlayerIp(PlayerID, pip, sizeof(pip));

                        

                        if (!strcmp(ip, pip, true)) {

                                

                                hasplayers++;

                                

                                // protect nubs against their stupidity.

                                new timex = TimeSincePvar(PlayerID, "last_rcon_attempt");

                                

                                if (timex > 1000) {

                                        

                                        SendPlayerMessage(PlayerID, COLOR_RED, "Do not abuse the rcon system, you will be banned if you fail to login again.");

                                                                                

                                }

                                

                                SetPVarInt(PlayerID, "last_rcon_attempt", TickCount());

                                

                                new rla;

                                rla = GetPVarInt(PlayerID, "rcon_login_attempts");

                                

                                rla = rla + 1;

                                

                                if (rla > 3) {

                                        

                                        // ban the ip via rcon

                                        makestrf(banipstr, 64, "banip %s", ip);

                                        SendRconCommand(banipstr);

                                        

                                }

                                

                                SetPVarInt(PlayerID, "rcon_login_attempts", rla);

                                

                        }

                        

                } // loop

                

                if (hasplayers == 0) {

                        

                        // ban the ip via rcon

                        makestrf(banipstr, 64, "banip %s", ip);

                        SendRconCommand(banipstr);

                        

                }

                

        }

        

        return PCOR_CONTINUE;

}

For: TimeSincePvar - grab it here: http://forum.sa-mp.com/showpost.php?...8&postcount=40

[Tutorial] Fix: Pawno failed to set data for ".

Maran3llo — Thu, 16 May 2013 14:00:25 GMT

Hi guys, I decided to make this small very simple tutorial for beginners who may not know how to fix this bug, let's say.

I'm sorry for how I express myself, or if I write bad, but I'm Italian.

So we move to the Tutorial.

When we go to open the Pawno, a screen will appear that says "failed to set data for". ".

To solve this problem we must go to the folder Pawno server, and open the file "Settings".

FileAssoc is set to one, and must be set to zero.

Well, we set to zero and save the changes to the bloc note.

We finished, now the pawno will open normally

[Tutorial] How to make a DM zone

Rimmon — Thu, 16 May 2013 12:00:27 GMT

DM Zones

Hello guys , in this tutorial i'm going to show you how to make a DM ( Death match ) zone
It is so simple , you must follow some steps
Step I:
New variable

We must create a new variable who's gonna verify if the player is in a DM or not

pawn Code:

new 
     DM [ MAX_PLAYERS ] 
;

You must create a variable with [ MAX_PLAYERS ]because it must be a variable for a player not a global variable
Step II:
Making a DM Zone by command
If you wanna to make a DM zone available you must set the variable which we created to 1

pawn Code:

DM [ playerid ] = 1 ;

Ex:

pawn Code:

CMD:gotodm ( playerid , params [ ] )
{
     DM [ playerid ] = 1 ; 
     return 1 ;
}

Step III:
Verification
In this step , i'll show you how to verify if the player is in a DM or not
We must use if to verify if the player is in a DM or NOT

pawn Code:

if ( DM [ playerid ] == 1 ) return SendClientMessage ( playerid , -1 , " You can't use this command in a DM " ) ;

With the upper code the script will verify if the player is in a DM
if DM is set to 1 he'll can't use a command , if DM is set to 0 he'll can use the command
What SendClientMessage mean ?
Well , SendClientMessage send a message to player who try to use a command or make a action
SendClientMessage ( playerid , color , message [ ] ) ;

playerid - The player who the message will be send
color - the text color
message - the text who will be sent to a player

Ex:

pawn Code:

CMD:gotodm ( playerid , params [ ] )
{
     if ( DM [ playerid ] == 1 ) return SendClientMessage ( playerid , -1 , " You can't use this command in a DM " ) ;
     else
     {
          SetPlayerPos ( playerid , 0.0 , 0.0 , 0.0 );
     }
     return 1 ;
}

I hope i helped you
If i wrong something reply xD
Sorry for my bad english

[Tutorial] Beautiful, Readable Code (Indentation, Whitespace, Comments)

RvGamers — Wed, 15 May 2013 13:02:29 GMT

Beautiful, Readable Code: Version 1.

Audience

It has come to my attention that poor scripting habits lurk left and right in the SA-MP community. This isn't a surprise considering the fact that most scripters are taking their first steps on these forums to produce code which offers immediate gratification. If you have ever found yourself wondering whether or not to indent, how to structure a set of statements, how to use comments effectively, or even looking up a plugin which indents for you automatically, then this tutorial is for you.

Oh, and one more thing! I have gone ahead and underlined key points in each section of the tutorial. Even if for some reason you don't understand any part of a particular explanation, make sure you understand the underlined key point!

Benefits

Proper indentation is the groundwork for writing beautiful, readable code. Although this point may have already been stressed to you at one point or another along your journey, you should be writing your code with the intention of it being readable for someone other than yourself. Even if you never intend to show your code off or introduce someone else to it, writing readable code makes troubleshooting easier and modifications less difficult to implement. Besides, you never know when you may take a break from the project you are working on and come back a few months later. If your code isn't readable, you will find yourself frustrated and unproductive.

Indentation

Indentation is arguably the most prominent factor in writing beautiful, readable code. Do you know how to indent properly? Let's find out.

First and foremost, we need to cover the idea of "nesting." Nesting is the use of those neat braces: { } to nest one statement, argument, or function within another. Let's start out with a basic example of nesting.

For this example, I am using a popular command processor named ZCMD for the purpose of simplicity and application. An example of a nest is creating a command using ZCMD. Notice the comments next to the code.

SINGLE NEST:

pawn Code:

COMMAND:heal(playerid, params[])
{
    SetPlayerHealth(playeird, 100);// This function (SetPlayerHealth) is nested inside of the command "heal."
}

The nested area is the area where you place further arguments and then define what you wish the command to do. It is possible to have a nest within a nest, or several nests within a nest. Below I have placed an example of a nest within a nest. Notice the comments in the code.

MULTIPLE NESTS:

pawn Code:

COMMAND:heal(playerid, params[])
{
    if(IsPlayerConnected(playerid)) // Nested within the "heal" command.
    {
        SetPlayerHealth(playerid, 100); // Nested within the if statement "IsPlayerConnected."
    }
}

How does nesting apply to indentation? They are directly related! The purpose of indentation is to visually represent nesting. In order to indent properly, all you have to do is press that "tab" button (the button which introduces several spaces) every time you are placing a new nested item. If you ever ask yourself again, "Do I need to indent here?" just remind yourself that you ONLY indent when you are placing a nested item. If the item you are placing is NOT nested in another statement/argument, you do NOT need to indent.

While you may have noticed in the past that loose indentation (improper indentation) only results in warnings, it is extremely beneficial to exercise good indentation when scripting. When you need to create multiple nests within nests, you'll find it much easier to locate the certain pieces you want to change or modify at a later date if they are indented properly.

White Space

White space is your friend! For some reason an obsession with line count (the amount of lines in a script) has overcome the SA-MP community. Stop making generalizations! Line count has absolutely nothing to do with how well a script has been written or how efficiently it will perform. The only reason line count has received such a negative aura is due to the fact that MOST scripts with large amounts of lines ALSO happen to be very poorly written. It is uncommon to find a large script written well, due to the fact that most large scripts are simply edits of poorly-written older scripts. If you utilize the latest plugins, includes, and stay up to date in your methods, line count is not an issue.

Now that I have flipped your world upside down, let's talk about white space! The ability to separate chunks of code with white space is a very powerful tool for creating excellent readability. Your code does not have to be on top of itself! Make some space, allow some breathing room! A couple of lines of space in between commands, for example, can make scanning through code a much more enjoyable experience. That being said, don't go overboard. You still want to display as much code as possible on the screen at any given time. Find the right balance between white space to create separation and readability and still displaying a good amount of code on the screen.

Comments

Another trend in the SA-MP community is the use of extravagant comments to create separation. While there isn't an issue with this practice, it's also not necessary. The real reason I am mentioning comments is not to encourage you to use them for separation, but to use them for what they are meant for: commenting things! Like I mentioned in the first paragraph, you should be writing your code through the eyes of someone else viewing it. This can be hard to do if you don't adjust your thinking accordingly!

Comments are meant to explain SCRIPT-SPECIFIC content, not general concepts of scripting. I find that some scripters tend to go overboard with their comments and begin to rewrite pawn_lang.pdf in the process. For example, in the if statement below:

BAD COMMENT:

pawn Code:

if(PlayerInfo[playerid][Admin] > 0) // Checks if the player's admin level is greater than zero.

I do NOT need you to tell me that this checks if the player's "Admin" is greater than zero. I have eyes and I have cognitive abilities! Instead, use comments to describe attributes of your script which an experienced scripter would not be able to recognize without previous knowledge of this exact script. An example of this is the creation of a new, unique function.

Just remember, you don't have to reinvent the wheel in your comments. Keep them short, simple, to the point, and most importantly only utilize them when necessary. While you may think its better to err on the side of caution, really you are just destroying your productivity.