Coding or Interface issue?

Page: 1 2
Nov 28 2008, 4:19 pm
Try this: Don't give your buttons commands until after the client has fully logged in.
Nov 28 2008, 4:52 pm
In response to Xooxer
How would I do that?
Nov 28 2008, 5:40 pm (Edited on Nov 28 2008, 5:46 pm)
In response to Mizukouken Ketsu
In the interface editor, delete the command you set for each button. Then, use winset() to give those commands back to the buttons after the client connects.

[edit]
Ah, wait, you're not using commands, are you? Nevermind, then. :P
Nov 28 2008, 6:36 pm
In response to Xooxer
Yeah, each button's command line has the verb in it.
Nov 28 2008, 7:42 pm
In response to Mizukouken Ketsu
BYOND likes to call those before there's anyone around, which can really mess up your toggles. If there's no command for the buttons before the client connects, then BYOND can't mess with your buttons.
Nov 28 2008, 11:48 pm
In response to Xooxer
This behaviour should have been fixed with 430:

"Buttons in a skin will no longer activate their commands as soon as they are loaded. The issue that the old behavior was intended to address--making sure "say" or ".alt" showed up in the input control in the default skin--has been solved via an update to the default skin. The new behavior is unlikely to cause any problems, and should make life easier for developers who were unhappy with the old behavior."
Nov 29 2008, 5:55 am
In response to Mizukouken Ketsu
Mizukouken Ketsu wrote:
I fail to see how changing the button type will fix my problem. Pushboxes are practically the same thing as radio buttons, only they look better than radios in my opinion.

I haven't used radio buttons (or pushboxes) in a Byond interface before, but if they work like they do in most apps, they're setup so that ONLY one can be chosen in a given group, no matter what... so if the problem does happen to be that more than 1 is getting stuck on, that would be a trivial fix.
Nov 29 2008, 7:07 am
In response to Ephemerality
I'm using pushboxes the same way you'd use radio buttons. I've tried using both, and they both get this problem.
Nov 29 2008, 7:09 am
In response to Schnitzelnagler
So I'm gonna go out on a limb and call this a bug? Click one pushbox, only to activate another one on a different window.
Nov 29 2008, 8:53 am
In response to Mizukouken Ketsu
It might be. Personally, I like to give my radio buttons no commands, and then have a submit button. That would be a good workaround if this is a bug.

Oh yeah, you should also keep the clan var a number. Text is a limited resource, and you should conserve it.
Nov 29 2008, 9:17 am
In response to Jeff8500
This is used to change their visible clan name in their stat panel, so they know what clan they are. Basically to define which clan they are. And I want to stay away from assigning each button its own verb to define the clan, although that's looking like the only sure-fire way to accomplish this task.

So what you're suggesting is assign only the Done/Submit button the verb and have that verb check to see which buttons are selected (true)?
Nov 29 2008, 9:59 am
In response to Mizukouken Ketsu
Yeah, that was the whole point of the snippet I gave you a while back! I would go about doing what you want differently:

client/Command(T)
       var/GET = findText(T,".ClanSelect",1,12) //Look up findText() if you don't know what it does
       if(GET)
              var/CLAN = text2num(copytext(T,12))
              ASSERT(CLAN) //for testing purposes only!
              mob.Clanstuff(CLAN)
              return //don't call any other commands if you find this, prevents extra
                     //overhead (unless you have extra commands, keep this)
       ..() //don't forget to call the parent!


Your button commands would be .ClanSelect50 etc. where 50 is the number. This snippet should work, although there might be an error in there somewhere; it's hard to write snippets in the post box. Need any explaining?
Nov 29 2008, 10:05 am
In response to Jeff8500
I don't get what all that does. I don't see why you'd use copytext() and findtext() procs at all honestly. I barely understand the method I'm currently using as it is (actually more so now that I look at it closer). Mind explaining what each line is and what it does for me? Like that "mob.Clanstuff(CLAN)" line?
Nov 29 2008, 10:33 am
In response to Mizukouken Ketsu
mob.Clan_stuff(CLAN) can be substituted with whatever proc/verb you are currently calling to change the clan, etc.

client/Command() is the proc called when a client attempts to call a verb etc. they don't actually have. It's only arg is the command they attempted to call, which would be .ClanSelect[num] in this case. The command can be absolutely anything, so first, you look for .ClanSelect in the beginning of the command (it should be characters 1 to 11, so the end would be 12). If it's there, use copytext() and text2num() to get the number at the end. Then, do what you want to do with it, and end the proc. You could pretty much remove the Clan_get() (or whatever) proc, and just have client/Command() call a proc that sets the player's clan to whatever.

Your code would look something like this if you were calling mob.Clan_change(CLAN):
mob/login/proc/Clan_change(CLAN)
       clan = Clan2text(CLAN)
       src << "You have joined the [CLAN] clan!"


And don't forget to check if the client's mob actually has the proc with hascall()
Nov 30 2008, 5:44 pm
I figured out a comprimise! :D

//////////////////////////////////////////////////////////////////////////
///Leaf Village Clans///
////////////////////////
mob/Logging/verb
    Clan_Select()
        set hidden = 1
        src.Clan = "[Num2Clan(Clan_Pick())]"
        src<<output("You are now a(n) [Clan]","World")

mob/proc
    Clan_Pick()
        for(var/C in 50 to 60)
            if(winget(src,"LeafClans.Clan[C]","is-checked")=="true")
                . = C
                return C

    Num2Clan(clan)
        switch(clan)
            if(UCHIHA) return "Uchiha"
            if(HYUGA) return "Hyuga"
            if(NARA) return "Nara"
            if(AKIMICHI) return "Akimichi"
            if(INUZUKA) return "Inuzuka"
            if(ABURAME) return "Aburame"
            if(KURAMA) return "Kurama"
            if(SENJU) return "Senju"
            if(TAISPEC) return "Taijutsu Specialist"
            if(CLONESPEC) return "Clone Specialist"
            if(WEPSPEC) return "Weapons Expert"

/////////////////////////////////////////////////////////////////////////
///Sand Village Clans///
////////////////////////
#define PUPPETSPEC 61
#define WINDSPEC 62
#define SANDSPEC 63
#define IRONSPEC 64
#define TAISPEC 65
#define WEPSPEC 66
mob/Logging/verb
    Clan_Select2()
        set hidden = 1
        src.Clan = "[Num2Clan2(Clan_Pick2())]"
        src<<output("You are now a(n) [Clan]","World")

mob/proc
    Clan_Pick2()
        for(var/C in 61 to 66)
            if(winget(src,"SandClans.Clan[C]","is-checked")=="true")
                . = C
                return C
        ASSERT(.)

    Num2Clan2(clan)
        switch(clan)
            if(IRONSPEC) return "Iron Manipulator"
            if(SANDSPEC) return "Sand Manipulator"
            if(PUPPETSPEC) return "Puppeteer"
            if(WINDSPEC) return "Wind Specialist"
            if(TAISPEC) return "Taijutsu Specialist"
            if(WEPSPEC) return "Weapons Expert"


It's not crating verbs for EVERY single clan, and it's not utilizing any mind-numbingly confusing code! :D It may not be the most robust or efficient, but it gets the job done the way I want it to. I also, just as a precaution, changed the group labels in the pushboxes for each window. Every "clan" related pushbox originally had the same group name - Clan - but now it's like "SClan" or "RClan" etc.
Page: 1 2