[BigETI]

What does this include actually do?
It does actually call a function with a higher performance instead of using any checks inside OnDialogResponse.

How to use this include?
Simple we can use

pawn Код:

DIAL:0(playerid, bool:response, listitem, inputtext[])

or

pawn Код:

DIALOG:0(playerid, bool:response, listitem, inputtext[])

or (not recommend)

pawn Код:

forward dial_0(playerid, bool:response, listitem, inputtext[]);
public dial_0(playerid, bool:response, listitem, inputtext[])
//...

Код:

DIAL:0(playerid, bool:response, listitem, inputtext[])

Callback start:

Код:

DIAL:

Dialog Response ID:

Код:

0

Player ID

Код:

playerid

Response statement

Код:

bool:response

List item ID:

Код:

listitem

Inputtext string:

Код:

inputtext[]

Example:

pawn Код:

DIAL:5(playerid, bool:response, listitem, inputtext[])
{
    if(response) SendClientMessage(playerid, 0x00FF00FF, "You have accepted the rules.");
    else SendClientMessage(playerid, 0xFF0000FF, "You have declined the rules.");
    return 1;
}

Every function must return a value. (Returning 1 or higher will stop calling OnDialogResponse otherwise returning 0 will call OnDialogResponse.)

Of course you can use several dialog responses to run another dialog response ID callbacks
Example:

pawn Код:

DIAL:5(playerid, bool:response, listitem, inputtext[])
{
    if(response) SendClientMessage(playerid, 0x00FF00FF, "You have accepted the rules.");
    else SendClientMessage(playerid, 0xFF0000FF, "You have declined the rules.");
    return 1;
}
DIAL:1(playerid, bool:response, listitem, inputtext[]) return dial_5(playerid, response, listitem, inputtext);
DIAL:2(playerid, bool:response, listitem, inputtext[]) return dial_5(playerid, response, listitem, inputtext);
//etc..

Benchmark Scripts/Results:
Every single callback/check will be called. Loops 10000 times through:
Edit: Because I was dumb enough to call the dialog response ID correctly, I have to retest the speed + reupload the scripts

• bdial.inc: 123ms - 125ms (not bad for such loop)
• fdialog.inc: 123ms- 124ms (kinda fast as my include)
• gDialog.inc: 175ms - 178ms (abit slower than bdial.inc and fdialog.inc, but still fast)
• if else methode: 1736ms - 1759ms (SLOW!)
• switch methode: 125ms - 127ms (This impressed me because the switch methode is also very fast. [But some milliseconds slower than bdial.inc and fdialog.inc. :P ])

All benchmark test scripts: http://solidfiles.com/d/565d/

Credits:

• Myself..
• Idea from ZCMD include which also calls a callback instead of using checks in its own callback
• Hooking methode by ******
• SA:MP Development Team

Where I can download this file?
Download bdial.inc from Solidfiles
Download bdial.inc from Pastebin

Regards: BigETI

[Norn]

Nice work, would it be possible for you to create some sort of converter to convert switch statements into DIAL's? As converting x amount of dialogs manually would be a pain!

[System64]

wow awesome, but how it's 0ms, I thik it must be min. 1ms? But ok

[EvgeN 1137]

o___0 wow.
Maybe, do the B-Pick (pickups)?

[vampirmd]

I tested it very good one to use it

[BigETI]

Quote:

Originally Posted by Norn Nice work, would it be possible for you to create some sort of converter to convert switch statements into DIAL's? As converting x amount of dialogs manually would be a pain!

Lol I'll look creating something like this.

Quote:

Originally Posted by System64 wow awesome, but how it's 0ms, I thik it must be min. 1ms? But ok

0 milliseconds for each test. I can't believe it too or the benchmark script gone mad (but if you check the script it's still fine..)

Quote:

Originally Posted by EvgeN 1137 o___0 wow. Maybe, do the B-Pick (pickups)?

I'll look if it's necessary

Quote:

Originally Posted by vampirmd I tested it very good one to use it

Thank you all!

EDIT: Removed some unnecessary lines from earlier debug.

[juraska]

That's awesome, now dialogs are more faster! nice job!

[[LaTinb0y]...$ag3R]

simple but very suefull...any way thanks !

[wups]

Your benchmark code is IMHO strange.
You should do benchmarks with Slice's code.
Now you only benchmark 10 OnDialogResponse's.
#define BENCHMARK_LOOP 10

[BigETI]

Quote:

Originally Posted by wups Your benchmark code is IMHO strange.[...] Now you only benchmark 10 OnDialogResponse's. #define BENCHMARK_LOOP 10

If I try to increase the amount, so at a certain value it will stop calling OnDialogResponse and the benchmark test freezes.

Quote:

Originally Posted by wups [...]You should do benchmarks with Slice's code.[...]

Any links to his benchmark code?

[wups]

Quote:

Originally Posted by BigETI If I try to increase the amount, so at a certain value it will stop calling OnDialogResponse and the benchmark test freezes. Any links to his benchmark code?

So try to find a problem why does it freeze.

https://sampforum.blast.hk/showthread.php?tid=218491
By the way, how is this different?
https://sampforum.blast.hk/showthread.php?tid=260298

+ This is WRONG

pawn Код:

DIAL_ODR = funcidx("Dial_OnDialogResponse");

And why do you use:

pawn Код:

#pragma library bdial

pawn Код:

public OnDialogResponse(playerid, dialogid, response, listitem, inputtext[])

response should be boolean.

[BigETI]

Quote:

Originally Posted by wups + This is WRONG pawn Код: DIAL_ODR = funcidx("Dial_OnDialogResponse");

This checks if Dial_OnDialogResponse exists (because if I check for OnDialogResponse it will of course return me not -1 so the same example for OnPlayerUpdate because if you check for OnPlayerUpdate and you want to call the hooked one but the hooked one doesn't even exists so OnPlayerUpdate will send desynced data. Simple check for it's hooked one and everything will be fine ) [Believe me I have tested it]

Quote:

Originally Posted by wups And why do you use: pawn Код: #pragma library bdial

I don't know why I've actually used it

Quote:

Originally Posted by wups By the way, how is this different? https://sampforum.blast.hk/showthread.php?tid=260298

Mine should have a better performance and easier to use.

[wups]

Quote:

Originally Posted by BigETI This checks if Dial_OnDialogResponse exists (because if I check for OnDialogResponse it will of course return me not -1 so the same example for OnPlayerUpdate because if you check for OnPlayerUpdate and you want to call the hooked one but the hooked one doesn't even exists so OnPlayerUpdate will send desynced data. Simple check for it's hooked one and everything will be fine ) [Believe me I have tested it] I don't know why I've actually used it Mine should have a better performance and easier to use.

Don't explain me, i know what it does.
What if OnDialogResponse function id is zero?
Although when returning in OnGameModeInit is correct.
Check my scripts, for how to hook.

Edit: Oh i didn't notice you have (DIAL_ODR != -1) there.
Anyway I think a better way to do it would save it in a boolean.

pawn Код:

new bool:DIAL_ODR;
DIAL_ODR = (funcidx(...) != -1);

[BigETI]

For real...
I'll explain you the logic behind this

OnDialogResponse already exists in this script, so I don't have to check for its validity.

• IF any "dial_" callbacks doesnt't exists or returns 0 so Dial_OnDialogResponse will be called
• IF the Dial_OnDialogResponse exists and it returns 1, this callback won't get called in another scripts.
• IF Dial_OnDialogResponse doesn't exists, funcidx will return -1 and our callback is missing. returns zero also and will be called in another scripts to keep checking for any dialog response.
• Same for if Dial_OnDialogResponse exists and it returns simply 0, then it will be ofc called (same as above) in another scripts

In your methode it doesn't really check the availability of the new function so if Dial_OnDialogResponse doesn't exists, funcidx will not return -1 because in the include there is already OnDialogResponse and while doing the check for its availability it will just return 0 (Oh imagine you are doing it for OnPlayerUpdate)

Edit:

Quote:

Originally Posted by wups Edit: Oh i didn't notice you have (DIAL_ODR != -1) there. Anyway I think a better way to do it would save it in a boolean. pawn Код: new bool:DIAL_ODR; DIAL_ODR = (funcidx(...) != -1);

* BigETI kisses on your forehead
This will indeed make the check faster!

[Gamer_Z]

Quote:

Originally Posted by BigETI Mine should have a better performance and easier to use.

So where is the speed comparision?

I already compared
gDialog, FDLG and NDLG together, there are 3 dialog systems (NDLG is the slowest, it uses strings), which 2 of them are fast processors, and you say it "should" be faster.. nothing "should" be, you have to benchmark that befor expressing such statement.

[BaubaS]

How this is easier? Syntax is total the same. DIAL: and DIALOG:

What's the difference?

[TheArcher]

Yes ok, nice work but who loop a dialog it makes no sense. You might call a dialog twice 1 - 2 seconds but not 10000000 in 1 ms.

[Jochemd]

How the...! I was working on this too!

Looks awesome and good idea

Oh, @ ******: I understand your point against this guy, but do you think it's a good idea to make this? I don't think it's faster to process for the server.

[BigETI]

Quote:

Originally Posted by ****** That benchmarking code, despite your claims to the contrary, is NOT valid. You are comparing 1000001 dialogs (yes, not 1000000, you don't even know how many tests you're running) to 1 dialog - of COURSE your system will be faster! "CallLocalFunction" does NOT call functions INSTANTLY - nothing happens INSTANTLY, it just happens very quickly because there is only a couple of public functions to search through! If you wanted a true VALID test, you would have to make 1000001 "DIAL" callbacks, put them all in your mode, compile, then run that test to see the difference. Check the benchmarking code I used to test y_commands. I wrote a file with about 676 command skeletons, then used macros to repeatedly call that file - once generating y_commands code, once generating ZCMD code and once generating strval code. This way I KNEW that all the systems had the same test parameters and I could go experimenting from there. Make sure you also choose a good sample of dialogs to test call - there's no point always calling the first one or the last one, you need to call a large number well distributed through the available IDs for EVERY test. As it is this is complete rubbish!

Ok I got what you've posted.
I'll create myself thousands of callbacks/checks in a file and paste it in the benchmark script to create a proper benshmark test. I'll post the results and scripts of the if else, switch, B-DIAL, FDLG etc. benchmark tests

[iGear Track]

Nice Big