1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

How do I make/edit buttons and menus? Making a big mod.

Discussion in 'Help' started by vriskybusiness, Oct 20, 2016.

Tags:
  1. vriskybusiness

    vriskybusiness Potential Patron

    Joined:
    Oct 20, 2016
    Messages:
    2
    Likes Received:
    0
    I want to make an elaborate Homestuck dialogue/scenario mod similar to Slave Bazaar and Pony Pack. Once I understand how to rig up an interface I can dive right in. I've had a lot of fun editing these frameworks to suit my purposes, but I'm feeling really restricted by the limited buttons.

    How do I create/edit menus of clickable buttons like those seen in these mods? I haven't had any luck finding a relevant tutorial, or figuring out quite how the buttons work by picking apart the files of these mods. Are the buttons stored in the .swf itself? That seems unlikely to me but I really have no idea.
     
  2. Samoth

    Samoth Avid Affiliate Content Creator

    Joined:
    Feb 13, 2016
    Messages:
    95
    Likes Received:
    50
    It's part of the DialogueActions mod. I believe the specific commands are [button#_on] and [button#_off], # being any number between 1 and 10.

    [Buttonall_off] removes all buttons from the screen. The button#_on function enables a specific button.

    Dialogue for a button falls under the button#: line (i.e. button1_on would then allow dialogue pertaining to button1: to function).

    The documentation of DialogueActions explains more about this. I'd advise making some simple "fake" dialogue code to test it out first, get a feel for it. It's what I've done for a lot of things I ended up using and I feel like it's a helpful thing to do. Just make sure if/when you publish the dialogue to mention that this mod is required for the dialogue to function.
     
  3. vriskybusiness

    vriskybusiness Potential Patron

    Joined:
    Oct 20, 2016
    Messages:
    2
    Likes Received:
    0
    Thanks! That was a fast response. I've been fooling around with basic dialogues for years and just found out about menu capabilities, I'm ready to tackle this. The mods I mentioned were great inspiration and very creative implementation of what's possible but I wanna go bigger. I intend to make a regular hobby of this mod for a couple months.

    Now that you've handed me the blueprints for menus, the biggest stumbling block I see on the horizon is how, specifically, I want to implement multiple "phases" of dialogue like many dialogues have. I've seen it approached with a couple different coding styles, triggers, and progressions, but nothing's as sophisticated as Slave Bazaar. I'm definitely gonna ask WeeWillie if I can build my concept directly off his framework. I doubt I'm smart enough to quickly figure out a save/load system like his mod has, so that's a big factor in how I want to approach this.

    I see that he hasn't been online in almost a week, so if anyone knew how to reach him so I can get an answer quickly and start seriously working on this, I'd appreciate it.
     
  4. Pim_gd

    Pim_gd Swell Supporter

    Joined:
    Jan 25, 2013
    Messages:
    721
    Likes Received:
    50
    So, I'll explain a bit about how his thing works...

    Basically, what WeeWillie is using are called "Object variables". These are like regular variables, but they have a period in their name. They have the same behaviors as regular variables, but you can use them in certain DA functions, such as saving and loading, or copying variable values.

    Here's the documentation, it's a bit lengthy. Maybe read this and the rest of the post and see if you can make sense of it.

    Object variables are a fancy term for "This variable's name starts with X."
    You can manually create "object variables" by adding variables to your initial_settings line like this:

    initial_settings:{"a.var1":0, "a.var2":0, "a.var3":0}

    And you'll have an object variable "a" with 3 attributes (sub-variables), "var1", "var2" and "var3".
    Great! So what are they useful for?

    DialogueActions uses object variables for advanced variable manipulation.
    You can greatly simplify complex dialogues with object variables.

    An example.

    You're writing some overly complex dialogue in which you can train slaves and equip them with (parts of) various outfits.
    Now, this would require you to keep track of over a hundred variables normally... about 10 or more per outfit, 10 outfits...

    It's a total mess.

    You don't want to write tons and tons of lines for putting all the clothes on (or loading them from char codes for that matter!)

    So what do you do?

    You use object variables.

    [COPYOBJECT_1_Outfit1._da.clothes.]

    With one trigger, you can copy all her clothes to an object...
    and you can load it back in later.

    ...

    Huh, but it copies everything. And you want the piercings and such to be compatible... oh, you mean outfits only consist of bra (top), panties, shirt (tops), pants, socks (legwear, legwearB) and shoes (footwear)?

    No problem.

    First, define an object for what an outfit "is".

    [DEFINEOBJECT_OutfitInfo._top_tops_panties_bottoms_legwear_legwearB_footwear]

    Then... copy using the object!

    [COPYOBJECT_1_Outfit1._da.clothes._USING_OutfitInfo.]

    But there's even more powerful things you can do with this...

    Imagine you had a shop where you can buy outfits. You have to display them on some sort of mannequin.

    You're not gonna weave the shop through your main dialogue file... that'd be a nightmare to manage.
    So you create a separate store dialogue file.

    Aww crap, how are you going to move 100+ variables?

    Well, what if we defined the Outfits into one big object?

    Change
    [COPYOBJECT_1_Outfit1._da.clothes._USING_OutfitInfo.]
    into
    [COPYOBJECT_1_Outfits.Outfit1._da.clothes._USING_OutfitInfo.]

    Then...

    [REGISTERGLOBALS_Outfits.]

    And voila! Everything in Outfits. is in the global namespace!
    [/code]

    You see, when you have 2 variables, like "MyVars.var1" and "MyVars.var2", you can use them in your dialogue as normal... but when you have to save them, you have to specify both.

    Code:
    [SAVESETVARS_name_variable1_variable2_variableN] Creates a savefile with name if not exists and adds the variables to the savefile. Supports objects. See "About variable scopes.txt" in the documentation for more information regarding savefiles.
    [SAVEGETVARS_name_variable1_variable2_variableN] Loads from a savefile with the supplied name the listed variables from the savefile. Supports objects.
    [SAVEREMOVEVARS_name_variable1_variable2_variableN] Removes variables from a savefile. Supports objects.
    [SAVEDELETE_name] Deletes a savefile.
    

    To save both of your variables, you'd have to call [SAVESETVARS_saveFileName_MyVars.var1_MyVars.var2]. This doesn't seem that bad, but say you have 10 variables...

    [SAVESETVARS_saveFileName_MyVars.var1_MyVars.var2_MyVars.var3_MyVars.var4_MyVars.var5_MyVars.var6_MyVars.var7_MyVars.var8_MyVars.var9_MyVars.var10]

    And it becomes a pain. Plus, if you're writing a big dialogue, you've got multiple places that use all these variables, and... well, you spend more time managing your variables than writing your dialogue! Argh!

    Enter the "Object variable" - the period. Each of these variables is prefixed with "MyVars.". Because of this, you can reference them like that... And just save the object.

    [SAVESETVARS_saveFileName_MyVars.]

    Tadaa, all 10 variables saved. And if you ever add an 11th one, it's also saved. Great. Can we build WeeWillie's Bazaar now? Well, no, this was the first trick.

    The second trick lies in that DialogueActions ALSO uses Object variables. Well, at first it was a way to keep things in their separate namespace (make the names logical), but ... it turned out to be useful. Of specific interest is the clothing:

    Code:
    da.clothes.<clothingType>.<colorComponent> {read and write} 
    --clothingType = any of these: "ankleCuffs", "armwear", "bellyPiercing", "bottoms", "collar", "cuffs", "earring", "eyewear", "footwear", "gag", "headwear", "himBottoms", "himFootwear", "himTop", "legwear", "legwearB", "nipplePiercing", "panties", "tonguePiercing", "top", "tops"
    --colorComponent = any of these: "r", "g", "b", "a", "r2", "g2", "b2", "a2". r, g, b and their r2, g2, b2 cousins are from 0 to 255. a and a2 are from 0 to 1
    da.clothes.<clothingType> {read and write} - set a lot in one go. Formats: Type,R,G,B,A,R2,G2,B2,A2 OR Type,R,G,B,R2,G2,B2 (might set A and A2 to 1) OR Type,R,G,B,A OR Type,R,G,B - see the table below for which one you need
    
    For clothes, clothingType (Loader mod clothing may use different amounts of values, which is why DA supports 8 RGBA for all)
    [panties]   3 RGB values
    [bottoms] (her pants)  6 RGB values
    [legwear]   8 RGBA values
    [legwearB]   8 RGBA values
    [footwear]   6 RGB values
    [top]  (her bra)  3 RGB values
    [tops]  (her shirt) 4 RGBA values
    [armwear]   3 RGB values
    [eyewear]   3 RGB values
    [headwear]   6 RGB values
    [tonguePiercing]  3 RGB values
    [nipplePiercing]  3 RGB values
    [bellyPiercing]   3 RGB values
    [earring]   3 RGB values
    [collar]   6 RGB values
    [cuffs]    6 RGB values
    [ankleCuffs]   6 RGB values
    [gag]    3 RGB values
    [himTop] 3 RGB values, male body only
    [himBottoms] 3 RGB values, male body only
    [himFootwear] 3 RGB values
    

    You can see that "da.clothes." contains the girl's entire outfit. "da.clothes.panties." contains all the color components of the girl's panties. If you could save/load these variables, then you could save/load the girl's clothes! (Also his clothes.)

    So [SAVESETVARS_saveFileName_da.clothes.] will save her and his ENTIRE outfit. [SAVEGETVARS_saveFileName_da.clothes.] will LOAD her and his entire outfit.

    That's trick 2. Like this, WeeWillie is able to persist outfits across sessions. There's still more tricks left.

    WeeWillie only wants to save specific clothes as part of an outfit, AND he wants to save MULTIPLE outfits. So how do we go about that?

    One way to do this is to make multiple savefiles. That's the easy way out - just make a separate savefile per girl - that way you can just dump the clothing variable in there. But if you do that, there's no easy way to, say, manipulate a girls outfit whilst another girl is on the screen.

    So what WeeWillie does is he defines an object variable for each girl to store the clothes in. If you do some digging you can find the moment it's applied:

    [COPYOBJECT_0_da.clothes._Slaves.slave1.CurrentOutfit.]

    What COPYOBJECT does is explained in the documentation, but a short version is "copies values from one set of variables to another". Basically, da.clothes.panties is set to whatever Slaves.slave1.CurrentOutfit.panties was set to.

    WeeWillie loads the girl's starting outfit whilst the screen is black, copies the clothing into an object variable, saves the object variable, and then he has the girls clothing stored in a savefile as a separate object variable.

    So how does he only target HER clothes?

    One way to do it would be to copy each variable by hand... [SETVAR_Slaves.slave1.CurrentOutfit.panties_da.clothes.panties]

    But that'd be a huge pain. Instead, he first defines an object structure - a list of variables, as it were.

    [DEFINEOBJECT_OutfitInfo._panties_bottoms_legwear_legwearB_footwear_top_tops_armwear_headwear]

    Then he copies values using this structure.

    [COPYOBJECT_1_Slaves.slave1.CurrentOutfit._da.clothes._USING_OutfitInfo.]

    Code:
    [COPYOBJECT_layers_targetObjectVariable._sourceObjectVariable.] Copies all variable values from sourceObjectVariable to targetObjectVariable, up to <layers> deep. 0 layers means "all layers". Keep in mind that object variable notation requires a period at the end of the variable name. See "About object variables.txt" in the documentation for further details.
    [COPYOBJECT_layers_targetObjectVariable._sourceObjectVariable._USING_structInfoVariable] COPYOBJECT, but uses structInfoVariable to determine which variables need to be copied. Only variables present in both structInfoVariable and sourceObjectVariable will be copied.
    [DEFINEOBJECT_objectVariableName._variableName1_variableName2_variableNameN] Creates variables objectVariableName.variableName1 and so on. Initializes them to 0. Useful for COPYOBJECT USING. See "About object variables.txt" in the documentation for usage examples.
    

    So that's the trick behind the clothing.

    Ah, if you're wondering how he decides what variable to use - he has separate Dialogue.txt's for each girl, so he just starts each dialogue by loading the savefile and then using the variable with the number of that dialogue (Girl1.txt is about slave1...)

    As for menu progression, this is handled via the object variable "Progression." which contains a FileID, a Menu, and NewVisit. The FileID is used to determine what file you came from (were you playing with a girl or were you in the store?), the Menu is used to handle button logic ([menu_*Progression.Menu*], and menu_menuBuy etc as lines), and the NewVisit is used to determine... I don't know, it looks like it's being used to determine whether this is the first time visiting, but I don't know whether that's for a girl or for the Bazaar itself.

    ---

    As for the buttons, I suggest you take a look at Store.txt in WeeWillie's Slave Bazaar, keeping in mind the thing about Object variables for clothing I just told you.
     
    Slingerbult and DrZombi like this.