Best effiecent scripting

[Y_Less]

Originally Posted by Sniper Kitty

I don't find it better.
Custom code takes more time, yes, but there's a benefit!
The benefit is you learn more along the way.
Although I still do relay on a_samp and the MySQL plugin, I don't use any other plugins or includes in my scripts.

That doesn't make any sense at all... Let's say you write 1000 lines of code and learn 2 things on the way - that's great but it will take you the same amount of time regardless of what those lines do. So you can either spend that time learning and re-writing code done before, or spend that time learning and writing something original. Either way you code and learn, so why waste it?

Originally Posted by SuperViper

1) Did you actually create the function?
2) You're checking for 3 seperate dialogs and 2 in the top two examples.

Bottom line is, putting dialogs in functions won't make things faster. There's no point in arguing anyway because the difference is so small that it won't be noticed at all.

That's not a bottom line because you have no evidence to support your claim that thousands of integer comparisons and branches are somehow faster than one function call, despite evidence (though admittedly weak) to the contrary! You can't just claim something for no good reason. Anyway, I personally would say use y_dialogs, not for the speed but for the simplicity (and if you want to argue with that, make sure you understand my last post first).

[AndreT]

You are right about the evidence I presented being rather weak. From the first moment on, I was intrigued how weird it would be to clock a hundred if-checks against calls to format and CallLocalFunction. But eventually they would be designed to do the same thing IF I was to make the code call a function in every if statement scope. However since it is quite late, I cannot even be bothered to write something that'll generate such code for me, I only did I partially.

http://pastebin.com/eArP5Ahk
(and no, this isn't the test from before, although to compensate it only a little bit, I still pass the same amount of values to the DLG_%d function)

I also tested it so the dialog ID varies, going from 0 to 99. In such cases, the difference between the timings will be smaller (the second method is only ~1.7 times slower than the first one).

If the test is flawed, please let me know.

Originally Posted by Y_Less

That's not a bottom line because you have no evidence to support your claim that thousands of integer comparisons and branches are somehow faster than one function call, despite evidence (though admittedly weak) to the contrary! You can't just claim something for no good reason. Anyway, I personally would say use y_dialogs, not for the speed but for the simplicity (and if you want to argue with that, make sure you understand my last post first).

I've never objected to using frameworks, libraries or whatever might make a scripter's job easier when creating a mode.
Mine has been running for a few years now and during the time, the time I've spent tweaking existing code according to tips from the SA-MP community, is very long. For example, I have also implemented the code from ZCMD.inc into my gamemode's main file. Why? So I can change it to my needs and integrate it with my command system a bit more thoroughly without losing efficiency there. Zeex's approach to scripters is very user-friendly by providing a few callbacks and the overhead from calling them can be reduced by implementing it in your mode.
In the position of someone who has an entirely unique idea and wants to put it into code without having to worry about "ugh, how do I most conveniently use dialogs", I would definitely use the most user-friendly library.
As for the post about when to optimize, I entirely agree!

[[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:

// 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:

#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:

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]

Originally Posted by VincentDunn

That's fine.

#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]

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]

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:

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]

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.