Building Basics

Bella raises a hand and is just mildly curious as to the topics that will be covered.

Swift says "I'm going to start at the basics of @-commands vs. +-commands, attributes (and how they apply to building), and go on to specific commands used in building. After that I'm going to discuss style vs. Standards."

Swift says "This is all very loose and if we get into an area of discussion that is intriguing that I didn't plan on covering, I'm not going to sweat it. Nobody's getting any credit hours for this and I don't feel overly-beholden to stick to a specific itenerary. I will try to keep things brief and interesting though."

Swift says "Okay, for those of you who are here, have any of you ever built before, or have any experience building on any other mu-framework?"

Bella raises a hand.

Pin does too.

Swift says "For those of you who have built before, you're probably going to be more familiar with what are known as @-commands or 'Hard Coded' commands than most people."

Swift says "When you build, until you develop your own style and figure out how you want things built (if you're building for your own game) or how your boss wants them built (if you're building for someone else's game) @-commands are probably what most of you will use. That's perfectly fine, in fact, I would be highly surprised if people learned to build using soft-coded commands over hard-coded ones, to be perfectly honest."

Swift says "And if you have a question at any time, please feel free to ask...this isn't a formal class, and I'm not taking off points from anyone's grades ;)"

Pin has reconnected.

Pin has partially disconnected.

Swift says "Okay. So, we're at the first main topic - what is the difference between @-commands (hard-coded commands) and other (softcoded) commands? If a command starts with an @ symbol, that means that it USUALLY is hard-coded into the mush server. Meaning it's part of the game when you compile it and first start of it...it's actually programmed into the mush server code."

Swift says "Soft coded commands are commands that use hard-coded commands and functions to achieve a task or perform a command. Most role-players are familiar with the @emit command and softcoding it into a more easily/quickly used command (I generally use . to emit) Softcoded building commands work in the same basic way. If it helps you to think of them as 'hot-keys' or 'macros' then feel free to do so...but softcoded commands can be, and usually are, way more powerful than a simple hot-key combination in another program."

Swift says "That being said, you can softcode commands later on down the road that use the hardcode commands to make your workload easier. I'll give examples of this later if anyone is interested."

Swift says "Let me pause here for a moment and ask if there are any questions currently?"

Swift says "Alright, continuing on then"

Bella says "No. Sorry."

Swift dropped Building Class Test Object.

Swift says "Okay, the next topic then is Attributes."

Swift says "Most of you should be familiar with the examine command, if not, type 'ex test'"

Building Class Test Object(#1515V) Type: THING Flags: VISUAL Owner: Swift Key: *UNLOCKED* Credits: 1 Accessed: Sat Sep 22 20:44:04 2007   Modified: Sat Sep 22 20:42:40 2007 Zone: [ZONE] Plotmaster Zone Object(#1495IV$) Powers: No exits. Home: Building Wonderland(#76RJz) Location: Building Wonderland(#76RJz)

Swift says "You'll notice that it is an 'empty' object...by 'empty' I mean that it has no attributes set on it, but there's still some information on there. It has a type, it has a flag (visual, something I set on there so you could examine it), an owner, something called a Key, access information, zone info, a home and a location."

Swift says "Now, I'm going to type '&d.test-attribute test=This is a simple test attribute.'"

Swift says "If you 'ex test' again, you'll see that it now has a new value on there..."

Building Class Test Object(#1515V) Type: THING Flags: VISUAL Owner: Swift Key: *UNLOCKED* Credits: 1 Accessed: Sat Sep 22 20:47:10 2007   Modified: Sat Sep 22 20:46:51 2007 Zone: [ZONE] Plotmaster Zone Object(#1495IV$) Powers: D.TEST-ATTRIBUTE: This is a simple test attribute. No exits. Home: Building Wonderland(#76RJz) Location: Building Wonderland(#76RJz)

Swift says "Does everyone understand where that attribute came from?"

Pin nods.

Swift says "Okay, assuming from the lack of outraged cacophony that everyone's on the same page ;), That is what is known as an attribute, and using & = sets an attribute named on containing "

Swift says "Now, I know this is looking suspiciously like a coding class instead of a building class, however, bear with me for a moment."

Swift says "Any multi-desc systems (such as Keran's Weather & Time system) or any home-brewed softcode multi/variable-desc system will use attributes of some sort to store the various attributes in. My game, Winter's Edge, uses Keran's W&T, which uses many different attributes for describing one room."

Swift says "To see an (older) example of this, type: ex #509/*-desc"

WEATHER-DESC: %t[u(#38/long-weather)] [u(#38/tree-weather)] MOON-DESC: [u(#40/moon-phase)] UNCHANGING-DESC: %r%tThe pathways of the park twist and turn between flower beds, trees, and carefully sculpted bushes. Rumored to be protected by the magic of the mages of Mimisbrunnur, the weather here in the park is usually milder and more pleasant than that outside its confines. At the north end of the park a gallows and stockade stand, an ominous reminder of swift justice here in the kingdom. NIGHT-DESC: %r%TThe pathways are warrens of shadows. Few, if any, people can be seen in the park after dark, most having retired to inns or their homes already at the dying of the light. DAY-DESC: %r%tThe light of day reveals the paths and beds beneath the trees. People can be seen wandering out amongst the beds and trees, enjoying the park and greenery that is so uncommon to the lands around Vintermor. DAWN-DESC: %r%tThe newly breaking light of day lightens the shadowed park, revealing attendants and gardeners carefully clipping, tending, and cultivating the park areas, keeping it clean for the Crown and the attendants of the park. DUSK-DESC: %r%tThe light leaves the park, slowly at first then with a gathering rapidity as night lowers once again on the pathways of the park. Lamplighters go about their duty, pushing back some of the encroaching darkness with pools of light along the paths of the park. People can be seen starting to leave. SPRING-DESC: %r%tThe trees, flowers, and shrubbery begins budding and throwing life out to the end of their stems, beginning to blossom and unfurl their beautiful palettes to the world. SUMMER-DESC: %r%tThe grounds of the park abound with people, picnicking and playing draughts, enjoying the placidity of the park and its gorgeous flora and fauna during the daytime, and lovers stroll hand in hand at dusk, enjoying the romantic mood of summer in the park. Summer, however brief, is here and clearly being enjoyed be the people of Vintermor. AUTUMN-DESC: %r%tLeaves drift to the ground in colorful profusion, reds, yellows, oranges and browns all join together to make a beautiful palette of colors for the people of Vintermor to enjoy. The flowers bend their dying heads to the ground, old men in their own, tending towards the earth and final sleep. WINTER-DESC: %r%tWinter has come to Vintermor and outside the park, people are feeling its harsh bite. Some little snow gathers on the grounds of the park, enough to make it an enjoyable winterland, though not enough to impede the guests of the park in their daily activities. While still cold, the air here lacks that certain glacial bite that Vintermor is well known for.

Shereem says "Like when you set your +finger on the mush?"

Swift nods, "Exactly like when you set your +finger information on mush

Shereem says "I always manage to mess mine up"

Swift says "An interesting thing to note here is the WEATHER-DESC and the MOON-DESC on #509. If you notice they say something like [u(#38/long-weather)]"

Swift says "Here the attribute is holding a function, in this case u which reads some information off of another object. (if you don't understand u I can explain it later). This allows you to build dynamic buildings and systems within your game that do not have to remain static at all."

Swift says "And now, before moving on to the actual @-commands used and the lab portion of the programme, does anyone have any questions?"

Pin says "None here."

Emerson has disconnected.

Swift says "Okay then. The first command we're going to work with is @dig"

Swift says "And there are help files for all of these things, so if you get lost in here and don't want to stop me, or if you're reading this online, feel free to connect to a game and type help @ ."

Swift says "Okay, You can come up with your own room names while we're doing this if you want, but chances are we'll be safer if you use  Room with your Name in place of ."

Swift says "The way the @dig command works is thus:"

Swift says "@dig =Exit in;alias;alias;etc.,Exit Out;alias;alias"

Swift says "so, if I want to dig a room named 'Swift's Office' with an exit named 'Swift's Office' and an alias of SO, with an Out exit aliased with 'O', it would look like this:"

Swift says "@dig Swift's Office=Swift's Office;SO,Out;o"

Swift says "Feel free to go ahead and try the command yourself, with your own room."

Swift says "Hmmmm...Give me a sec, I think it's going to perm-deny you guys"

Pin says "You've set quota?"

Swift says "You're limited to 20, but I need to check the ownership on this room."

Swift says "Okay, you guys should be able to do it now, but don't re-enter the command. Instead that takes us naturally into our next command."

Swift says "You'll note that when you did the @dig, it created the room, and gave you a dbref number for it. That's the dbref number for that room. The next command that we're going to use is @open."

Swift says "What I want you to do is in this format @open ;alias= "

Swift says "So if your room dbref is #9999 and you want an exit named Swift's office it'd look like this: @open Swift's Office;SO=#9999"

Swift says "Just make sure you put your own room's dbref number in there."

Swift says "And if you're still having problems, let me know so I don't get too far ahead of you."

Swift says "And conversely, if you /haven't/ done the @dig command, please do that now."

Pin says "Permission denied on the @open."

Swift says "Try now"

Pin says "No luck."

Shereem says "It says permission denied."

Swift says "Okay, one more time, try now"

Pin says "link_ok should do it?"

Pin says "OK."

Swift says "Needs Open_anywhere apparently"

Swift says "Link_ok only works on exits back to."

Swift says "At least on TM3"

Pin hrms. Used to Penn, I guess

Swift nods

Swift says "YMMV"

Swift says "Shereem - feel free to @dig or @open as is most appropriate"

Shereem says "got it"

Swift says "Now, you'll notice if you 'look' at the room we're currently in, the newer rooms don't have that nifty neat  out there to the right of them, letting you know what the handy alias to that room is."

Swift says "That's because if you want there to be a /visible/ alias, you'll have to set your exit name up to display it. (there are ways around it in other code like parents and @conformats, but for a basic class, let's just go with this way."

Swift says "On tiny and mux you can use ansi %-sub codes such as %xh%xb for highlighted blue, %xh for Highlighted white, etc. On penn, you have to use the [ansi] function."

Swift says "This kind of dips into the idea of building standards, which we'll get to later, but for now, if you want to add an alias to your room that's visible, you would use the @name command"

Swift says "@name Swift's Room=Swift's Room %xh%xb<%xn%xhSR%xn%xh%xb>%xn;Swift's Room;SR"

Swift says "Any questions so far?"

Swift says "I think I've got an actual audience of two, but hey, if you two get anything out of it, it's worth it."

Pin is good so far.

Swift says "Okay. If you're curious about the %x stuff, see help substitutions, and help ansi"

Pin says "I think most are just logging for reference's sake. I was going to make some suggestions regarding placecode, if we get to it."

Swift nods, "Definitely

Shereem eyes that sting of percent symbols.

Swift says "The next command(s) we're going to work with are the success, drop and failure commands. If I teach anyone anything tonight I hope it's this: Always put success messages, drop messages, and fail messages on all your exits.../before/ descing out the room."

Swift says "These commands /always/ confuse new builders so, pay attention:"

Shereem says "My problem is that I don't know how to type all that stuff myself. I mean I can cut and paste it sure but I don't have a clue what all that means.""

Swift says "@succ =You enter room X"

Swift says "I'll explain ansi later Shereem"

Swift says "@osucc =goes into room X"

Swift says "@odrop =comes into room X from room y."

Swift says "@fail =You can't use that exit"

Swift says "@ofail =tries to use exit Alpha, but it's locked."

Swift says "Okay"

Swift says "Success, drop and failure."

Swift says "Each one has three (3) seperate parts. an @succ, an @osucc, and an @asucc."

Swift says "This should make it /really/ simple"

Swift says "If it's @succ, @drop, or @fail, the person performing the action/going through the exit sees that message."

Swift says "If it's @osucc, @odrop, or @ofail, the person or people that are in the room that message is sent to sees that message, not the person performing it."

Swift says "If it's an @asucc, @adrop, or @afail, it's a message or command that is executed when that particular attribute is triggered."

Swift says "Everybody still with me?"

Pin nods.

Swift says "Now, on exits: Nobody uses @drop, and chances are unless you're having things added to or changed on players, you're not going to use @asucc, @adrop, and @afail."

Swift says "So that leaves @succ, @osucc, @odrop, @fail, and @ofail."

Swift types> @succ SR=You enter Swift's Room.

Swift types> @osucc SR=enters Swift's Room and shuts the door.

Swift types> @odrop SR=comes into Swift's Room from the hallway and shuts the door.

Swift types> @fail SR=That door is locked!

Swift types> @ofail SR=tries the door to Swift's Room, but it's locked!

Swift says "Now, if you 'ex SR' you'll note that those attributes are set on the door."

Swift's Room ;Swift's Room;SR(#1521EV) Type: EXIT Flags: VISUAL Owner: Swift Key: *UNLOCKED* Credits: 0 Accessed: Sat Sep 22 21:43:20 2007   Modified: Sat Sep 22 21:43:10 2007 Zone: [ZONE] Plotmaster Zone Object(#1495IV$) Powers: Succ: You enter Swift's Room. Osucc: enters Swift's Room and shuts the door. Odrop: comes into Swift's Room from the hallway and shuts the door. Fail: That door is locked! Ofail: tries the door to Swift's Room, but it's locked! Source: Building Wonderland(#76RJLz) Destination: Swift's Room

Swift says "I know that it doesn't seem important now, but people who RP on your grids will rely on you the builders to give these directions correctly and coherently."

Swift says "Please do feel free to add these attributes to your own exits now."

Swift says "And pausing now for any questions or comments. We've been at this for an hour now, if anyone needs a break, feel free to take one."

Swift says "Okay, continuing on"

Bella has disconnected.

Swift says "On any mush, Exits, rooms, objects, players...they're all things, some type of object. Each object can have all these attributes on it. Just like you would use @desc for your room description, you also use it for exit descriptions, object descriptions, to describe yourself, all of it. So if I wanted to describe my office door, I would do something like this:"

Swift types> @desc SR=This simple wooden door has a discreet plaque in the center of the top half. Simple letters spell out the word 'Swift', embossed in brass and attached to the door by screws.

Swift says "Maybe not sexy, but it gets the job done. You can now 'look sr' and see the door's desc on there"

Swift says "Just like any other description, you can use %R and %T to get a Carriage Return (linebreak) and Tab, respectively."

Swift says "I'm not going to go through the excruciating process of descing out a whole room here, but the commands are all the same. You'll note, however, if you look at the /other/ exit that you created, that it doesn't carry the @desc, @succ, @osucc, @odrop, or @fail/@ofail messages that you set on /this/ exit. Exits on mush are funny things - they're always two seperate, one-way exits, not one exit that lets traffic flow both ways."

Swift says "Another handy command that most builders use is @create. This creates objects (like the plus-help object, or the Building Class Test Object) the way it works is simple, just @create . It should automatically be inside your player object (type i to see what you're carrying, if anything) and you can use it however you wish - a puppet (help puppet) a code object to hold soft-coded commands, or whatever"

Swift says "Alright, that's the rough basics of building, and before I move onto a discussion of style and standards, I'm going to stop and let anyone who has any questions ask them"

Pin is good so far.

Lachesis is here now but for all intents and purposes listening as I'd have a lot to read before being able to ask specific questions.

Swift nods

Swift says "Well, this isn't as 'interactive' as I'd hoped it'd be, but hey, maybe someone will get something out of the logs ;)"

Lachesis smiles "I hope so"

Swift says "Further commands to look into, if you're serious about building: @parent, @chown, @chzone, zones, and there's lots more, but that's a good start for now. I may do a more advanced building class sometime in the future if there are people that are interested in it."

Swift says "Okay, on style and standards"

Swift says "Everyone who starts out building is going to, by necessity, be clumsy at it. It's hard for most people to get out of the idea of rooms, or boxes when building on mush. Though things are rooms, there are times when it may be a closet, or it may be 20 miles of ocean. This is where your descriptive style comes in, as well as the messages you set on the exits, the way you use variable descs...all of this comprises your building style."

Shereem says "Is there a way we can figure out how much cost would be involved with adding on a room to an existing building or anything like that?"

Swift says "If you're talking about on Winter's Edge and the IC cost, yeah, the costs are dependant on the pricing system in the Stronghold Builder's Guidebook."

Shereem nods and listens

Swift says "Style can either make or break your building."

Swift says "for example"

Swift types> ex #1505/desc

Taiga(#1505RVhz)

Desc [#7($DV)]: %r%tThe trees are still light here, near the coast and the more inhabited areas of the fjordland. Snow and ice blanket the sparse terrain, concealing the ground and yet leaving everything bared to the eye. The trees here are slender and tall, branches reaching eagerly for the meager warmth of the sun. No moss or creepers dare to grow here, though some hardy shrubs eke out a living between the trees, and in their bowels, small anmials survive as best they can. A road winds through the trees here, stretch back northeast, towards the Helgegard Pass, and south towards the main road.%r

Swift says "versus another description of the same area (take into consideration that this is a weather/season dependant description)"

Swift says "The trees become sparse here in this odd confluence of many pathways. This area of the Taiga seems to be one of the most well traveled as many footpaths go off in various directions. The main road goes northeast towards Helgegard Pass and south towards the main, western, road. Small shrubs and lichens dot the sides of the various paths here and there. Darkness covers the land, making it difficult for those with normal vision to see the various paths leading off from the main track here. The sounds of small animals in the underbrush is one of the few sounds audible. Snow blankets the ground and rutted tracks, clotting the land with its stark white blankness. Small animals can be seen digging down through the snows to forage, or for cover when the shadow of an occasional bird of prey skates across the ground. Winter is fully entrenched and at times drifts to either side of the main track are almost head high, sometimes covering the various paths and trails that branch off."

Swift says "A cold wind blows from the west, driving charcoal clouds before it and blotting out the stars in isolated patches overhead. The air is clear and elsewhere the stars shine brightly."

Swift says "Now, which is better? Which is worse? I'm not going to say that one is worth a literary prize, but to /you/ which one makes the 'room' feel like less of a 'room' and more of a 'wilderness'?"

Pin says "Detail is always helpful. Those weather descs get a bit generic after a while."

Lachesis likes the second

Swift says "Assuming that no one wants to step forward and give an opinion on it, I'll answer as a player - The first one is succinct, but in the world of description, shorter doesn't always mean sweeter. The first desc has at least two misspellings, poor location style and is just extremely spartan...it doesn't give the players anything to react to, to add into their repretoir of roleplay. The second one may be too long for a lot of people, but there's a lot of useable /meat/ in there that players can use to RP with. Not only that, but it's been /spellchecked/. Yes the second desc is good - if it's going on a live game, it /better/ be good. Just because it's good (or even great as some buildings really are) doesn't mean they have a right to exist on a game when they're not being used, but at least being good, they give the players something to use within their RP, and they are part of a believable setting."

Swift says "When you're building, what you're doing is writing. If you don't or can't write, then chances are you're not going to be a good builder. If you can't spell, buy a dictionary, if you don't know the difference between there, their and they're, you need to learn it before you embarass yourself in a building. I know that sounds like an asshole thing to say, but it's true. Players will see something stupid in a desc, laugh at the people running the game, and then never tell them about it."

Swift says "All of that is style - how you write. That's your bag, and how you develop it is completely and totally up to you."

Pin says "I like your point about 'meat'. That's always a plus, yes. Effort put into building atmosphere really makes a room desc. If it's just an list of features and "what you can see's" it really doesn't help inspire rp."

Swift says "However, the one thing that you, as builders, need to do is learn and understand that regardless of your style, you /need/ to apply a standard to your building - especially if it's going to be part of a game, one that you don't run. Standards are the things that pull an entire grid together."

Swift nods to Pin - "Yeah, and while most people who have built before can tell you: 75-90% of the players out there read the desc once, then ignore it forever unless it changes, but there are people who do pay attention to the descriptions and use them in their RP - and that makes the game richer for everyone.

Pin says "Another thing I'd say about desc style, is worry less about trying to roadmap everything (x lies to the left, such and such is in the northeast, next to the stables etc.) and focus more on trying to communicate the feel of the place. Too much road-mapping makes for clumsiness and length."

Shereem says "I reread them for my poses. Esp in an unfamilar place"

Swift nods, "Indeed. I relie heavily on directions for my rooms - Helgegard pass to the north, the closet to the east, the shadowed door in the southwest corner of the room, but locate it and get away from it to the real description, otherwise it's like reading a blueprint, or stereo instructions.

Swift says "Rely, even"

Lachesis says "You want to desc it such a way as to make them feel like they're really there, and giving them enough detail to work with."

Swift says "Exactly"

Lachesis nods

Swift says "But you also want to take into account the rest of the grid and how everything you've worked on up to that point flows into that room."

Swift says "For example"

Pin says "I think +views are the place to put all the blueprint stuff, really."

Lachesis agrees with Pin

Swift says "Batman isn't batman without all those darkened alleyways and brooding slender spires in the night. If you put a shining squat megamall in there and have Batman walking around inside, in uniform, shopping, then it breaks the feel of the game."

Swift says "That's where building standards come in, with regards to style."

Pin has reconnected.

Swift says "You'll notice that all the exits on WE have a visible alias, and when you hit the new grid, you'll notice that they're coloured differently...that's part of standards, as is saying 'okay, all rooms are going to be parented to the master room parent', but you'll also note that all the buildings in a certain area /mesh/ with the other buildings in that area, either in style of description, or in purpose. That's something that you, as builders, need to be able to apply to your projects. Ask yourself: Where does this belong in the game? and If it doesn't belong in the game, can I fix it to where it does, or do I need to scrap it and start over?"

Swift says "A good building will never pull people to your game, and a bad building may never drive people away from it, but it can really affect the style and level of thought that players put into their RP efforts on a game, and that /is/ important."

Swift says "And that's all I've got right now. Pin, you said you wanted to talk about places code?"

Pin says "Hrm."

Swift says "?"

Pin types

Shereem waits more patiently than Swift and smirks.

Swift says "Sorry, my bronchitis meds are doing funny things to my head and stomach right now, so if I seem a little off or antsy, you guys know why."

Pin says "Well, this may not apply, depending on your building standards, but I was going to say... When you mention place code, people tend to think tables and chairs. They can do a lot more, though. Dunno if anyone's been on it, but I did a fair bit of building on LA MUSH. One of the projects there was to build the Huntington Library and Gardens -- a 400 or so acre site, with about 8 rooms. Place code made that possible. So, I'd recommend them for castles and suchlike, where you want to describe lots of rooms, but don't care to build a labyrinth of connected @dug rooms."

Pin says "For instance, you could have one room for your courtyard, with various configured places representing stables, servant's lodging, barracks, the main drawbridge etc. Just an idea. Keeps projects from getting ungainly, whilst providing an idea of layout and structure."

Swift nods, "Indeed, Pin is right. One question he asked me about earlier is Quota. on WE it's not that big of a deal because nobody builds but me, but on games where you can build (like M*U*S*H or Mpug) quota is your limit of how many object (besides your player bit) you can 'own'. Places can really expand the look and feel of a room into an entire structure without busting your quota. You'll notice that the Park uses that ideal, though more subtly on the live game. The park is /huge/ It covers the most area of any one 'physical' structure in the city, but it's all in one room."

Swift says "Now, to go back to ansi...something that throws Shereem for a loop every time she sees it."

Swift says "You'll notice if you type 'help ansi' that it talks about codes and strings. Ansi is simply a basic code for standard 8-bit colour (red, yellow, blue, black, green, magenta, cyan, and white, both normal and highlighted) There are different 'codes' that allow you to do different colours. Again, these are basic colours, not shades or anything like that."

Swift says "So, you can either get ansi red by typing: [ansi(r,Test)] ---> Test"

Swift says "Or you can use the % substitutions by typing: %xrTest ---> Test"

Swift says "%x tells the mush 'We're going to do ansi now, the next letter is the ansi code'."

Swift says "So, if you want to build a test to see the differences, you could do something like this:"

Pin has partially disconnected.

Swift says "%xhHighlight%xn, %xuUnderline, %xxBlack, %xr Red, %xg Green, %xyYellow, %xbBlue, %xmMagenta, %xcCyan, %xwWhite"

Swift says "Note that %xn causes it to revert to normal"

Swift says "So you get: Highlight, Underline, Black, Red,  Green, Yellow, Blue, Magenta, Cyan, White"

Swift says "And note, the underline carries through as well, seeing as how I forgot to %xn it"

Swift says "To get 'brighter' colours, you add highlight to each one thusly:"

Swift says "So you get: %xh%xxBlack,%xh%xr Red, %xh%xg Green, %xh%xyYellow, %xh%xbBlue, %xh%xmMagenta, %xh%xcCyan, %xh%xwWhite"

Swift says "So you get: Black, Red, Green, Yellow, Blue, Magenta, Cyan, White"

Swift says "And yes, you can highlight Black....really odd, but it's true."

Swift says "And yes, the BG codes work as well, so you can do %xR%xgGreen on Red%xn ---> Green on Red"

Swift says "Which, if you ask me, is truly fucking horrendous."

Swift says "Does that make a little more sense now Shereem?"

Pin thinks this is worse

Swift says "Yellow on Cyan?"

Pin says "Aye."

Swift says "Not too bad, actually. I have my colours on my terminal adjusted specifically for me though, because I'm colourblind."

Pin says "Ah."

Pin says "That was highlighted, too."

Swift says "My 'red' is more orange because I can't see red text on black background."

Pin says "I think the main rule with ansi is: less is more."

Lachesis agrees

Swift nods, "Yes. You can use as much ansi as you want, but if you use too much, chances of people hanging out in your building is really slim. I like ansi for a lot of the menus and stuff like +who info. Buildings? Not so much.

Shereem says "my screen looks gay.""

Lachesis finds it annoying when people use it in their com titles

Lachesis says "especially the flashing ones"

Swift says "The one exception that I make to that is Ansi'ing a name. I don't have a problem with that as long as it's not using like the rainbow function"

Pin says "Yeah."

Swift says "because Whitehart Inn - The common Room Just looks fucking stupid."

Pin chuckles.

Swift says "It looks like a clown exploded on the room title."

Shereem says "I don't mind it if it's not to bright or highlighted. It tends to help me seperate the lines of text."

Lachesis says "To each their own I guess :)"

Swift nods, "Again, exit aliases, stuff like that? No problem. But don't intersperse a bunch of ansi words in your building rooms."

Shereem says "But yeah that does look like it was done by a 4 year old. I should know I teach them art."

Swift says "I particularly find the use of colourizing channel names and pages makes it easier for me to see important info at a glance, but that's something you can do with your client - not something you should force onto people on the game."

Shereem says "How do you do that? Like make certain things pop up as a certain color?"

Shereem says "say pages or channels"

Swift says "Anyways, Shereem, if you want to play with ansi to understand it more, you can always use the 'think' command to play with it 'think %xh%xrRed'"

Swift says "That depends on your client"

Shereem says "That's cool"

Pin says "Though on the subject of roomname ansi -- I was thinking it might be a good convention to have Vintermor city outdoor rooms set as one colour, and Wilds outdoor set as another. Might provide a sense of unity for each area."

Swift nods, "That's a good idea Pin, if you'll sub it into the building queue on the live game, i'll see about incorporating it into the new/rebuilt grid. Also some colour suggestions would be good - I suck at picking out colours

Pin gets on it.

Lachesis says "Do you mean like having the name of the room a different colour? or the exits? or both?"

Swift says "As a wrap to the building portion of this: If you're going to build, don't be afraid to try things out, and /learn/ to read help files. Most games try to write their +help files in the same manner as 'help' files are written, but not always. And if you ever have any questions, ask your local build wiz - most of us are happy to explain how something works."

Swift says "Could do both I suppose."

Pin says "Lachesis -- just the room name."

Lachesis nods "I wondered because for the wilderness areas the muted green as the room name would work"

Pin says "Yep."

Pin says "I suggested that, with cyan for the city. Could go highlighted black for it too, perhaps."

Lachesis says "the muted one?"

Pin says "Well, I just said green in the qmail."

Swift says "The one thing you have to be careful about on ansi though, not everyone uses white text on black or black text on white. If someone uses a green bg it can bite you."

Pin says "True enough."

Pin says "But provided it's nothing too silly, most clients allow individual users to adjust."

Swift nods

Lachesis nods "the highlighted black would be neat for the city with the muted green for the wilderness. Just go on the basis that the majority of individuals use the black background."

Swift says "Alrighty. If that's it on the questions, I'm going to go ahead and work on cleaning the log up and putting it up on the wiki"

Shereem says "I use a dark blue. It's easier on my eyes."

Shereem says "ok"

Pin nods to Lachesis. I'd go with that, too.

Shereem says "Thanks Swift.""

Lachesis says "Well thanks Swift sorry I wasn't here on time""

Pin says "Thanks, Swift."

Swift shrugs, "S'okay, you'd told me you wouldn't be ;)"

Pin says "An advanced class would be interesting -- I'm not so clued up on zoning."

Swift says "If I do it again though, we'll work with parents and zones - that's where things get really interesting, and more code-like."

Pin says "Cool."

Swift nods, "Zoning is easy...you just have to get your brain around the concept of it first ;)

\*** TinyMUSH Disconnected ***