[Universal]

Which way is more efficient?

pawn Код:

for(new i=0; i<MAX_PLAYERS; i++) {
   if(IsPlayerConnected(i)) {
      // code goes here
   }
}

OR

pawn Код:

for(new i=0; i<MAX_PLAYERS; i++) {
   if(!IsPlayerConnected(i)) continue;
   // code goes here
}

[Jack_Leslie]

Quote:

Originally Posted by Universal Which way is more efficient? pawn Код: for(new i=0; i<MAX_PLAYERS; i++) {    if(IsPlayerConnected(i)) {       // code goes here    } } OR pawn Код: for(new i=0; i<MAX_PLAYERS; i++) {    if(!IsPlayerConnected(i)) continue;    // code goes here }

I'd personally say the second one.

[Slice]

Quote:

Originally Posted by 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.

It's not about whether it works. It just isn't right.

Quote:

Originally Posted by Universal Which way is more efficient? pawn Код: for(new i=0; i<MAX_PLAYERS; i++) {    if(IsPlayerConnected(i)) {       // code goes here    } } OR pawn Код: for(new i=0; i<MAX_PLAYERS; i++) {    if(!IsPlayerConnected(i)) continue;    // code goes here }

There's no significant difference. The former has fewer AMX instructions (maybe 3).

[SuperViper]

In some cases, returning a function in a command can be useful for debugging because if it returns 0 you'll see unknown command, which usually means a function failed.

[The__]

Quote:

Originally Posted by Universal Which way is more efficient? pawn Код: for(new i=0; i<MAX_PLAYERS; i++) {    if(IsPlayerConnected(i)) {       // code goes here    } } OR pawn Код: for(new i=0; i<MAX_PLAYERS; i++) {    if(!IsPlayerConnected(i)) continue;    // code goes here }

I'd say

pawn Код:

foreach(new i : Player)

[SuperViper]

Quote:

Originally Posted by The__ I'd say pawn Код: foreach(new i : Player)

Foreach isn't a magical tool that speeds up all player loops. In some cases, regular loops are faster than foreach.

[Finn]

Quote:

Originally Posted by SuperViper Foreach isn't a magical tool that speeds up all player loops. In some cases, regular loops are faster than foreach.

Interesting, what's that case?

[The__]

Quote:

Originally Posted by SuperViper Foreach isn't a magical tool that speeds up all player loops. In some cases, regular loops are faster than foreach.

I remember someone saying the foreach loops between online players, and not max player capacity, which is better IMO.

[Universal]

Quote:

Originally Posted by The__ I'd say pawn Код: foreach(new i : Player)

I dont remember asking about foreach.

OT. Thanks for answers, I was just curious.

[[KHK]Khalid]

You've been given good methods for defining dialogs and they work efficiently, I'll give you one more method which I prefer though. Hmm what about writing an special include file for dialogs? Let me explain:

Open up notepad and put something like this:

pawn Код:

// Dialogs IDs

#if defined _diags_included
    #endinput
#endif
#define _diags_included
// Dialogs definations
#define Dialog 1 // Example
#define Dialogo Dialog+1 // another example actually Dialogo is set to 2 now (1 + Dialog = 1 + 1 = 2)
#define Dialogoo 3
// Other dialogs

Save as .inc (Include File) then put this file into your pawno include folder.

After that open up your a_samp include file then include the dialogs inc file there:

pawn Код:

#include <core>
#include <float>
#include <string>
#include <file>
#include <time>
#include <datagram>
#include <a_players>
#include <a_vehicles>
#include <a_objects>
#include <a_sampdb>
#include <dialogs> // replace "dialogs" with your dialogs include file name.

So as soon as you include a_samp, the dialogs inc file will be included as well. So, whenever you want to add/remove a dialog, you'll just have to go to the dialogs inc file and define/un-define it there.

Now you can easily use your dialogs in any script that includes the a_samp we modified above:

pawn Код:

ShowPlayerDialog(playerid, Dialogo, ...);

The same can be done with virtual worlds and such things.

[Y_Less]

You shouldn't modify the original includes.

[Ash.]

HellSphinX comes in with the left hook, but Y_Less takes him down with a right!

Sorry... anyway @HellSphinX It would be better if you put that in a new include. That way you don't 'lose' the defines when the server version updates, and it makes sure that you don't break original includes.

[WackoX]

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.

The .pwn and .amx would be smaller, plus it is much easier to find other things.
BTW changing MAX_PLAYERS to MP doesn't make any sence.

[Y_Less]

Quote:

Originally Posted by WackoX The .pwn and .amx would be smaller, plus it is much easier to find other things. BTW changing MAX_PLAYERS to MP doesn't make any sence.

It doesn't affect the .amx size at all, our only marginally affects the .pwn size while seriously affecting readability.

[[KHK]Khalid]

Quote:

Originally Posted by Y_Less You shouldn't modify the original includes.

Would you mind telling me what could happen (or what issue could it cause)?

It's done to make it simpler, so you just include a_samp (which is needed in any script except npcs) instead of including dialogs (or any special include file you ever made) in every script you want to use those dialogs in.


Edit:

Quote:

Originally Posted by funky1234 @HellSphinX It would be better if you put that in a new include. That way you don't 'lose' the defines when the server version updates, and it makes sure that you don't break original includes.

It's been written in a new include file if you didn't notice. All what I did modify in the original include (a_samp) was putting one line to include my special include file so I won't have to include it in every script I wanna use diags on.


Well, waiting for Y_Less' reply to know if it's illegal or something.

[Y_Less]

Its not illegal, its just not generally done. Those are provided for you to write your own scripts with and can change without warning, meaning you will loose all your custom code. Why not do it the other way round? Include a_samp from your include and then only ever include your include instead.

Also, if you ever release your mode it won't compile for other people as they won't modify their a_samp.

[[KHK]Khalid]

Quote:

Originally Posted by Y_Less Include a_samp from your include and then only ever include your include instead.

Sweet! This should be better when writing a script to be released (Even though you could give the special include file too when releasing your script).

I personally never had a problem with it being included from the a_samp include though.


Edit:

Or you can use #tryinclude.