New dialog engine uses almost no memory!

Maybe you remember me. I created that dialog engine to handle what player clicked the button.
So you had 1 trigger for all players (how it should be).
It's mainly a helping trigger that you include to make things easier.
But then I read weaaddars post on the battle.net forums where he said that dialogs aren't removed from memory.
So i redid the engine.
Features:
Only one dialog per player is created and used during the whole game!
Means NO LAG, because the dialog is reused the whole time.
Every single local trigger that is being created will be destroyed after use.
Well, it's custom text at the moment, but i will create a GUI-compatible version.
It's only 1 function call and you have assigned a dialog for a player and all triggers that should be called when the buttons are clicked.
With my engine it's just something like: playerid,title,button titles,button triggers,button hotkeys
that's it.

To make it work, you must import the 'Dialog Engine' trigger into your map BEFORE you create triggers that use the engine.
That's because the function must be above the callers in the *.j file.

@weaaddar: It's definitely easier to use than the last one. How do you like it now?

Yay! Now I can make a nice Warcraft Advanced, with balanced races an and easy Race Selection Menu! ^__^

Thanks. Now I just have to figure out how to use this ^_~

If you know custom text, it's easy.
Just call the MakeDialog function with appropriate parameters. Look at the sample map.

Be sure to add the Dialog Engine BEFORE you make triggers that refer to it. Otherwise you have to shift a bit in the *.j file (not nice) so that the Dialog Engine trigger stands above the referring triggers.

Heh your way works but for me where my button names change erg its not fun.

Your thing still seems to be variable intensive, and does it specify hotkeys? Anyway call me old fashion but I like my methods. bj_forLoopAIndex all the way :)

weaaddar, you underestimate me: :)
Button name changing is no problem.
And hotkeys are passed to the function as well.
And there are only 3 (THREE) variables.
And two of them are for your convenience:
They are set to
a) The Player who clicked the button and
b) The Index of the last clicked button, which is [0-4]

Every time you call MakeDialog, not a new Dialog is created, but the old one is taken with new buttons.

I think you looked at the wrong map, because i used hotkeys in the sample map. ;)

for the hotkeys
we can use 'N' etc (letters) and also their ascii code as defined by weadder someone esle in teh forum right?

while im not too familiar with custom code, that function call seems easier enough..

the biggest problem i see is turning all the ways of finding out who the player is (triggering player, owning of unit(triggering unit) etc, into custom code form :)

Not difficult to get the player who clicked the button:
GetLastClicker
And the clicked button's index:
GetLastClickedButtonIndex
These two variables will be set when a button is clicked.
Just look at the sample map.
In custom text it's:
udg_GetLastClicker and udg_GetLastClickedButtonIndex
udg means UserDefinedGlobal

Unfortuantly your method doesn't suit my needs. Mainly becuase with your method I would need to do a specific trigger per each button clicked (I pefer If then Elseif...) I also need buttons to change what they say and do. And so I would need alot more triggers. Don't get me wrong I'm not bashing your engine. Its just so much easier to define 1 bit of code in my response trigger and 1 bit of code in my button generator. And just have if then elses control it and loops running through it. (my bag uses the same bit of code for 5 buttons and 5 responses and even with diferent hotkeys!!)

Think of this: You can specify ONE response trigger (just use the same 5 times). In this trigger you can do 'if elseif' and so on. And you don't need the Dialog Button Array you use, because you get a variable GetLastClickedButtonIndex. So in the response trigger you can check who clicked the button and what button number. Everything you want.
The engine is MADE to have the buttons change their values. MakeDialog can be called with any button titles.

So you have:
1 MakeDialog call
and
1 Response Trigger where you do your looping stuff

I do it this way and it works well for me. And the best thing: It shortens code!

But for orginization sake I enjoy my 2d array. Anyway I'd rather keep my dailog button array, as it affords me many things.

I realize you return a lastclickedbuttonindex but if its a number like 36 or whatever I have no idea what it corresponds with. as i know it as db[index(8,4)]

lastclickedbuttonindex is between 0 and 4 and is the index of the button clicked in this dialog. It's always between 0 and 4 and won't go to 36.
0 is the top button and 4 is the bottom button of the dialog.

you don't understand I have multiple dialogs, and for ease of use since I only want 1 response trigger I use 2d dailog button array. So if it returned 4 then well it wouldn't be so good.

Why do you have multiple dialogs? You can only show one at a time?
But if you say you need them... I never need more than one dialog per player.
Maybe more dialogs make the things easier for you?
Don't know.

Wait! Maybe that's why:
You make multiple dialogs, but you don't show them at the same time. You use DialogDisplay only for one dialog at a time. My engine doesn't need that many dialogs. DialogDisplay is replaced with my MakeDialog.
The parameters are how the dialog shall look and what it shall do.
My engine has no global dialog buttons nor does it use ANY of the normal dialog functions. It's only 1 function you need to use to create a dialog.
Take a look at the sample map: No dialog function, only in the engine code.
It's just MakeDialog. How could it be simpler? And it can be looped, ifthenelsed and all that stuff. That works just fantastic. That's why I built it.

That's it: My engine is able to handle all the things you want it to in an easy and comfortable manner.

The sample map shows the engine's true power. You don't need to use it though.

And for the bag system: It wouldn't be work good for the bag system. You would have 2 triggers: the engine and the bag system. Or you would have to include the engine code into the bag system. That would be a mess!
I used the engine for example to create a menu with several submenus in a few seconds. That's its true strength.

I'm gonna take a look at this later and see how it works :)

I'll let ya know if I find any bugs

I only use 1 dialog this is true, but currently there are different acess points to diferent menu (3), and I only use 1 for my response if I did it any other way i'd be look at alot more.