Brewing, Crafting and Liquids
You all gave such great feedback after my initial release last week that I was compelled to go back over and do a better job, a job that took the concerns and desires of the playerbase into account. In a decision with slightly more forethought, I’m going to be posting here to get your impressions now, so my initial release of this project is spot on. Here are the proposed changes for my upcoming Brewing, Crafting and Liquids patch:
- Brewing will be integrated into the current Design system.
- In addition to this, it will have the follow attributes added: extended description, which will allow players to LOOK AT <liquid> IN <container>; aftertaste, which will send a message to the player at a specific interval after they have drunk the beverage (optional); brewing tool, such as pot, pitcher, etc (more found below), can be supplied, or the default (pot) will be used; and heat source, which is optional, but suggested for liquids such as a hot toddy.
- We’ll be removing the last1p/3p and drink1p/3p attributes, their use being merged into ‘taste’ which will be appended to every drink message, appearing something like this: You quaff down $(description$) from $(container$). $(taste$).
- For beverages only, the current ‘taste’ command will operate identical to the ‘sip’ command, consuming part of the beverage.
- Various drink commands, along with having unique messages, will consume varying amounts of a drink--this feature will be enabled for alcohol and drinks only. Other types, such as salves and poisons and elixirs, won’t be affected. A nonexhaustive list of these drink commands is: sip, taste, drink, chug, quaff, gulp, swig, imbibe, guzzle, swig. I’m taking suggestions on the messages for these, as well as the quantity they should consume.
- Similar to GIVE/TAKE and others, all the drink commands will become operational within the verbmote system, such that ‘drink beer [chugs down $thing as if he was at a phrat party.] will be possible--but please don’t.
- All design rules that can be enforced in the code, will be.
- A tagging system will be added to all designs, following the simple syntax: DESIGN <#> TAG <word>. The DESIGN LIST command will be expanded to take tags as a search attribute such that DESIGN LIST TAGS <tag list> will be possible. Additionally, the command DESIGN COMMS <tag> will be added, sorting through all approved designs of a particular tag, displaying them, what they require to be made, along with a ‘total’ field down the very bottom. While we will need to limit how many tags a design can have, a number is yet to be decided on.
- I’m aware brewing is finicky, excess comms or varying amounts often producing unexpected results. In all ways possible this will be streamlined, such that BREW <design #> will produce as much of the liquid in question as possible, while destroying excess items in a way that has no negative impact on the output. If you miscalculated, why be punished twice?
- All liquid containers will have sizes added to them, such that shotglasses will hold two sips, while vials will hold the standard 50. We’ll compile a list of these containers internally and try to apply appropriate values.
- In terms of transferring liquids between items, the following commands will be added: POUR [<x>] <liquid/container> INTO <liquid/container>. EMPTY <liquid/container>.
- A list of items will need to be compiled that -can’t- use the previous commands. Such a list will include the following, at the very least: artifacts, eggnog, and casks.
- We'll be offering several artifacts to coincide with the release, one to help with vial management and another specifically for brewers. I won't say anything more!
- We’ll reduce all the design costs for Brewing to zero for the first month of release, and open up the design queue for people who have the Cooking skillset to help get through old designs that are being touched up.
- You can now steep in a teapot or kettle, and shake a beverage in a cocktail shaker. Additionally, brewing is also available in cauldrons.
I’m also debating with myself over a few changes I'm thinking about making. I'm wondering if these changes will benefit the players, or create needless hassle. If they're worth the time they'll take to code. Anyway, the questions I have are:
- Should we add the ability to set a design as PUBLIC, reducing all fees associated with it, to encourage community crafting? With Brewing coming out, this could mean a handful of designs (such as basic rum, vodka, whiskey) being available to everybody. I'm concerned about balance, in terms of costs, of making crafters redundant in any respect, or encouraging players to keep tailoring at Inept 0%.
- Should we add the ability for brews to take liquids, as well as solids, as components? 5 sips of vodka, 10 sips of whiskey...it might make an interesting ‘progression’ for more complex brews, and more adventurous brewers, to go through. But, you'd only be able to use liquids available to you, and what if those designs go kaput? It creates a lot of headaches.
- If we go through with the above, I’m thinking of limiting it to MIX command. So you can brew ‘ingredient’ based brews in a cauldron or pot, then you mix ‘liquid’ brews in a shaker or mixer. And then for the ‘steep’ command, we essentially do brewing under a different skin. We could do this anyway, it's just determining how they -look- and how they operate.
- Alternatively, I’d be interested in ideas for crafting ‘teabags’ that any lay person can use to steep their own tea. We could do this really simply by allowing crafters to condense liquids into little cloth pouches...or something.
Anyway before I lose my mind I should wrap this up. I've coded a lot of this (the substantive parts) already, but I'll hold back on releasing until this weekend.
Tok
12
Comments
No seriously. This is awesome. Thank you.
EDIT:
Could add a skill in the trade skills (jewelcraft, tailoring, furniture, etc) at a specific skillrank that gives access to public designs:
"At GIFTED skillrank, the crafter gains access to public designs (DESIGN LIST PUBLIC [tradeskill OR item type]). A design can be set as public via the DESIGN <#> PUBLIC <CONFIRM> command."
Will it be possible to retract designs from public access? Have you considered moving expired designs to the public domain? Can we post other random crafting requests in this thread (o my god I want craftable tattoos)?
YesYesYes @ Public designs.
ETA: Not enough to say OHNO, I still think public designs are a great idea--how many standard pairs of black leather pants does the world need, really?
Would it be possible to add an additional message much like say, incense but instead of smoke it might be:
A wisp of steam snakes up from <container>
Or I guess you could even do smells too.
The mingling aroma of honey and lemon softly wafts up from a steaming cup of lemon tea.
Or in the case of blooming teas:
stir <container>
After so many seconds:
a dried <insert plant blossom> begins to slowly bloom open in a menagerie of color as the tea steeps in
These messages could be chosen to happen once or multiple times depending on what is desired by the crafter.
Other than credit sales, shop taxes are the only source of steady income for a city. I think Delos could do without them, but the cities? Leave 'em be. Also, what Seir said.
Also, let me wear my flask on my hip.
Message #17059 Sent By: Oleis Received On: 1/03/2014/17:24
"If it makes you feel better, just checking your artifact list threatens to crash my mudlet."
Public designs should be opt-in rather than automatic, as some people have already said. I would be pissed if some of my special or personal designs were made public. The idea of having public designs is great, though. Gives newer crafters the ability to make neat things even if they're not confident in their designing abilities.
Also, I really think there should be more benefits to learning crafting skills past Expert rank. As it stands, I only learn to Expert in all of my craft skills just to be able to make custom stuff because it's not really worth transing just to be able to permanence a few designs.
-----------------------------------------------------------------
(The Front Line): Daskalos says, "<-- artifacts."
#ALIAS brewadd {#forall @brewingredients {buy %i;outc %i;~add %i to pot;inc %i};mix pot for @brewitem} "brewing"
#ALIAS gobrew {brewamount=%1;brewitem=%2;brewingredients=@%2;brewvessel=%3;brewadd} "brewing"
#TRIGGER {The pot has nothing in it that needs distilling.} {fill @brewvessel from pot;drop @brewvessel;#math brewamount @brewamount-1;empty pot;#if @brewamount>0 {gobrew @brewamount @brewitem @brewvessel} {#say BREWING DONE, YOU DRUNKARD!}} "brewing"
#TRIGGER {You carefully pour some water into} {#temp {you have recovered balance} {empty pot into still;~fire still}} "brewing"
#TRIGGER {You open the tap and carefully fill the still} {fill @brewvessel from pot;drop @brewvessel;#math brewamount @brewamount-1;empty pot;#if @brewamount>0 {gobrew @brewamount @brewitem @brewvessel} {#say BREWING DONE, YOU DRUNKARD!}} "brewing"
Syntax:
#var f### {item1|item2|item3} - sets components for a brew recipe. Eg #var f123 {raspberry|strawberry|sugar}
GOBREW <#> - starts your autobrewing! Just sit back and enjoy! Eg, GOBREW 5 f123 CUP
--------------------
Now you do!
Message #17059 Sent By: Oleis Received On: 1/03/2014/17:24
"If it makes you feel better, just checking your artifact list threatens to crash my mudlet."
Message #17059 Sent By: Oleis Received On: 1/03/2014/17:24
"If it makes you feel better, just checking your artifact list threatens to crash my mudlet."
I don't much like the idea of auto-public designs either- an opt-in system sounds great, but, there are too many potential issues with expired designs going into the public domain. Singular items are often designed for a specific individual or RP purpose, and I don't think people would really want their wedding band/wedding outfit/special commission going public.
RED:
ruby
crimson
sanguine
Etcetera.
A way to make something default to a set colour instead of grey would be nifty, IMO--I'd prefer that to being able to re-dye something that's been dyed.