[Jack_Leslie]

Hi there,

I'm currently working on a custom script, from complete scratch, even color definitions, I'm only currently at 1,261 lines but before I go any further I'd like to get some opinions on the best way to script efficiently, so in a years time the script is still scriptable (unlike some messy godfather edits).

I'm using y_ini and y_commands, with Dini for some other commands that require certain things that y_ini can't do. I'm then using foreach, sscanf2 and streamer. So in my opinion, that's pretty efficient so far.

How ever it's the actual style/method of coding I'm worried about that's going to make it inefficient. One thing is, for dialogs, I use dialog defines so that I can keep track of what dialog numbers I'm at.
Example:

pawn Code:

#define DIALOG_LOGIN 1

Then, for player related variables (not sure of the technical name), I use a define for them.
Example:

pawn Code:

#define MAX_PLAYERS MP

new gIsPlayerLoggedIn[MP];

I then use this style of coding when I create a command:

pawn Code:

CMD:connected(playerid, params[])
{
    if(IsPlayerConnected(playerid)) return SendClientMessage(playerid, -1, "You are connected.");
    else return SendClientMessage(playerid, -1, "For some reason, you are not connected.");
}

Instead of:

pawn Code:

CMD:connected(playerid, params[])
{
    if(IsPlayerConnected(playerid))
    {
        SendClientMessage(playerid, -1, "You are connected.");
        return 1;
    }
    else
    {
        SendClientMessage(playerid, -1, "For some reason, you are not connected.");
    }
    return 1;
}

So, how do you think I'm going with efficiency so far? Should I keep going the way I am or change things? Input your opinions below, and voice your opinion on anything else about scripting efficiently

[dannyk0ed]

Welcome to ZCMD

[ReneG]

Quote:

Originally Posted by Jack_Leslie How ever it's the actual style/method of coding I'm worried about that's going to make it inefficient. One thing is, for dialogs, I use dialog defines so that I can keep track of what dialog numbers I'm at. Example: pawn Code: #define DIALOG_LOGIN 1

That's fine.

Quote:

Originally Posted by Jack_Leslie Then, for player related variables (not sure of the technical name), I use a define for them. Example: pawn Code: #define MAX_PLAYERS MP new gIsPlayerLoggedIn[MP];

pawn Code:

#define  MP  MAX_PLAYERS

Is the correct way, you had it backwards.

Quote:

Originally Posted by Jack_Leslie I then use this style of coding when I create a command: pawn Code: CMD:connected(playerid, params[]) {     if(IsPlayerConnected(playerid)) return SendClientMessage(playerid, -1, "You are connected.");     else return SendClientMessage(playerid, -1, "For some reason, you are not connected."); } Instead of: pawn Code: CMD:connected(playerid, params[]) {     if(IsPlayerConnected(playerid))     {         SendClientMessage(playerid, -1, "You are connected.");         return 1;     }     else     {         SendClientMessage(playerid, -1, "For some reason, you are not connected.");     }     return 1; }

There is literally no difference in efficiency between the two, it just makes you read it differently. Personal choice really.

[Jack_Leslie]

Quote:

Originally Posted by VincentDunn That's fine. pawn Code: #define  MP  MAX_PLAYERS Is the correct way, you had it backwards. There is literally no difference in efficiency between the two, it just makes you read it differently. Personal choice really.

Thanks, that's helpful!

[coole210]

I think you're confusing efficiency with making the code shorter.

[Jack_Leslie]

Quote:

Originally Posted by coole210 I think you're confusing efficiency with making the code shorter.

Yeah but let's say someone has a command that's 50 lines long, when it could easily be 10 lines long, the scripts not going to be very efficient in the long run.

[coole210]

Quote:

Originally Posted by Jack_Leslie Yeah but let's say someone has a command that's 50 lines long, when it could easily be 10 lines long, the scripts not going to be very efficient in the long run.

You mean to say that the one that's 50 lines long is harder to read and understand? I think the one that tries to fit 50 lines worth of code into 10 is a bit harder to understand.

[JoBullet]

Lookup Slice's project called PAWN-Boilerplate, though unreleased yet, I find it very mature and it serves exactly to make building a new gamemode easier. Why start from scratch, when you can build on others' people work, this will also mean you will able to work on other features unique to your gamemode(i.e. not common ones, like group system, user system etc.)

[CaHbKo]

Judging code by amount of lines is like judging a plane by it's weight.

[CaHbKo]

Quote:

Originally Posted by Sniper Kitty A plane's weight is important... too much and it cannot fly.

But both 2-seater and Boeing 747 serve their purpose.

[Sinner]

Quote:

Originally Posted by CaHbKo Judging code by amount of lines is like judging a plane by it's weight.

I think you mean the famous quote:

pawn Код:

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

- Bill Gates

[Sniper Kitty]

Quote:

Originally Posted by Sinner I think you mean the famous quote: pawn Код: “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” - Bill Gates

Which would make alot more sense.

[Vince]

Dini sucks. Please that me what it is that dini can do that any other (and better) ini writer can't do. Furthermore, use enumerators to keep track of dialogs. Much easier to maintain. Also you can undefine MAX_PLAYERS and set it to your own.

pawn Код:

#if defined MAX_PLAYERS
     #undef MAX_PLAYERS
#endif
#define MAX_PLAYERS (100)

[Jack_Leslie]

Quote:

Originally Posted by Vince Dini sucks. Please that me what it is that dini can do that any other (and better) ini writer can't do. Furthermore, use enumerators to keep track of dialogs. Much easier to maintain. Also you can undefine MAX_PLAYERS and set it to your own. pawn Код: #if defined MAX_PLAYERS      #undef MAX_PLAYERS #endif #define MAX_PLAYERS (100)

I defined MP as MAX_PLAYERS so when I create player related variables I only need to do "[MP]", not "[MAX_PLAYERS]", just shortens scripting time.

I'm using Dini for an unbanned command, and I'll use it for other commands to. The reason I'm using that instead of y_ini (I still use y_ini for the the main things, like loading and saving players data) is because y_ini can't get a single value from a file, without needing the load the whole file and parse it (from my knowledge). The only function I use with Dini is dini_Get.

[Slice]

Quote:

Originally Posted by Jack_Leslie I defined MP as MAX_PLAYERS so when I create player related variables I only need to do "[MP]", not "[MAX_PLAYERS]", just shortens scripting time.

That's just silly..

[Jack_Leslie]

Quote:

Originally Posted by Slice That's just silly..

That's why I made this thread, so I can see what I'm doing wrong and if I can improve

[IstuntmanI]

I think

pawn Код:

CMD:connected( playerid, params[ ] )
{
    if( IsPlayerConnected( playerid ) )
        return SendClientMessage( playerid, -1, "You are connected." );

    return SendClientMessage( playerid, -1, "For some reason, you are not connected." );
}

is better (at least shorter) than

pawn Код:

CMD:connected(playerid, params[])
{
    if(IsPlayerConnected(playerid))
    {
        SendClientMessage(playerid, -1, "You are connected.");
        return 1;
    }
    else
    {
        SendClientMessage(playerid, -1, "For some reason, you are not connected.");
    }
    return 1;
}

[Slice]

Personally, I really don't like the way people use "return SendClientMessage". The return value of SendClientMessage has nothing to do with the return value of a command - it just happens to be the value you want to return anyway.

I'd say something like this is better:

pawn Код:

CMD:connected(playerid, params[]) {
    if (!IsPlayerConnected(playerid))
        SendClientMessage(playerid, -1, "For some reason, you are not connected.");
    else
        SendClientMessage(playerid, -1, "You are connected.");
    
    return 1;
}

CMD:kick(playerid, params[]) {
    new otherid = strval(params);
    
    if (!HasPermission(playerid))
        SendClientMessage(playerid, -1, "You don't have permission.");
    else if (!IsPlayerConnected(otherid))
        SendClientMessage(playerid, -1, "Invalid player id given.");
    else if (IsPlayerAdmin(otherid))
        SendClientMessage(playerid, -1, "Other player is admin.");
    else {
        Kick(otherid);
        
        SendClientMessage(playerid, -1, "KDONE");
    }
    
    return 1;
}

[Jack_Leslie]

Quote:

Originally Posted by Slice Personally, I really don't like the way people use "return SendClientMessage". The return value of SendClientMessage has nothing to do with the return value of a command - it just happens to be the value you want to return anyway. I'd say something like this is better: pawn Код: CMD:connected(playerid, params[]) {     if (!IsPlayerConnected(playerid))         SendClientMessage(playerid, -1, "For some reason, you are not connected.");     else         SendClientMessage(playerid, -1, "You are connected.");         return 1; } CMD:kick(playerid, params[]) {     new otherid = strval(params);         if (!HasPermission(playerid))         SendClientMessage(playerid, -1, "You don't have permission.");     else if (!IsPlayerConnected(otherid))         SendClientMessage(playerid, -1, "Invalid player id given.");     else if (IsPlayerAdmin(otherid))         SendClientMessage(playerid, -1, "Other player is admin.");     else {         Kick(otherid);                 SendClientMessage(playerid, -1, "KDONE");     }         return 1; }

I never thought of it that way, I'll most likely script similar to that, seems more efficient, which is what I was aiming to get from posting this thread, thank you!

[Vince]

I don't see what's wrong with return SendClientMessage. You can always still add a 1 to the end of the statement, but what's the point? It's not like the return value of SendClientMessage is going to change any time soon. I'm not too keen on large if-elseif statements. It makes code less readable.