From grimslayde at sbcglobal.net Sun Feb 2 07:35:11 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Sun Feb 2 06:35:16 2003 Subject: [Coldstuff] Re: Well, something just clicked... References: Message-ID: <000a01c2cabf$e9e10e00$4743fea9@dc> Yes, you DO deal with it. I'm a moderator on a Flash forum where I've posted well over 1,000 replies for people where ingratitude is my usual reward. I'll tell you the same thing I tell those impatient people: this is my hobby and not a job. I really enjoy helping people when and if I can, but you gotta be patient - especially on weekends. And gawd forbid, yes, I might answer other questions before yours and it's nothing personal. Oy. Now. Your problem. The CML generators require you to use hard brackets. Your generator goes first followed by a colon and then the arguments. The example I gave you came /directly/ from one of my most-frequented rooms, so it does work. About the only thing I can assume is that you aren't running on a Linux-based system. The time generator uses the native OS's time function, so your arguments might be different than mine. I run on RedHat, so the %R will return the hour:minute in 12-hr format. I'm not sure why you would get an error thrown, though. In all my experiments with the time generator I didn't get errors thrown. I got an error in the midst of the description... something like >>ERROR: Unknown generator<< or the like. Been a while since then, so I don't recall. Maybe Brandon-san can be more of assistance there. I would suggest you check your OS's documentation on their time function, the answer probably lies there. ----- Original Message ----- From: "Gary Whitten" To: "Grimslayde" Sent: Saturday, February 01, 2003 8:59 PM Subject: RE: Well, something just clicked... > Ok, you're chaotic and I have half answers. I guess I deal with that and > get the rest of them somewhere else. I cannot, however, learn from someone > else if the line [time:%R] %R is something you wrote yourself or it came > from somewhere else. Can you at least answer that question for me? > > -----Original Message----- > From: Grimslayde [mailto:grimslayde@sbcglobal.net] > Sent: Saturday, February 01, 2003 9:46 PM > To: Gary Whitten > Subject: Re: Well, something just clicked... > > > Wuzzat, a guilt trip? C'mon, ye can do better than that.*winks* I'm just > chaotic, man. Especially when I'm busy. I flight from here to there like a > spastic sparrow. > > Not sure what the problem was on your CML. Try pasting what you tried in on > an email, I'll be happy to peer it over. > > I've been looking into starting a forum for ColdCore on my server. Searching > through the email archives for answers is cumbersome! > > Anyway, more to come later. Drop a line if yer on it, or drop by my core > sometime. We can chat up on code or whatgnot. > > PEACE > - Grim > > > ----- Original Message ----- > From: "Gary Whitten" > To: "Grimslayde" > Sent: Saturday, February 01, 2003 1:43 AM > Subject: RE: Well, something just clicked... > > > > Ok, well, given that you've answered a few other messages and not mine I'm > > guessing that I'm not going to get an elaboration on the stuff that still > > confused me. Thanks for the help you provided, I appreciate it. > > > > -----Original Message----- > > From: Grimslayde [mailto:grimslayde@sbcglobal.net] > > Sent: Friday, January 31, 2003 12:09 PM > > To: Gary Whitten > > Subject: Re: Well, something just clicked... > > > > > > Yeah, you just use the hard brackets. Just like in the example I gave... > no > > ctext_frob stuffage, that's what the .prose() code does after it parses > > everything. Check out the help docs on CML. It's cryptic, but it's all > > there... supposedly. > > > > ----- Original Message ----- > > From: "Gary Whitten" > > To: "Grimslayde" > > Sent: Friday, January 31, 2003 10:46 AM > > Subject: Well, something just clicked... > > > > > > > Went to go put in a time statement into my office to play with it and > what > > > do I see.. > > > > > > Described variables: > > > prose: <$ctext_frob, > > > > > > So I guess that what you showed just goes into the normal description > > area. > > > > > > From gary at undiscoveredworlds.com Mon Feb 3 08:54:37 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Mon Feb 3 06:53:35 2003 Subject: [Coldstuff] Apologies In-Reply-To: <000a01c2cabf$e9e10e00$4743fea9@dc> Message-ID: I want to take a moment to apologize to anyone I've annoyed or offended as well as those I haven't yet gotten around to if I've seemed pushy or ungrateful. I wasn't supposed to be the coder in this project I'm doing but I am now and I'm a bit out of my element and while there are help nodes, I learn better by examples, not just dry explanations of syntax and purpose. I do appreciate any and all help I get from people, and I think I've proven on tCD in the last week or so that I'm willing to give help in return where needed so again, sorry if I've ruffled feathers, I'll try to keep myself well-behaved in the future. Gary From gary at undiscoveredworlds.com Tue Feb 4 23:50:42 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Tue Feb 4 21:49:40 2003 Subject: [Coldstuff] Resolving parser ambiguities In-Reply-To: Message-ID: I was wondering if people had changed the command resolution stuff to not void a command because the object it was referring to could be one of several things. I THINK I'd prefer it'd pick one instead of just getting 'be more specific'. Also, is this normal behavior for most MUx/MOO code bases? I ran a game for years but after being behind the scenes it just wasn't the same to play much so I really don't know how some of the other code bases work in some areas. TIA Gary From roys at mindspring.com Wed Feb 5 00:12:12 2003 From: roys at mindspring.com (Roy Sutton) Date: Tue Feb 4 22:14:13 2003 Subject: [Coldstuff] Resolving parser ambiguities In-Reply-To: References: Message-ID: <5.1.0.14.2.20030205000935.038b8338@mail.mindspring.com> You've put your finger on one of the most aggravating pieces of ColdCore. It's one of the reasons I wrote my own. Yes, it'd be easy enough to do that. Check in the code where the ambiguous match is returned and instead select the first object from the list (pretty sure that's easy enough to do). Alternatively or additionally you'll want to be able to tweak the search order, which is a much bigger problem and something I really can't help you with since I've abandoned the ColdCore. Roy At 11:50 PM 2/4/2003, you wrote: >I was wondering if people had changed the command resolution stuff to not >void a command because the object it was referring to could be one of >several things. I THINK I'd prefer it'd pick one instead of just getting >'be more specific'. > >Also, is this normal behavior for most MUx/MOO code bases? I ran a game for >years but after being behind the scenes it just wasn't the same to play much >so I really don't know how some of the other code bases work in some areas. > >TIA > >Gary > >_______________________________________________ >Cold-Coldstuff mailing list >Cold-Coldstuff@cold.org >http://web.cold.org/mailman/listinfo/cold-coldstuff From gary at undiscoveredworlds.com Wed Feb 5 00:20:28 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Tue Feb 4 22:19:25 2003 Subject: [Coldstuff] Resolving parser ambiguities In-Reply-To: <5.1.0.14.2.20030205000935.038b8338@mail.mindspring.com> Message-ID: Thanks. I really wasn't looking for assistance in modifying it as much as I was looking for the 'norm' and what people did with it. My gut instinct is to do what you said 'Have it pick SOMETHING' as the first try then after I get better and/or have more time, try to put in some sort of system to help make educated guesses. aka, if you smile, pick a person over an object or if you're chopping, pick the object. Using the parser (with the @ac command) to help do things like may be a good approach for me to try too. -----Original Message----- From: cold-coldstuff-bounces@cold.org [mailto:cold-coldstuff-bounces@cold.org]On Behalf Of Roy Sutton Sent: Wednesday, February 05, 2003 12:12 AM To: coldstuff@cold.org Subject: Re: [Coldstuff] Resolving parser ambiguities You've put your finger on one of the most aggravating pieces of ColdCore. It's one of the reasons I wrote my own. Yes, it'd be easy enough to do that. Check in the code where the ambiguous match is returned and instead select the first object from the list (pretty sure that's easy enough to do). Alternatively or additionally you'll want to be able to tweak the search order, which is a much bigger problem and something I really can't help you with since I've abandoned the ColdCore. Roy At 11:50 PM 2/4/2003, you wrote: >I was wondering if people had changed the command resolution stuff to not >void a command because the object it was referring to could be one of >several things. I THINK I'd prefer it'd pick one instead of just getting >'be more specific'. > >Also, is this normal behavior for most MUx/MOO code bases? I ran a game for >years but after being behind the scenes it just wasn't the same to play much >so I really don't know how some of the other code bases work in some areas. > >TIA > >Gary > >_______________________________________________ >Cold-Coldstuff mailing list >Cold-Coldstuff@cold.org >http://web.cold.org/mailman/listinfo/cold-coldstuff _______________________________________________ Cold-Coldstuff mailing list Cold-Coldstuff@cold.org http://web.cold.org/mailman/listinfo/cold-coldstuff From grimslayde at sbcglobal.net Wed Feb 5 07:32:15 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Wed Feb 5 06:32:44 2003 Subject: [Coldstuff] Resolving parser ambiguities References: Message-ID: <000801c2cd1b$0de94e40$4743fea9@dc> Looks like this really IS a commonality for folks who use the core. I suffered the same issue not long ago, many of my players (all two of them) complained about the ambiguous match issue. Rather than default it to the first match for everything, I tweaked the $foundation.match_environment method to return the list of matches in the throw statement like this: ... } else if (error() == ~ambig) { lst_found = traceback()[1][3]; str_line = "\"" + str_what + "\" can match " + traceback()[1][3].mmap('namef, 'ref).to_english("", " or ") + "."; throw(~ambig, str_line, lst_found); ... So it still did basically the same thing, but I could CATCH the ~ambig error and use traceback()[1][3] to get the list of what the matching found. That way I could have different methods handle the ~ambig error as needed (usually taking first). If you need more I can paste up my entire $foundation.match_environment method. Just didn't wanna spam folks. Oh, and sorry about earlier. Went all Dennis Leary on ya, Gary. Caught me on the tail end of a week that gnawed my sanity to a frazzle. So yeah, I'll endeavor not to be such a jerk to ye all in the future. *grin* Peace! - Grim Leary ----- Original Message ----- From: "Gary Whitten" To: Sent: Tuesday, February 04, 2003 11:20 PM Subject: RE: [Coldstuff] Resolving parser ambiguities > Thanks. I really wasn't looking for assistance in modifying it as much as I > was looking for the 'norm' and what people did with it. > > My gut instinct is to do what you said 'Have it pick SOMETHING' as the first > try then after I get better and/or have more time, try to put in some sort > of system to help make educated guesses. aka, if you smile, pick a person > over an object or if you're chopping, pick the object. > > Using the parser (with the @ac command) to help do things like of $place> may be a good approach for me to try too. > > -----Original Message----- > From: cold-coldstuff-bounces@cold.org > [mailto:cold-coldstuff-bounces@cold.org]On Behalf Of Roy Sutton > Sent: Wednesday, February 05, 2003 12:12 AM > To: coldstuff@cold.org > Subject: Re: [Coldstuff] Resolving parser ambiguities > > > You've put your finger on one of the most aggravating pieces of > ColdCore. It's one of the reasons I wrote my own. Yes, it'd be easy > enough to do that. Check in the code where the ambiguous match is returned > and instead select the first object from the list (pretty sure that's easy > enough to do). Alternatively or additionally you'll want to be able to > tweak the search order, which is a much bigger problem and something I > really can't help you with since I've abandoned the ColdCore. > > Roy > > At 11:50 PM 2/4/2003, you wrote: > >I was wondering if people had changed the command resolution stuff to not > >void a command because the object it was referring to could be one of > >several things. I THINK I'd prefer it'd pick one instead of just getting > >'be more specific'. > > > >Also, is this normal behavior for most MUx/MOO code bases? I ran a game > for > >years but after being behind the scenes it just wasn't the same to play > much > >so I really don't know how some of the other code bases work in some areas. > > > >TIA > > > >Gary > > > >_______________________________________________ > >Cold-Coldstuff mailing list > >Cold-Coldstuff@cold.org > >http://web.cold.org/mailman/listinfo/cold-coldstuff > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From xidus at xidus.net Wed Feb 5 08:13:02 2003 From: xidus at xidus.net (Jeremy Weatherford) Date: Wed Feb 5 09:13:07 2003 Subject: [Coldstuff] Resolving parser ambiguities In-Reply-To: Message-ID: IMHO, the best way to handle this is to complain if there's some way of discriminating between the objects (a blue box and a red box, 'get box' should say "I don't know which one you mean, there's a red box and a blue box here."). If there's no way to discriminate, though (names are identical), then there obviously needs to be -some- way of addressing one of them. I'd say pick the first one listed unless the user types something like 'get second box'. I'll have to go back and look at how my parser works. But yeah, this is a fun area to get into. Fun in the sense that it'll keep you lying awake at night... Jeremy Weatherford xidus@xidus.net http://xidus.net On Tue, 4 Feb 2003, Gary Whitten wrote: > I was wondering if people had changed the command resolution stuff to not > void a command because the object it was referring to could be one of > several things. I THINK I'd prefer it'd pick one instead of just getting > 'be more specific'. > > Also, is this normal behavior for most MUx/MOO code bases? I ran a game for > years but after being behind the scenes it just wasn't the same to play much > so I really don't know how some of the other code bases work in some areas. > > TIA > > Gary > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > From acormany at yahoo.com Wed Feb 5 08:21:50 2003 From: acormany at yahoo.com (Adam Cormany) Date: Wed Feb 5 09:21:58 2003 Subject: [Coldstuff] Resolving parser ambiguities In-Reply-To: Message-ID: <20030205162150.14208.qmail@web12805.mail.yahoo.com> As far as this example with 2 different colored boxes, this is what I did for what it's worth. I set my commands up to accept 1) get box 2) get 2.box 3) get all.box 4) get all. As far as a social(smile, nod, etc) goes determining whether it does its action to an object, a victim in the room, or to self, I have a $social_parser to do all that. It has worked quite nicely for me. Are people really having that much problems with the ambig commands? I haven't run into that problem much, but again I redid a lot of the command names, created my own, and removed a lot of the old ones. Adam --- Jeremy Weatherford wrote: > IMHO, the best way to handle this is to complain if > there's some way of > discriminating between the objects (a blue box and a > red box, 'get box' > should say "I don't know which one you mean, there's > a red box and a blue > box here."). If there's no way to discriminate, > though (names are > identical), then there obviously needs to be -some- > way of addressing one > of them. I'd say pick the first one listed unless > the user types > something like 'get second box'. I'll have to go > back and look at how my > parser works. But yeah, this is a fun area to get > into. Fun in the sense > that it'll keep you lying awake at night... > > Jeremy Weatherford > xidus@xidus.net > http://xidus.net > > > On Tue, 4 Feb 2003, Gary Whitten wrote: > > > I was wondering if people had changed the command > resolution stuff to not > > void a command because the object it was referring > to could be one of > > several things. I THINK I'd prefer it'd pick one > instead of just getting > > 'be more specific'. > > > > Also, is this normal behavior for most MUx/MOO > code bases? I ran a game for > > years but after being behind the scenes it just > wasn't the same to play much > > so I really don't know how some of the other code > bases work in some areas. > > > > TIA > > > > Gary > > > > _______________________________________________ > > Cold-Coldstuff mailing list > > Cold-Coldstuff@cold.org > > > http://web.cold.org/mailman/listinfo/cold-coldstuff > > > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From grimslayde at sbcglobal.net Wed Feb 5 10:28:32 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Wed Feb 5 09:28:42 2003 Subject: [Coldstuff] Resolving parser ambiguities References: Message-ID: <000801c2cd33$a124e0d0$f30c060a@npd.com> The way it's set up now isn't so terrible, I personally got used to it. In contrast, just about every DIKU-style MUD coded goes by the "first match" rule and players just had to live with it. I don't see any major problem with doing it that way. Heck, that's how the majority of my methods handle the ~ambig error anyway. I still want the error thrown, though, and caught/handled in the method it was called from, thus the tweak of error throwing in my $foundation.match_environment to toss back the list of offending objects. That way on an ~ambig error I could have one method complain for specifics while another could just default on the first, while yet another that only matches for $body objects filters down and chooses the first, etc... Just my take on it. ----- Original Message ----- From: "Jeremy Weatherford" To: Sent: Wednesday, February 05, 2003 10:13 AM Subject: Re: [Coldstuff] Resolving parser ambiguities > IMHO, the best way to handle this is to complain if there's some way of > discriminating between the objects (a blue box and a red box, 'get box' > should say "I don't know which one you mean, there's a red box and a blue > box here."). If there's no way to discriminate, though (names are > identical), then there obviously needs to be -some- way of addressing one > of them. I'd say pick the first one listed unless the user types > something like 'get second box'. I'll have to go back and look at how my > parser works. But yeah, this is a fun area to get into. Fun in the sense > that it'll keep you lying awake at night... > > Jeremy Weatherford > xidus@xidus.net > http://xidus.net > > > On Tue, 4 Feb 2003, Gary Whitten wrote: > > > I was wondering if people had changed the command resolution stuff to not > > void a command because the object it was referring to could be one of > > several things. I THINK I'd prefer it'd pick one instead of just getting > > 'be more specific'. > > > > Also, is this normal behavior for most MUx/MOO code bases? I ran a game for > > years but after being behind the scenes it just wasn't the same to play much > > so I really don't know how some of the other code bases work in some areas. > > > > TIA > > > > Gary > > > > _______________________________________________ > > Cold-Coldstuff mailing list > > Cold-Coldstuff@cold.org > > http://web.cold.org/mailman/listinfo/cold-coldstuff > > > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From patm at pureconnection.net Wed Feb 5 11:27:35 2003 From: patm at pureconnection.net (Pat Moroney) Date: Wed Feb 5 09:54:35 2003 Subject: [Coldstuff] Resolving parser ambiguities Message-ID: <465E88A5809A9E4F9D6313331087BC4034A066@les1.lstrat.com> >From what I remember Kipp had something like this working on ColdParadigm. Pick up first box pick up all boxes ect.. but that was not even based off of coldcore. I believe he built it up from minimalcore, could be wrong though. -Pat Moroney -----Original Message----- From: Adam Cormany [mailto:acormany@yahoo.com] Sent: Wednesday, February 05, 2003 11:22 AM To: coldstuff@cold.org Subject: Re: [Coldstuff] Resolving parser ambiguities As far as this example with 2 different colored boxes, this is what I did for what it's worth. I set my commands up to accept 1) get box 2) get 2.box 3) get all.box 4) get all. As far as a social(smile, nod, etc) goes determining whether it does its action to an object, a victim in the room, or to self, I have a $social_parser to do all that. It has worked quite nicely for me. Are people really having that much problems with the ambig commands? I haven't run into that problem much, but again I redid a lot of the command names, created my own, and removed a lot of the old ones. Adam --- Jeremy Weatherford wrote: > IMHO, the best way to handle this is to complain if > there's some way of > discriminating between the objects (a blue box and a > red box, 'get box' > should say "I don't know which one you mean, there's > a red box and a blue > box here."). If there's no way to discriminate, > though (names are > identical), then there obviously needs to be -some- > way of addressing one > of them. I'd say pick the first one listed unless > the user types > something like 'get second box'. I'll have to go > back and look at how my > parser works. But yeah, this is a fun area to get > into. Fun in the sense > that it'll keep you lying awake at night... > > Jeremy Weatherford > xidus@xidus.net > http://xidus.net > > > On Tue, 4 Feb 2003, Gary Whitten wrote: > > > I was wondering if people had changed the command > resolution stuff to not > > void a command because the object it was referring > to could be one of > > several things. I THINK I'd prefer it'd pick one > instead of just getting > > 'be more specific'. > > > > Also, is this normal behavior for most MUx/MOO > code bases? I ran a game for > > years but after being behind the scenes it just > wasn't the same to play much > > so I really don't know how some of the other code > bases work in some areas. > > > > TIA > > > > Gary > > > > _______________________________________________ > > Cold-Coldstuff mailing list > > Cold-Coldstuff@cold.org > > > http://web.cold.org/mailman/listinfo/cold-coldstuff > > > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Cold-Coldstuff mailing list Cold-Coldstuff@cold.org http://web.cold.org/mailman/listinfo/cold-coldstuff From grimslayde at sbcglobal.net Wed Feb 5 11:04:16 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Wed Feb 5 10:04:23 2003 Subject: [Coldstuff] Resolving parser ambiguities References: <465E88A5809A9E4F9D6313331087BC4034A066@les1.lstrat.com> Message-ID: <001101c2cd38$9e7a6800$f30c060a@npd.com> Yeah, the ordinal reference is already in ColdCore. Can't say the same for the "all" option, but it wouldn't be difficult to code it. Come to think of it, that's just an eventuality for something I'd HAVE to code. Players will inevitably whine about having to do a get for every little item. So, that's another thing for my task list. *glances as his phonebook-thick tasklist breaks his desk* Thanks, Pat... reaaaaaally. *grins* ----- Original Message ----- From: "Pat Moroney" To: Sent: Wednesday, February 05, 2003 10:27 AM Subject: RE: [Coldstuff] Resolving parser ambiguities > >From what I remember Kipp had something like this working on ColdParadigm. > Pick up first box > pick up all boxes > ect.. > but that was not even based off of coldcore. I believe he built it up from > minimalcore, could be wrong though. > > -Pat Moroney > > -----Original Message----- > From: Adam Cormany [mailto:acormany@yahoo.com] > Sent: Wednesday, February 05, 2003 11:22 AM > To: coldstuff@cold.org > Subject: Re: [Coldstuff] Resolving parser ambiguities > > > As far as this example with 2 different colored boxes, > this is what I did for what it's worth. I set my > commands up to accept 1) get box 2) get 2.box 3) get > all.box 4) get all. > > As far as a social(smile, nod, etc) goes determining > whether it does its action to an object, a victim in > the room, or to self, I have a $social_parser to do > all that. It has worked quite nicely for me. > > Are people really having that much problems with the > ambig commands? I haven't run into that problem much, > but again I redid a lot of the command names, created > my own, and removed a lot of the old ones. > > Adam > --- Jeremy Weatherford wrote: > > IMHO, the best way to handle this is to complain if > > there's some way of > > discriminating between the objects (a blue box and a > > red box, 'get box' > > should say "I don't know which one you mean, there's > > a red box and a blue > > box here."). If there's no way to discriminate, > > though (names are > > identical), then there obviously needs to be -some- > > way of addressing one > > of them. I'd say pick the first one listed unless > > the user types > > something like 'get second box'. I'll have to go > > back and look at how my > > parser works. But yeah, this is a fun area to get > > into. Fun in the sense > > that it'll keep you lying awake at night... > > > > Jeremy Weatherford > > xidus@xidus.net > > http://xidus.net > > > > > > On Tue, 4 Feb 2003, Gary Whitten wrote: > > > > > I was wondering if people had changed the command > > resolution stuff to not > > > void a command because the object it was referring > > to could be one of > > > several things. I THINK I'd prefer it'd pick one > > instead of just getting > > > 'be more specific'. > > > > > > Also, is this normal behavior for most MUx/MOO > > code bases? I ran a game for > > > years but after being behind the scenes it just > > wasn't the same to play much > > > so I really don't know how some of the other code > > bases work in some areas. > > > > > > TIA > > > > > > Gary > > > > > > _______________________________________________ > > > Cold-Coldstuff mailing list > > > Cold-Coldstuff@cold.org > > > > > http://web.cold.org/mailman/listinfo/cold-coldstuff > > > > > > > _______________________________________________ > > Cold-Coldstuff mailing list > > Cold-Coldstuff@cold.org > > http://web.cold.org/mailman/listinfo/cold-coldstuff > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From brandon at roguetrader.com Wed Feb 5 10:15:00 2003 From: brandon at roguetrader.com (Brandon Gillespie) Date: Wed Feb 5 10:14:43 2003 Subject: [Coldstuff] Resolving parser ambiguities In-Reply-To: <001101c2cd38$9e7a6800$f30c060a@npd.com> References: <465E88A5809A9E4F9D6313331087BC4034A066@les1.lstrat.com> <001101c2cd38$9e7a6800$f30c060a@npd.com> Message-ID: <3E414694.7080200@roguetrader.com> Grimslayde wrote: > Yeah, the ordinal reference is already in ColdCore. Can't say the same for > the "all" option, but it wouldn't be difficult to code it. Come to think of > it, that's just an eventuality for something I'd HAVE to code. Players will > inevitably whine about having to do a get for every little item. So, that's > another thing for my task list. ~ambig includes a list of possible matches as part of the error arguments (traceback()[1][3]). It looks like this may have become broken over time, requiring a simple fix in $foundation.match_environment (line 69): throw(~ambig, "\"" + str + "\" can match " + found + "."); throw(~ambig, "\"" + str + "\" can match " + found + ".", traceback()[1][3]); So all you have to do is in the code that calls .match_environment, catch ~ambig and to pick the "first" match just pull traceback()[1][3][1]. -Brandon From brandon at roguetrader.com Wed Feb 5 10:21:29 2003 From: brandon at roguetrader.com (Brandon Gillespie) Date: Wed Feb 5 10:21:12 2003 Subject: [Coldstuff] Resolving parser ambiguities In-Reply-To: <3E414694.7080200@roguetrader.com> References: <465E88A5809A9E4F9D6313331087BC4034A066@les1.lstrat.com> <001101c2cd38$9e7a6800$f30c060a@npd.com> <3E414694.7080200@roguetrader.com> Message-ID: <3E414819.7020009@roguetrader.com> Brandon Gillespie wrote: > throw(~ambig, "\"" + str + "\" can match " + found + ".", > traceback()[1][3]); Actually, it is a little more complex than this, just look at the last few lines of the updated method at: http://ice.cold.org:1180/bin/method?target=$foundation.match_environment() -Brandon From grimslayde at sbcglobal.net Wed Feb 5 11:29:58 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Wed Feb 5 10:30:11 2003 Subject: [Coldstuff] Resolving parser ambiguities References: <465E88A5809A9E4F9D6313331087BC4034A066@les1.lstrat.com><001101c2cd38$9e7a6800$f30c060a@npd.com> <3E414694.7080200@roguetrader.com> Message-ID: <001a01c2cd3c$35ad0ae0$f30c060a@npd.com> Heh! Yup, I traced it all back to there and figured that was what ye first intended. Didn't know if you all took it out for some reason, so I didn't sound the Brokie Code Alarm. There's a couple spots in the $foundation.match_environment where you'll have to add that fix. I can't tell you what the original lines were anymore since mine is very different... but peer at the method for mentions of throw(~ambig... and you'll see 'em. Doing that little trick a while back taught me you can toss more arguments in the throw. Handy stuff! ----- Original Message ----- From: "Brandon Gillespie" To: Sent: Wednesday, February 05, 2003 11:15 AM Subject: Re: [Coldstuff] Resolving parser ambiguities > Grimslayde wrote: > > Yeah, the ordinal reference is already in ColdCore. Can't say the same for > > the "all" option, but it wouldn't be difficult to code it. Come to think of > > it, that's just an eventuality for something I'd HAVE to code. Players will > > inevitably whine about having to do a get for every little item. So, that's > > another thing for my task list. > > ~ambig includes a list of possible matches as part of the error > arguments (traceback()[1][3]). It looks like this may have become > broken over time, requiring a simple fix in > $foundation.match_environment (line 69): > > throw(~ambig, "\"" + str + "\" can match " + found + "."); > > throw(~ambig, "\"" + str + "\" can match " + found + ".", > traceback()[1][3]); > > So all you have to do is in the code that calls .match_environment, > catch ~ambig and to pick the "first" match just pull traceback()[1][3][1]. > > -Brandon > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From gary at undiscoveredworlds.com Wed Feb 5 16:04:48 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Wed Feb 5 14:03:48 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: <001a01c2cd3c$35ad0ae0$f30c060a@npd.com> Message-ID: Ok, cool discussion on the first question about this I asked. I've implemented the change and it's pretty neat. Let me ask a follow-up question related to this. In my 'office' on my sandbox server I have a 'simple door' and a 'secure door' as exits. Now, I can just type 'go secure' or 'go simple' and go through the appropriate door. If I choose to type 'go simple door' however, I go through the door both ways (there are reciprocal exits in the destination rooms for each door). Is this intended and more importantly, is this 'normal behavior' in the majority of game engines out there? It seems a bit bizarre to me but if the majority of people are used to this, I'll leave it be and get used to it but just was curious. Gary From grimslayde at sbcglobal.net Wed Feb 5 15:09:39 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Wed Feb 5 14:09:50 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 References: Message-ID: <003e01c2cd5a$e6490110$f30c060a@npd.com> The go command is for following a series of paths... say I want to go from my bedroom to the kitchen I'd type this: go hall den kitchen And the go command takes each respective exit. So when you type go secure door it first takes the 'secure' exit then the 'door' exit in the next room... which takes you right back where you started! You don't have to type go to move around, just the exit name... but ye prolly knew that already. ----- Original Message ----- From: "Gary Whitten" To: Sent: Wednesday, February 05, 2003 3:04 PM Subject: [Coldstuff] Resolving parser ambiguities pt 2 > Ok, cool discussion on the first question about this I asked. I've > implemented the change and it's pretty neat. > > Let me ask a follow-up question related to this. > > In my 'office' on my sandbox server I have a 'simple door' and a 'secure > door' as exits. Now, I can just type 'go secure' or 'go simple' and go > through the appropriate door. > > If I choose to type 'go simple door' however, I go through the door both > ways (there are reciprocal exits in the destination rooms for each door). > Is this intended and more importantly, is this 'normal behavior' in the > majority of game engines out there? It seems a bit bizarre to me but if the > majority of people are used to this, I'll leave it be and get used to it but > just was curious. > > Gary > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From gary at undiscoveredworlds.com Wed Feb 5 16:21:40 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Wed Feb 5 14:20:40 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: <003e01c2cd5a$e6490110$f30c060a@npd.com> Message-ID: Grimslayde typed: >The go command is for following a series of paths... >say I want to go from my bedroom to the kitchen I'd >type this: >go hall den kitchen >And the go command takes each respective exit. So >when you type go secure door it first takes the >'secure' exit then the 'door' exit in the next >room... which takes you right back where you started! I'd pretty much extrapolated that and should have said that specifically, I just wasn't sure if this was intended (it seems it is) and if it is the 'norm' for other platforms. Grimslayde typed: >You don't have to type go to move around, just the >exit name... but ye prolly knew that already. Nope, never knew that. So just typing 'secure door' will move me the one room I see. ---- So given this, let me re-ask the question as: a) Is the command GO used similarly in other game platforms, ie to let you proceed through a series of rooms or does it usually go for just one room? b) How many other platforms have the use of a 'GO' type command be optional? From brandon at roguetrader.com Wed Feb 5 14:35:42 2003 From: brandon at roguetrader.com (Brandon Gillespie) Date: Wed Feb 5 14:35:22 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: References: Message-ID: <3E4183AE.1030305@roguetrader.com> Gary Whitten wrote: > If I choose to type 'go simple door' however, go will take stacked directions, so you can do: go n n n e se up To walk through six different rooms. -Brandon From grimslayde at sbcglobal.net Wed Feb 5 15:43:45 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Wed Feb 5 14:43:57 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 References: Message-ID: <005401c2cd5f$aae24d20$f30c060a@npd.com> I came from the world of DIKU style MUDs... coded on Merc, Circle/RoA, and ROM mostly. None of those used the go command at all (that I can recall). You had the exits listed and all you had to do to move was type n,w,e,s,u,d, etc... The directions were hard-coded, too, so you couldn't make an exit named "secure door" or the like, it HAD to be one of the pre-defined directions. Sucks, huh? So yeah, ColdCore is the first I've really seen the "go" command used, but it may be more common in other MUSH-like codebases. You'll see it in MU* clients offer the same functionality all the time called pathing or the like. I've never much used go, but it looks like it'd be handy for users. Your average player isn't going to be accustomed to using the go command to move, though. You'd probably get some flack if it was made mandatory. As a player I think it would suck to HAVE to type go west, go east, go door. There's alot to debate when it comes to directionals. I prefer having a standard cardinal and bi-cardinal layout, it just makes it easier to visualize a realm. BUT, the occasional unique exit adds spice and shouldn't be overlooked... just used sparingly. ----- Original Message ----- From: "Gary Whitten" To: Sent: Wednesday, February 05, 2003 3:21 PM Subject: RE: [Coldstuff] Resolving parser ambiguities pt 2 > Grimslayde typed: > >The go command is for following a series of paths... > >say I want to go from my bedroom to the kitchen I'd > >type this: > > >go hall den kitchen > > >And the go command takes each respective exit. So > >when you type go secure door it first takes the > >'secure' exit then the 'door' exit in the next > >room... which takes you right back where you started! > > I'd pretty much extrapolated that and should have said that specifically, I > just wasn't sure if this was intended (it seems it is) and if it is the > 'norm' for other platforms. > > Grimslayde typed: > >You don't have to type go to move around, just the > >exit name... but ye prolly knew that already. > > Nope, never knew that. So just typing 'secure door' will move me the one > room I see. > > ---- > > So given this, let me re-ask the question as: > > a) Is the command GO used similarly in other game platforms, ie to let you > proceed through a series of rooms or does it usually go for just one room? > > b) How many other platforms have the use of a 'GO' type command be optional? > > > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From gary at undiscoveredworlds.com Wed Feb 5 16:56:19 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Wed Feb 5 14:55:18 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: <005401c2cd5f$aae24d20$f30c060a@npd.com> Message-ID: Ok, thanks Grim. My personal feelings on this are: * I don't want to put anything radically different than most people are used to because why annoy people who want to give me money when I don't have to. * I also don't want to force anyone to use anything for similar reasons. * Having the standard directions of N, NE, E, SE, S, SW, W, NW, U, D, O (out) is just ducky with me. * Having a command the way 'Go' is implemented now seems to be 'cheating' to me somehow. If I have this command in my game as is and without other such things as movement roundtime/delays related to room size or ease/difficulty of travel, basically someone could give a string to a new person that would basically allow them to go from a nice safe haven to another safe haven without either experiencing the difficulties or hazards inherent in the journey or experiencing the terrain they pass through, etc. I probably sound naive or something but my game isn't designed to cater to the powergamer and several choices of game design will probably annoy them I guess. This may be one of them. From roys at mindspring.com Wed Feb 5 17:10:48 2003 From: roys at mindspring.com (Roy Sutton) Date: Wed Feb 5 15:12:55 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: References: <005401c2cd5f$aae24d20$f30c060a@npd.com> Message-ID: <5.1.0.14.2.20030205170753.01c401f0@mail.mindspring.com> I concur on the use of the 'go' command. I prefer to make the user do any sort of pathing in his client. (zMud's maps are great for this). IMO, the use of the GO command is a small convenience whose lack will not cause your users to go up in arms. (Hmm, of course, if you have a fantasy RPG you probably -want- your users to go up in arms -- just not at you) Roy At 04:56 PM 2/5/2003, Gary Whitten wrote: >My personal feelings on this are: > >* I don't want to put anything radically different than most people are >used to because why annoy people who want to give me money when I don't have >to. >* I also don't want to force anyone to use anything for similar reasons. >* Having the standard directions of N, NE, E, SE, S, SW, W, NW, U, D, O >(out) is just ducky with me. >* Having a command the way 'Go' is implemented now seems to be 'cheating' >to me somehow. From grimslayde at sbcglobal.net Wed Feb 5 16:14:48 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Wed Feb 5 15:15:00 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 References: Message-ID: <005b01c2cd63$ffcebb30$f30c060a@npd.com> I agree on that last part. It sucks also because you have builders putting their sweat into 5-line room descs that people just WHIZ through and never read. Powergamers always ticked me off when I headed up building initiatives... BUT, whether or not you have a code-side command to walk a path, people have clients that can stack commands. Heck, I use MUSHClient all the time to do all manner of things. So you can exclude it just for your own creed, but unless you code some method to "pause" a user between steps a player will find a way around it. ----- Original Message ----- From: "Gary Whitten" To: Sent: Wednesday, February 05, 2003 3:56 PM Subject: RE: [Coldstuff] Resolving parser ambiguities pt 2 > Ok, thanks Grim. > > My personal feelings on this are: > > * I don't want to put anything radically different than most people are > used to because why annoy people who want to give me money when I don't have > to. > * I also don't want to force anyone to use anything for similar reasons. > * Having the standard directions of N, NE, E, SE, S, SW, W, NW, U, D, O > (out) is just ducky with me. > * Having a command the way 'Go' is implemented now seems to be 'cheating' > to me somehow. If I have this command in my game as is and without other > such things as movement roundtime/delays related to room size or > ease/difficulty of travel, basically someone could give a string to a new > person that would basically allow them to go from a nice safe haven to > another safe haven without either experiencing the difficulties or hazards > inherent in the journey or experiencing the terrain they pass through, etc. > I probably sound naive or something but my game isn't designed to cater to > the powergamer and several choices of game design will probably annoy them I > guess. This may be one of them. > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From brandon at roguetrader.com Wed Feb 5 19:07:51 2003 From: brandon at roguetrader.com (Brandon Gillespie) Date: Wed Feb 5 19:03:45 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: References: Message-ID: <3E41C377.3010202@roguetrader.com> Gary Whitten wrote: > Ok, thanks Grim. > > My personal feelings on this are: > > * I don't want to put anything radically different than most people are > used to because why annoy people who want to give me money when I don't have > to. > * I also don't want to force anyone to use anything for similar reasons. > * Having the standard directions of N, NE, E, SE, S, SW, W, NW, U, D, O > (out) is just ducky with me. > * Having a command the way 'Go' is implemented now seems to be 'cheating' > to me somehow. If I have this command in my game as is and without other > such things as movement roundtime/delays related to room size or > ease/difficulty of travel, basically someone could give a string to a new > person that would basically allow them to go from a nice safe haven to > another safe haven without either experiencing the difficulties or hazards > inherent in the journey or experiencing the terrain they pass through, etc. > I probably sound naive or something but my game isn't designed to cater to > the powergamer and several choices of game design will probably annoy them I > guess. This may be one of them. I have seen the go command on other systems, but it was too long ago for me to recall what they were. These are the systems which inspired me to implement the go command in the first place. For the issues: 1) If people are not reading the descriptions and are willing to just tool through a room quickly, there may be a deeper problem at stake (ever read up on tiny-scenery?). I strongly feel that you should make your rooms compelling enough to stop and enjoy, at least once. If it is just scenery, than you will only annoy the user forcing them to step through six rooms which are trite and useless. 2) the places I saw it used were helpful for newbies. Things like a sign saying 'to get to the library and read the help docs, type: 'go n n w nw' This is much more useful than other methods of directing newbies around. 3) The concern of people zipping through quickly is moot--as has been mentioned you can just do this in a client. However, you COULD implement a delay in the movement code, allowing people to react more quickly. I dont know if there is a delay in the move code or not, but you should probably throw a pause() in there if not a second sleep. either way if you properly use events, things in the room will get the opportunity to respond to the user before they move onwards. -Brandon From gary at undiscoveredworlds.com Wed Feb 5 21:15:55 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Wed Feb 5 19:14:57 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: <3E41C377.3010202@roguetrader.com> Message-ID: Never thought of your example #2, to be honest, Brandon. Interesting thought. As for putting in a pause or sleep or whatever, I'd never want to put in a pause just for the sake of putting in a pause. There are several things, however, I could do to put in reasonably explained pauses. However, what probably will end up happening is that there will be good descriptions, perhaps variable and where necessary to do special things or make sure people aren't using their clients to avoid danger. Thanks everyone for their thoughts. G From brandon at roguetrader.com Wed Feb 5 19:25:27 2003 From: brandon at roguetrader.com (Brandon Gillespie) Date: Wed Feb 5 19:21:20 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: References: Message-ID: <3E41C797.1070909@roguetrader.com> Gary Whitten wrote: > Never thought of your example #2, to be honest, Brandon. Interesting > thought. As for putting in a pause or sleep or whatever, I'd never want to > put in a pause just for the sake of putting in a pause. There are several > things, however, I could do to put in reasonably explained pauses. Actually, the pause() is almost necessary in order to multitask and allow other (event hooked) tasks to execute. -Brandon From gary at undiscoveredworlds.com Wed Feb 5 21:25:20 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Wed Feb 5 19:24:19 2003 Subject: [Coldstuff] Resolving parser ambiguities pt 2 In-Reply-To: <3E41C797.1070909@roguetrader.com> Message-ID: Hmmm, ok, good point. I was saying I wasn't going to do it just to prevent the zooming around mostly. -----Original Message----- From: cold-coldstuff-bounces@cold.org [mailto:cold-coldstuff-bounces@cold.org]On Behalf Of Brandon Gillespie Sent: Wednesday, February 05, 2003 9:25 PM To: coldstuff@cold.org Subject: Re: [Coldstuff] Resolving parser ambiguities pt 2 Gary Whitten wrote: > Never thought of your example #2, to be honest, Brandon. Interesting > thought. As for putting in a pause or sleep or whatever, I'd never want to > put in a pause just for the sake of putting in a pause. There are several > things, however, I could do to put in reasonably explained pauses. Actually, the pause() is almost necessary in order to multitask and allow other (event hooked) tasks to execute. -Brandon _______________________________________________ Cold-Coldstuff mailing list Cold-Coldstuff@cold.org http://web.cold.org/mailman/listinfo/cold-coldstuff From gary at undiscoveredworlds.com Thu Feb 6 09:23:53 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Thu Feb 6 07:22:54 2003 Subject: [Coldstuff] Realms and commands Message-ID: Just a couple questions in relation to realm objects. * How do you define subrealms or does it just happen when you create a realm inside another? * Is there a way to list all the realms showing any subrealms in a 'tree' type format? * Has anyone ever written a method to do an announce to a realm that they're willing to share? * As above but for any other realm based commands? Below is a listing for a method that shows the names of any one realm. Nothing huge but was a definite learning experience for this newbie. @program $builder.show_realms arg realm_name; var loop; for loop in (realm_name.local()) { .tell(loop.name()); } . TIA everyone Gary From grimslayde at sbcglobal.net Thu Feb 6 09:34:08 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Thu Feb 6 08:34:13 2003 Subject: [Coldstuff] Realms and commands References: Message-ID: <000e01c2cdf5$35a591c0$f30c060a@npd.com> I define subrealms by spawning off the parent realm. At one point I altered the @realm command to show subrealms as indentations of the parents, just like in @descend. That was a before the Crash That Really Sucked so many moons ago, so it's gone now... but the premise is simple enough. Check out the code on $programmer.descendants_cmd and see how you can apply that to a better $builder.realms_cmd! As for doing realm "shouts", I've done that too but it was lost and has yet to be recoded. I can tell you that room creation doesn't add to the realm's local var like it should. Check out $place.init_place() or take care of it in the @dig/@build methods. Prolly be easier to do it in the $place.init_place method, just have the realm be the same as the parent object's realm. Clean that code up to keep the realm's rooms up to date, that'll make it easier for other stuff to fall in line, like realm shouts, realm-affect spells, etc... - Grim ----- Original Message ----- From: "Gary Whitten" To: "Coldstuff" Sent: Thursday, February 06, 2003 8:23 AM Subject: [Coldstuff] Realms and commands > Just a couple questions in relation to realm objects. > > * How do you define subrealms or does it just happen when you create a realm > inside another? > > * Is there a way to list all the realms showing any subrealms in a 'tree' > type format? > > * Has anyone ever written a method to do an announce to a realm that they're > willing to share? > > * As above but for any other realm based commands? > > > Below is a listing for a method that shows the names of any one realm. > Nothing huge but was a definite learning experience for this newbie. > > @program $builder.show_realms > > arg realm_name; > var loop; > > for loop in (realm_name.local()) { > > .tell(loop.name()); > > } > . > > > TIA everyone > > Gary > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From gary at undiscoveredworlds.com Thu Feb 6 16:54:16 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Thu Feb 6 14:53:18 2003 Subject: [Coldstuff] Realms and commands In-Reply-To: <000e01c2cdf5$35a591c0$f30c060a@npd.com> Message-ID: I'd intended to do a bunch of stuff with init_place already actually. I'd also wanted to initialize the visibility setting for one. Then I had dug out out all the vars from $place and its parents to check out other potential stuff to work with figuring if I was going to do it, might as well do as much as I could in one swoop. Also would give me a chance to add to the room_information command I'd been working on so I could add that information (like visibility and realm(s) to that as well. In regards to the functionality for those commands, thanks for the tips on what similar commands to peek at. I don't think the concepts are that hard but I had a hard time last nite with the method I posted because one key concept eluded me for awhile. Anyhow, I'll be working on this between now and the end of the week, but hopefully will have most of it done by tonite. Course, I said that LAST nite too. Gary -----Original Message----- From: cold-coldstuff-bounces@cold.org [mailto:cold-coldstuff-bounces@cold.org]On Behalf Of Grimslayde Sent: Thursday, February 06, 2003 10:34 AM To: coldstuff@cold.org Subject: Re: [Coldstuff] Realms and commands I define subrealms by spawning off the parent realm. At one point I altered the @realm command to show subrealms as indentations of the parents, just like in @descend. That was a before the Crash That Really Sucked so many moons ago, so it's gone now... but the premise is simple enough. Check out the code on $programmer.descendants_cmd and see how you can apply that to a better $builder.realms_cmd! As for doing realm "shouts", I've done that too but it was lost and has yet to be recoded. I can tell you that room creation doesn't add to the realm's local var like it should. Check out $place.init_place() or take care of it in the @dig/@build methods. Prolly be easier to do it in the $place.init_place method, just have the realm be the same as the parent object's realm. Clean that code up to keep the realm's rooms up to date, that'll make it easier for other stuff to fall in line, like realm shouts, realm-affect spells, etc... - Grim From gary at undiscoveredworlds.com Fri Feb 7 00:23:40 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Thu Feb 6 22:22:43 2003 Subject: [Coldstuff] Equivalents of 'Attributes' Message-ID: Hi folks I was wondering if several of you who are much more familiar with building in other systems could take some time and elaborate on how you would explain how things are done in ColdC and ColdCore to someone who is more used to building things in code bases where they use 'Attributes' to do various things. I'm looking for a bit of help in explaining the capabilites but lack the comparisons and knowledge to do so. TIA (as always) Gary From grimslayde at sbcglobal.net Fri Feb 7 05:58:42 2003 From: grimslayde at sbcglobal.net (Grimslayde) Date: Fri Feb 7 04:59:36 2003 Subject: [Coldstuff] Equivalents of 'Attributes' References: Message-ID: <000401c2cea0$62626520$4743fea9@dc> Not sure what you mean by attributes or what they might possibly do... I assume you mean stuff like spell effects, room or physical conditions. Hope I'm on the right track here. I came from the world of DIKU, so everything was a flag there. You had a single variable that used bitwise comparison on to store flags. Things like poison, invisibility, disease, flight, etc were like switches that were on or off. Rooms were the same way for things like deathtraps or other suchness. Usually each of these flags would have effects that would trigger when the nanny function updated everyone/everything each tick. It all worked very well but seemed quite limiting. The way I'm handling things on ColdCore, I'm using a dictionary for each kind of effect such as conditions, spells, etc. Each update the core filters through that dictionary and updates the object they affect by calling an update method. I've only worked briefly on other types like PennMUSH and their like, none of which had much developed. Can't provide much more example from that. ----- Original Message ----- From: "Gary Whitten" To: "Coldstuff" Sent: Thursday, February 06, 2003 11:23 PM Subject: [Coldstuff] Equivalents of 'Attributes' > Hi folks > > I was wondering if several of you who are much more familiar with building > in other systems could take some time and elaborate on how you would explain > how things are done in ColdC and ColdCore to someone who is more used to > building things in code bases where they use 'Attributes' to do various > things. > > I'm looking for a bit of help in explaining the capabilites but lack the > comparisons and knowledge to do so. > > TIA (as always) > > Gary > > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From gary at undiscoveredworlds.com Fri Feb 7 08:04:43 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Fri Feb 7 06:03:45 2003 Subject: [Coldstuff] Equivalents of 'Attributes' In-Reply-To: <000401c2cea0$62626520$4743fea9@dc> Message-ID: Actually no. The kind of stuff you described I'm almost ok with. I was seriously debating putting in something like 'if you aren't sure what an attribute was, save your time, you don't have the answers I need' but couldn't find a nice way to phrase it. Sorry if you spent a lot of time on that answer but there are a few things in your answer I can use and I'm sure others will read the answer and go 'Hey, cool' :) *I* am not entirely sure about them either but basically I think attributes are like a generic thing that you can turn into a note, a code snippet, a variable or something like that. In the game I used to run, each 'effect' would be in one of seven (I think) effect 'slots'. If you cast a spell that used slot 3 and nothing was there, fine. If there was, depending on the spell, it would either overwrite the current effect or fail. Anyhow, each slot would have the spell # in it and a duration marker (you'd probably duplicate it with a list here). Every 'tick' would decrement the duration until it hit 0 and expire as well as run through the various effects and check to see if anything needed to be done and then did it. I was planning, at least at first, to use a system fairly similar to this but I like how you handle it with the update method. Very nice. -----Original Message----- From: cold-coldstuff-bounces@cold.org [mailto:cold-coldstuff-bounces@cold.org]On Behalf Of Grimslayde Sent: Friday, February 07, 2003 6:59 AM To: coldstuff@cold.org Subject: Re: [Coldstuff] Equivalents of 'Attributes' Not sure what you mean by attributes or what they might possibly do... I assume you mean stuff like spell effects, room or physical conditions. Hope I'm on the right track here. I came from the world of DIKU, so everything was a flag there. From gary at undiscoveredworlds.com Fri Feb 7 08:09:43 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Fri Feb 7 06:08:45 2003 Subject: [Coldstuff] Equivalents of 'Attributes' In-Reply-To: <000401c2cea0$62626520$4743fea9@dc> Message-ID: For the record, this is what she said to me in our meeting last night. "I create a room with the @dig command, an exit with the @open command, and an item with the @create command -- which gives the resulting item a 'type' flag. From there, everything is wide open. I CAN @parent it to another item.. you don't create a new instance of the item to start with.. you create a generic item.. then if you want, @parent it and set it with the inherit flag.. and it will inherit all attributes from the parent.. I'd just define an attribute for it. The attributes can hold variables, code, or just notes." From brandon at roguetrader.com Fri Feb 7 08:47:19 2003 From: brandon at roguetrader.com (Brandon Gillespie) Date: Fri Feb 7 08:46:46 2003 Subject: [Coldstuff] Equivalents of 'Attributes' In-Reply-To: References: Message-ID: <3E43D507.3000206@roguetrader.com> In Cold code and data are seperate--methods are used for code, data is stored in variables on the object. Variables are accessed through ColdC code. For the VR in ColdCore there is an additional ease-of-use thing called settings, which built-in inheritance and a few other things. You access these with @set. There are also specific "attributes" (used in the generic sense), depending upon which parents the object has, such as a name, description, contents, exits, etc. These are all updated and managed under the hood in variables, and accessed using varying means. -Brandon From owel at ptd.net Wed Feb 12 15:36:28 2003 From: owel at ptd.net (owel@ptd.net) Date: Wed Feb 12 13:34:23 2003 Subject: [Coldstuff] Searching personal environment Message-ID: <001c01c2d2d6$6bf72af0$9900a8c0@alpha> A number of people have been asking me about adding MY to our core when referencing something in one's environment. For example, if there were two birds in a room, and I picked one up, "LOOK MY BIRD" would show me the description of the one I was holding, instead of the other. "PUT BIRD IN MY BAG" would definately put it in the bag I was holding, instead of the one on the ground. So the point is, is there already code in place for a personal environment and I'm missing it, or was their a past discussion about this? I searched the archives and couldn't find anything. As always, any help or advice is appreciated in advance. From acormany at yahoo.com Fri Feb 14 08:14:34 2003 From: acormany at yahoo.com (Adam Cormany) Date: Fri Feb 14 09:14:40 2003 Subject: [Coldstuff] scour command Message-ID: <20030214161434.970.qmail@web12806.mail.yahoo.com> I was looking around at the various commands today and noticed one called @scour ($admin.scour_cmd) that I overlooked in the past. Could someone tell me what @scour is, what it does, maybe an example and/or syntax to use it. I can't find a help file for it and I've tried using it with no luck. Thanks in advance, Adam(Soth) __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From msmouse at kittymail.com Fri Feb 14 11:52:59 2003 From: msmouse at kittymail.com (K Anderson) Date: Fri Feb 14 12:53:26 2003 Subject: [Coldstuff] scour command Message-ID: <20030214195259.1376.qmail@kittymail.com> Hi, @which @scour says @scour $admin.scour_cmd here's an example that works- @scour setting :content-type equals ansi d $root .. $user Here's my take on it. search the db for a setting called :content-type equals ansi (this doesn't seem to do anything, nor is an error thrown if left out) descendants $root .. $user search from $root to $user and display the results I tried applying the same syntax for the other choices of variable and method are elusive. I think the @scour is either more powerful/weaker version of the @grep command. I'm trying to put little .tells in the program when it looks but no luck. best of luck to you. HTH ----- Original Message ----- From: Adam Cormany Date: Fri, 14 Feb 2003 08:14:34 -0800 (PST) To: Cold Subject: [Coldstuff] scour command > I was looking around at the various commands today and > noticed one called @scour ($admin.scour_cmd) that I > overlooked in the past. > > Could someone tell me what @scour is, what it does, > maybe an example and/or syntax to use it. I can't find > a help file for it and I've tried using it with no > luck. > > Thanks in advance, > Adam(Soth) > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > -- _______________________________________________ Get your free email from http://www.kittymail.com Powered by Outblaze From patm at pureconnection.net Wed Feb 5 18:15:13 2003 From: patm at pureconnection.net (Pat Moroney) Date: Thu Feb 20 22:52:55 2003 Subject: [Coldstuff] List issues. Message-ID: <465E88A5809A9E4F9D6313331087BC4034A067@les1.lstrat.com> I'm subscribed to this list through another one of my email addresses. How would i change my account to show this address, so that i dont have to get moderator approval? And also how do I subscribe to the other lists, such as genesis ones? From brandon at roguetrader.com Thu Feb 20 22:58:49 2003 From: brandon at roguetrader.com (Brandon Gillespie) Date: Thu Feb 20 22:58:08 2003 Subject: [Coldstuff] List issues. In-Reply-To: <465E88A5809A9E4F9D6313331087BC4034A067@les1.lstrat.com> References: <465E88A5809A9E4F9D6313331087BC4034A067@les1.lstrat.com> Message-ID: <3E55C019.2070102@roguetrader.com> Pat Moroney wrote: > I'm subscribed to this list through another one of my email addresses. How > would i change my account to show this address, so that i dont have to get > moderator approval? And also how do I subscribe to the other lists, such as > genesis ones? The list server emails monthly(?) your password and a link to the web interface, you should be able to login on the web with that and change your address. If you are having problems with it, send me your old email address and I can change it. -Brandon From gary at undiscoveredworlds.com Fri Feb 21 02:57:10 2003 From: gary at undiscoveredworlds.com (Gary Whitten) Date: Fri Feb 21 00:55:47 2003 Subject: [Coldstuff] List issues. In-Reply-To: <3E55C019.2070102@roguetrader.com> Message-ID: Brandon I don't think I've ever gotten such an automated email from the list server, just an FYI. Gary -----Original Message----- From: cold-coldstuff-bounces@cold.org [mailto:cold-coldstuff-bounces@cold.org]On Behalf Of Brandon Gillespie Sent: Friday, February 21, 2003 12:59 AM To: coldstuff@cold.org Subject: Re: [Coldstuff] List issues. Pat Moroney wrote: > I'm subscribed to this list through another one of my email addresses. How > would i change my account to show this address, so that i dont have to get > moderator approval? And also how do I subscribe to the other lists, such as > genesis ones? The list server emails monthly(?) your password and a link to the web interface, you should be able to login on the web with that and change your address. If you are having problems with it, send me your old email address and I can change it. -Brandon _______________________________________________ Cold-Coldstuff mailing list Cold-Coldstuff@cold.org http://web.cold.org/mailman/listinfo/cold-coldstuff From acormany at yahoo.com Thu Feb 27 16:22:29 2003 From: acormany at yahoo.com (Adam Cormany) Date: Thu Feb 27 17:22:36 2003 Subject: [Coldstuff] $uncompiler._eval_ctext Message-ID: <20030228002229.37121.qmail@web12805.mail.yahoo.com> I've been messing around more with $ctext_frob's and noticed when I set one with spaces, my spaces during the display is doubled. For instance, say my $ctext_frob is called ctfrob, with text in it " Blah". When I do join(ctfrob.uncompile()), I get " Blah". I traced this back to $uncompiler._eval_ctext() calling $uncompiler._spaces(), with the lines: case 'string: token = quote_all ? .quote_all(token) : .quote(token); token = ._spaces(token, prev, 'prev); token = ._spaces(token, next, 'next); out = out.affix(token); If I comment out the two lines that call ._spaces(), my ctfrob is correct. Can anyone tell me what this $uncompiler._spaces() is for and is it needed in $uncompiler._eval_ctext()? Thanks in advance, Adam __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/