System Dialog System

[TriggerHappy]

Dialog System​

TriggerHappy187​

Introduction :

This system allows you to make dialogs easier.

Requirements :

• ABC ( Included in the map )

Changlog:

Spoiler

Version 1.1

• Fixed TriggerAction leak.
• Removed bj_ prefixes.
• Struct variables are now private.

Version 1.0a

• Fixed the destroy method
• Tidied up the demo usage

Code :

library Dialogs requires ABC

globals
    private constant integer BUTTON_AMOUNT   = 16
endglobals

struct Dialog
    
    private button array Button[BUTTON_AMOUNT]
    private integer ButtonCount
    private dialog Dialog
    private string name
    private string array ButtonName[BUTTON_AMOUNT]
    private trigger DIALOG
    private string clicked
    
    static method create takes string name returns Dialog
        local Dialog d       = Dialog.allocate()
        set d.Dialog         = DialogCreate()
        set d.name           = name
        set d.ButtonCount    = 0
        set d.DIALOG      = CreateTrigger()
        
        call SetDialogStructA(d.Dialog, d)
        
        call TriggerRegisterDialogEvent(d.DIALOG, d.Dialog)
        
        return d
    endmethod
    
    method Conditions takes nothing returns boolean
        return true
    endmethod
    
    method ShowAll takes nothing returns nothing
        local integer i = 0
        call DialogSetMessage(this.Dialog, this.name)
        loop
            exitwhen i > 11
            call DialogDisplay(Player(i), this.Dialog, true) 
            set i = i + 1
        endloop
    endmethod
    
    method ShowPlayer takes player p returns nothing
        call DialogDisplay(p, this.Dialog, true) 
    endmethod
    
    method createButton takes string ButtonName returns nothing
        set this.ButtonCount                  = this.ButtonCount + 1
        set this.Button[this.ButtonCount]     = DialogAddButton(this.Dialog, ButtonName, 0)
        set this.ButtonName[this.ButtonCount] = ButtonName
    endmethod
    
    method createAction takes code func returns nothing
        call TriggerAddCondition(this.DIALOG, Condition(func))
    endmethod

    method result takes nothing returns string
        local button b = GetClickedButton()
        local integer i = 0
        loop
            exitwhen i > BUTTON_AMOUNT
            if this.Button<i> == b then
                return this.ButtonName<i>
            endif
            set i = i + 1
        endloop
        return null
    endmethod
    
    method onDestroy takes nothing returns nothing
        call ClearDialogStructA(.Dialog)
        call DestroyTrigger(.DIALOG)
        call DialogDestroy(.Dialog)
    endmethod 
    
endstruct

    function ShowDialog takes Dialog d returns nothing
        call d.ShowAll()
    endfunction 
    
    function ShowDialogPlayer takes Dialog d, player p returns nothing
        call d.ShowPlayer(p)
    endfunction
    
    function AddButton takes Dialog d, string ButtonName returns nothing
        call d.createButton(ButtonName)
    endfunction
    
    function AddAction takes Dialog d, code func returns nothing
        call d.createAction(func)
    endfunction
    
    function ClickedButton takes Dialog d returns string
        return d.result()
    endfunction
    
    function GetDialog takes nothing returns integer
        return GetDialogStructA(GetClickedDialog())
    endfunction
    
    function ClearDialog takes Dialog d returns nothing
        call d.destroy()
    endfunction
    
endlibrary</i></i>

Demo Usage :

Spoiler

scope test initializer InitTrig

globals
    Dialog test
endglobals

private function Actions takes nothing returns boolean // MUST HAVE RETURNS BOOLEAN
    local Dialog d = GetDialog() // This is needed!
    if ClickedButton(d) == "Yes" then // Checks if the button that was clicked was "Yes"
        call BJDebugMsg("Damn Straight!")
    elseif ClickedButton(d) == "No" then // Checks if the button that was clicked was "No"
        call BJDebugMsg(".....Shutup")
    endif
    call ClearDialog(d)
    return false // THIS MUST BE AT THE END OF THE FUNCTION
endfunction

private function CreateDialog takes nothing returns nothing
    set test = Dialog.create("Do you like Clan Mapz?") // Creates the Dialog + it's name
    call AddButton(test, "Yes") // Creates a button call "Yes"
    call AddButton(test, "No") // Creates a button call "No"
    call AddAction(test, function Actions) // The actions for the dialog
    call ShowDialog(test) // Shows the dialog to all players
endfunction

//===========================================================================
private function InitTrig takes nothing returns nothing
    local trigger t = CreateTrigger()
    call TriggerRegisterTimerEventSingle(t, 1.00)
    call TriggerAddAction(t, function CreateDialog)
endfunction

endscope

 

[saw792]

Why are you naming some of your globals/struct members bj_...?

 

[Vestras]

This already exists, made by cohadar.
Make this not use any attachment systems and it'll might be better. (Haven't tested it)

 

[Flare]

Dynamic triggers with triggeractions... if you are going to continue with dynamic triggers, at least use triggerconditions. Just convert the codefunc parameter to a boolexpr with Condition () or make the function take a boolexpr parameter, and use TriggerAddCondition instead of TriggerAddAction. And mention it in documentation that the function used for AddAction must return a boolean (IIRC, you should return false with dynamic triggers) i.e.

function DialogClickedFunction takes nothing returns boolean
...
return false
endfunction

...
call AddAction (someDialog, Condition (function DialogClickedFunction))

    function ClearDialog takes Dialog d returns nothing
        call d.onDestroy()
    endfunction

... you don't call the onDestroy method, that on it's own isn't very useful, since it doesn't recycle the struct index - call d.destroy () instead

    function ShowDialog takes Dialog d returns nothing
        call d.ShowAll()
    endfunction 
    
    function ShowDialogPlayer takes Dialog d, player p returns nothing
        call d.ShowPlayer(p)
    endfunction
    
    function AddButton takes Dialog d, string ButtonName returns nothing
        call d.createButton(ButtonName)
    endfunction
    
    function AddAction takes Dialog d, code func returns nothing
        call d.createAction(func)
    endfunction
    
    function ClickedButton takes Dialog d returns string
        return d.result()
    endfunction
    
    function GetDialog takes nothing returns integer
        return GetDialogStructA(GetClickedDialog())
    endfunction
    
    function ClearDialog takes Dialog d returns nothing
        call d.onDestroy()
    endfunction

Lame BJ equivalents - those functions are pretty pointless. The struct methods are perfectly usable, so why do you need an extra function to call them?

And I can't find where you are using that Conditions function

This already exists, made by cohadar.

And, your point being? There's numerous attachment systems in existence, but did it stop you from making one? If someone wants to make a system, they can, and there's no reason why anyone should try and stop them

 

[Vestras]

And, your point being? There's numerous attachment systems in existence, but did it stop you from making one? If someone wants to make a system, they can, and there's no reason why anyone should try and stop them

You wanted my system to be better than the others too - I just tell him what to do in order to make this better.

 

[saw792]

The difference between attachment systems and pretty much any other system is that creating a new attachment system DOES require it to be better than other systems. If it is not it provides no advantage and users will stick with more familiar/trustworthy/tried and tested systems.

This is not the case for systems such as this. Systems of this nature are not generally popular, and thus are less tested and develop less of a following. It is far more likely for a person to search for/ask for a dialog system than they will for CDS (an example name of a dialog system), in contrast to attachment systems where people will search for CSData over the generic category.

The point I'm trying to make is, this sort of system can get away with being 'worse' than others as long as it works, and does what is says it does. A new attachment system cannot get away with anything less than the best.

 

[Flare]

You wanted my system to be better than the others too

I did? I don't remember wanting that...

I just tell him what to do in order to make this better.

Well, system independence isn't really an option here - with timers, you have the option of looping through instances on, well, a timer With dialogs, you don't have the same freedom since the alternative is O(n) searches, and attachment > that

On further inspection...

    method createAction takes code func returns nothing
        call TriggerAddAction(this.bj_DIALOG, func)
    endmethod

    method ShowPlayer takes player p returns nothing
        call DialogDisplay(p, this.Dialog, true) 
    endmethod

Lame BJ methods Both of those seem like something the end-user can/should do themselves (createAction is sort-of useful, but not very)

 

[TriggerHappy]

The "BJ" Functions are just there incase the user isnt used to , or gets confused by structs.

@Flare

Dynamic triggers with triggeractions... if you are going to continue with dynamic triggers, at least use triggerconditions. Just convert the codefunc parameter to a boolexpr with Condition () or make the function take a boolexpr parameter, and use TriggerAddCondition instead of TriggerAddAction. And mention it in documentation that the function used for AddAction must return a boolean (IIRC, you should return false with dynamic triggers) i.e.

lol , sorry not understanding what your getting at here.

EDIT :

1.0a released.

 

[saw792]

Triggeractions leak. Triggerconditions don't, and are executed faster, I believe.

 

[TriggerHappy]

Yes but i don't see what he wants me to do with 'em? +rep

 

[saw792]

He wants you to change your TriggerAddAction to TriggerAddCondition...

 

[TriggerHappy]

oh But doing that just makes it more confusing for the user, since conditions must return a boolean. Couldn't i just remove the leak and it would be better.

 

[Vestras]

I don't think you get it - with triggeractions you can't remove the leaks.

 

[Flare]

When you destroy a trigger, events and trigger conditions (AFAIK) are removed fine, but trigger actions aren't. There is an action to remove trigger actions, but it doesn't actually work So, when the trigger is destroyed, the trigger actions are left floating around, doing nothing, being useless, and leaking

It may be more confusing, but it's safer


Alternatively, you could let the end-user handle the event registration and such i.e. the system handle dialog creation, adding buttons and so on, but end-user handles how they are 'applied' to triggers, so they could create the dialogs, then add the dialog events to pre-existing trigger(s) - that way, no dynamic triggers on their part, no leaking trigger actions. Only problem would be a little extra work, but in the interest of not breaking things, it seems like a reasonable deal

 

[TriggerHappy]

That is too much work imo, for probably 1 leak. I mean users usually only create 1 dialog in maps, at the most 5.

 

[Flare]

That depends on the map - what if you had a quest system that relied on dialogs for accepting/declining the quest? Perhaps an inventory system that used a quest (if, say, you have multiple inventory 'pages' and the dialog lets you pick what page to view).
Or just remove anything relating to trigger creation - as long as the end-user has access to the dialog variable, they can make the triggers themselves, so you rid yourself of any association with dynamic triggers

And 1 leak is still a leak - may not be much, but taking such an attitude towards leaks isn't a good idea, it all builds up

And

Submissions with memory leaks will not be approved.

Anyway, it's very little work - add some bit of documentation, change TriggerAddAction to TriggerAddCondition, add Condition () around your existing action, is it really that hard?

 

[BRUTAL]

i like this system, its pretty simple and easy to use
but whats this talk about 1 leak? will it affect gameplay alot if dialog is used like...medium ish; not alot, but then again not alittle : s

 

[Azlier]

Why is this any better than this?

EDIT: Oh. Vestras mentioned it. Nevermind then, I guess.

 

[TriggerHappy]

Alright, even though this is old.

Updated.

 

[Azlier]

Oh, this isn't new? Way to go, Brutal! You caused me to post in an old thread Meh, why don't I look at dates?