From coldstuff@cold.org Sun Sep 1 07:07:21 2002 From: coldstuff@cold.org (K Anderson) Date: Sat, 31 Aug 2002 22:07:21 -0800 Subject: [Coldstuff] guilds Message-ID: <20020901060721.29084.qmail@kittymail.com> Oooh, finally, a question I can even answer. Alrighty make an object with parents of $user_interfaces, and maybe $event_handler (but I think this is something I was trying out so leave it off, but add if it doesn't work). Then you need to add it to comman-modules. This is an @set thing I think. to add a command module do @set command-modules=+$. For example I created a command module of $telepath so I just do @set command-modules=+$telepath to see if it has been added do @set me: and it will show up in your list of command modules. Take a look at the command module sof $social and $anti-social. Check out @help command modules :) Woo-hooo. Then I think you'll need to do @rehash or something like that. here's an example of something for a $telepath @program $telepath.path_cmd() +access=pub arg cmdstr, cmd, path_to, prep, path_msg; (> .perms(caller(), 'command) <); s = sender(); vars = #[["$actor", s],["actor", s.name()]]; if (path_msg) vars=vars.add("$path_msg", path_msg).add("path_msg", path_msg); message = s.eval_message(cmd, definer(), vars); for o in ([s, path_to]) o.location().announce(message); . What it does is then path to a person. to use do path with and there you have it. pretty spiffy :) HTH ----- Original Message ----- From: Mark Cheverton Date: 29 Aug 2002 11:59:34 +0100 To: coldstuff@cold.org Subject: [Coldstuff] guilds > Hi, > > I'm just working through the first steps of coldc and have decided to > start by working on a guild system. This has raised a few initial > questions. > > I envision the guild adding commands to the player, so where in the > heirachy should it be? In MOO I guess I would have probably have added > it as a feature. Is it best to do this as a parser and add that parser > to the user, or make the guild a descendant of $has_commands and insert > that into the heirachy (I tried adding this as another parent of $player > and borked everything, I guess the commands overwrote the default > commands and I was locked out from my only admin account - oops). > > Its not particularly clear where extra player abilities like > $guild_member should go in the heirachy that aren't VR objects, I can't > seem to find anything that equates to features in moo. Should I just > subclass $player for the different guilds and switch the type of object > a user is when they join a guild? What's best practice? > > Thanks. > > -Mark > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > > -- _______________________________________________ Get your free email from www.kittymail.com Powered by Outblaze From coldstuff@cold.org Mon Sep 2 11:09:15 2002 From: coldstuff@cold.org (Mark Cheverton) Date: 02 Sep 2002 11:09:15 +0100 Subject: [Coldstuff] guilds In-Reply-To: <20020901060721.29084.qmail@kittymail.com> References: <20020901060721.29084.qmail@kittymail.com> Message-ID: <1030961365.2477.0.camel@localhost.localdomain> On Sun, 2002-09-01 at 07:07, K Anderson wrote: > Oooh, finally, a question I can even answer. > Excellent stuff, very complete answer thanks. Right, lots for me to explore... -Mark From coldstuff@cold.org Wed Sep 4 05:38:25 2002 From: coldstuff@cold.org (Robert Stout) Date: Wed, 04 Sep 2002 00:38:25 -0400 Subject: [Coldstuff] The Cold Software Project Message-ID: Hello, I came across your website after a seven month-long search for a codebase on which to build a mud game I am planning. I've reviewed everything from "PennMush" to "The Dawn of Time" codebases. Needless to say it has been worth the wait. I am very excited about the potential your program offers. The bad thing however is I am very new to programming and can see that if I am going to impliment some of the features I have in mind I've alot to learn. I was wondering if you know of any resources (web articles or books) I could check out that would help me learn to use ColdC effectively. I *embarassed to say* don't know C programming (yet). I assume knowing C (and/or C++) is a requirement before even considering building a mud-game on ColdC? The game I have in mind is alot like "The Eternal City" style - which runs on your codebase. I don't want to waste your time but I was hoping you could help me.. get started - point me in the right direction? If not that's ok. FYI: I am running an older (1996) computer using Windows 98 :(. But I have plans to buy a new computer. Should I break-out of windows and join the Unix community? I am deticated, and I will do what I need to do and learn what I need to learn inorder to get this game online. I just need help with directions, I can handle the grunt work myself. Thank you for your time. I'm hoping to hear back from you. Robert - Harken - Haxdeth - Microp Signed, Robert J. Stout talonthalas@hotmail.com _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From coldstuff@cold.org Wed Sep 4 16:02:56 2002 From: coldstuff@cold.org (coldstuff@cold.org) Date: Wed, 4 Sep 2002 10:02:56 -0500 Subject: [Coldstuff] The Cold Software Project In-Reply-To: Message-ID: --openmail-part-00996ced-00000002 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Wed, 4 Sep 2002 09:41:26 -0500" Content-Transfer-Encoding: quoted-printable Hey Robert, Welcome to the show! There are ALOT of codebases out there to buil= d a game from, believe me I've been in the same boat as you are right now... with= no prior coding experience and only the drive to make a great game. And a c= rappy Win98 box to boot! But with perserverance you can succeed. There are a TON of good coding resources when it comes to learning= C, and in truth, once you get used to the ColdCore environment it's much easier= learning it there because it's all compiled run-time. You can make a qui= ck method and test it right then and there! ColdCore's language, ColdC, is thoroughly documented. It's like a toned-down version of regular C, so all the syntax is the same. ColdCor= e itself is not so documented, but that shouldn't slow you down much. It's a bril= liant piece of work right out of the box. After years of coding and restarting= and pestering the nine HELLS out of this forum and the folks on TCD there ar= e still things I'm learning. =20 You can find resources in your local bookstore or on the internet.= Look up stuff like C programming and definately look into Object Oriented Progra= mming. It takes a little to get adjusted to the thought of encapsulation and inheritance in OOP. Any help you can get is good in that departement = Stop by TCD sometime, we'll chat it up. You'd be surprised how man= y people on this forum are going through the same thing you are. My game is STILL= under development after all these years (gawd I'm lazy). I'd be more than happ= y to trade talk and theory any time. And the folks on TCD are extremely helpf= ul when you can catch them unidle. Good luck! =2D Grim > Hello, >=20 > I came across your website after a seven month-long search for a codeb= ase on=20 > which to build a mud game I am planning. I've reviewed everything from= =20 > "PennMush" to "The Dawn of Time" codebases. >=20 > Needless to say it has been worth the wait. I am very excited about th= e=20 > potential your program offers. >=20 > The bad thing however is I am very new to programming and can see that= if I=20 > am going to impliment some of the features I have in mind I've alot to= =20 > learn. >=20 > I was wondering if you know of any resources (web articles or books) I= could=20 > check out that would help me learn to use ColdC effectively. I *embara= ssed=20 > to say* don't know C programming (yet). >=20 > I assume knowing C (and/or C++) is a requirement before even consideri= ng=20 > building a mud-game on ColdC? >=20 > The game I have in mind is alot like "The Eternal City" style - which = runs=20 > on your codebase. >=20 > I don't want to waste your time but I was hoping you could help me.. g= et=20 > started - point me in the right direction? If not that's ok. >=20 > FYI: I am running an older (1996) computer using Windows 98 :(. But I = have=20 > plans to buy a new computer. Should I break-out of windows and join th= e Unix=20 > community? >=20 > I am deticated, and I will do what I need to do and learn what I need = to=20 > learn inorder to get this game online. I just need help with direction= s, I=20 > can handle the grunt work myself. >=20 > Thank you for your time. I'm hoping to hear back from you. >=20 > Robert - Harken - Haxdeth - Microp >=20 > Signed, > Robert J. Stout > talonthalas@hotmail.com >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > MSN Photos is the easiest way to share and print your photos:=20 > http://photos.msn.com/support/worldwide.aspx >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff >=20 =20 --openmail-part-00996ced-00000002 Content-Type: application/rtf Content-Disposition: attachment ;Creation-Date="Wed, 4 Sep 2002 09:41:26 -0500" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcZGVmZjB7XGZvbnR0Ymx7XGYwXGZyb21hbiBUbXMgUm1uO317XGYxXGZy b21hbiBDb3VyaWVyIE5ldzt9fXtcY29sb3J0YmxccmVkMFxncmVlbjBcYmx1ZTA7XHJlZDBc Z3JlZW4wXGJsdWUyNTU7XHJlZDBcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVlbjI1NVxi bHVlMDtccmVkMjU1XGdyZWVuMFxibHVlMjU1O1xyZWQyNTVcZ3JlZW4wXGJsdWUwO1xyZWQy NTVcZ3JlZW4yNTVcYmx1ZTA7XHJlZDI1NVxncmVlbjI1NVxibHVlMjU1O1xyZWQwXGdyZWVu MFxibHVlMTI3O1xyZWQwXGdyZWVuMTI3XGJsdWUxMjc7XHJlZDBcZ3JlZW4xMjdcYmx1ZTA7 XHJlZDEyN1xncmVlbjBcYmx1ZTEyNztccmVkMTI3XGdyZWVuMFxibHVlMDtccmVkMTI3XGdy ZWVuMTI3XGJsdWUwO1xyZWQxMjdcZ3JlZW4xMjdcYmx1ZTEyNztccmVkMTkyXGdyZWVuMTky XGJsdWUxOTJ9e1xpbmZve1xjcmVhdGltXHlyMjAwMlxtbzlcZHk0XGhyOVxtaW40MVxzZWMy N317XHZlcnNpb24xfXtcdmVybjE5Nzk4NX19XHBhcGVydzEyMjQwXHBhcGVyaDE1ODQwXG1h cmdsMTMyNFxtYXJncjEzMTBcbWFyZ3QxNDQwXG1hcmdiMTQ0MFxkZWZ0YWI3MjBccGFyZFxx bHtcZjFcZnMyMFxjZjBcdXAwXGRuMCBIZXkgUm9iZXJ0LH17XHBhcn1ccGFyZFxxbHtcZjFc ZnMyMFxjZjBcdXAwXGRuMFx0YWJ9e1xmMVxmczIwXGNmMFx1cDBcZG4wIFdlbGNvbWUgdG8g dGhlIHNob3chIFRoZXJlIGFyZSBBTE9UIG9mIGNvZGViYXNlcyBvdXQgdGhlcmUgdG8gYnVp bGQgYSBnYW1lIH1ccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgZnJvbSwgYmVsaWV2ZSBtZSBJ J3ZlIGJlZW4gaW4gdGhlIHNhbWUgYm9hdCBhcyB5b3UgYXJlIHJpZ2h0IG5vdy4uLiB3aXRo IG5vIH1ccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgcHJpb3IgY29kaW5nIGV4cGVyaWVuY2Ug YW5kIG9ubHkgdGhlIGRyaXZlIHRvIG1ha2UgYSBncmVhdCBnYW1lLiBBbmQgYSBjcmFwcHkg fVxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCBXaW45OCBib3ggdG8gYm9vdCEgQnV0IHdpdGgg cGVyc2VydmVyYW5jZSB5b3UgY2FuIHN1Y2NlZWQufXtccGFyfVxwYXJkXHFse1xmMVxmczIw XGNmMFx1cDBcZG4wXHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMFx0YWJ9e1xm MVxmczIwXGNmMFx1cDBcZG4wIFRoZXJlIGFyZSBhIFRPTiBvZiBnb29kIGNvZGluZyByZXNv dXJjZXMgd2hlbiBpdCBjb21lcyB0byBsZWFybmluZyBDLCBhbmQgfVxxbHtcZjFcZnMyMFxj ZjBcdXAwXGRuMCBpbiB0cnV0aCwgb25jZSB5b3UgZ2V0IHVzZWQgdG8gdGhlIENvbGRDb3Jl IGVudmlyb25tZW50IGl0J3MgbXVjaCBlYXNpZXIgfVxxbHtcZjFcZnMyMFxjZjBcdXAwXGRu MCBsZWFybmluZyBpdCB0aGVyZSBiZWNhdXNlIGl0J3MgYWxsIGNvbXBpbGVkIHJ1bi10aW1l LiBZb3UgY2FuIG1ha2UgYSBxdWljayB9XHFse1xmMVxmczIwXGNmMFx1cDBcZG4wIG1ldGhv ZCBhbmQgdGVzdCBpdCByaWdodCB0aGVuIGFuZCB0aGVyZSF9e1xwYXJ9XHBhcmRccWx7XGYx XGZzMjBcY2YwXHVwMFxkbjBccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wXHRh Yn17XGYxXGZzMjBcY2YwXHVwMFxkbjAgQ29sZENvcmUncyBsYW5ndWFnZSwgQ29sZEMsIGlz IHRob3JvdWdobHkgZG9jdW1lbnRlZC4gSXQncyBsaWtlIGEgdG9uZWQtfVxxbHtcZjFcZnMy MFxjZjBcdXAwXGRuMCBkb3duIHZlcnNpb24gIG9mIHJlZ3VsYXIgQywgc28gYWxsIHRoZSBz eW50YXggaXMgdGhlIHNhbWUuIENvbGRDb3JlIGl0c2VsZiBpcyB9XHFse1xmMVxmczIwXGNm MFx1cDBcZG4wIG5vdCBzbyBkb2N1bWVudGVkLCBidXQgdGhhdCBzaG91bGRuJ3Qgc2xvdyB5 b3UgZG93biBtdWNoLiBJdCdzIGEgYnJpbGxpYW50IHBpZWNlIH1ccWx7XGYxXGZzMjBcY2Yw XHVwMFxkbjAgb2Ygd29yayByaWdodCBvdXQgb2YgdGhlIGJveC4gQWZ0ZXIgeWVhcnMgb2Yg Y29kaW5nIGFuZCByZXN0YXJ0aW5nIGFuZCBwZXN0ZXJpbmcgfVxxbHtcZjFcZnMyMFxjZjBc dXAwXGRuMCB0aGUgbmluZSBIRUxMUyBvdXQgb2YgdGhpcyBmb3J1bSBhbmQgdGhlIGZvbGtz IG9uIFRDRCB0aGVyZSBhcmUgc3RpbGwgdGhpbmdzIEknbSB9XHFse1xmMVxmczIwXGNmMFx1 cDBcZG4wIGxlYXJuaW5nLn17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMFx0 YWJ9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjBcdGFifXtcZjFcZnMyMFxj ZjBcdXAwXGRuMCBZb3UgY2FuIGZpbmQgcmVzb3VyY2VzIGluIHlvdXIgbG9jYWwgYm9va3N0 b3JlIG9yIG9uIHRoZSBpbnRlcm5ldC4gTG9vayB1cCB9XHFse1xmMVxmczIwXGNmMFx1cDBc ZG4wIHN0dWZmIGxpa2UgQyBwcm9ncmFtbWluZyBhbmQgZGVmaW5hdGVseSBsb29rIGludG8g T2JqZWN0IE9yaWVudGVkIFByb2dyYW1taW5nLiB9XHFse1xmMVxmczIwXGNmMFx1cDBcZG4w IEl0IHRha2VzIGEgbGl0dGxlIHRvIGdldCBhZGp1c3RlZCB0byB0aGUgdGhvdWdodCBvZiBl bmNhcHN1bGF0aW9uIGFuZCB9XHFse1xmMVxmczIwXGNmMFx1cDBcZG4wIGluaGVyaXRhbmNl IGluIE9PUC4gQW55IGhlbHAgeW91IGNhbiBnZXQgaXMgZ29vZCBpbiB0aGF0IGRlcGFydGVt ZW50fXtcZjFcZnMyMFxjZjBcdXAwXGRuMFx0YWJ9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBc Y2YwXHVwMFxkbjBccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wXHRhYn17XGYx XGZzMjBcY2YwXHVwMFxkbjAgU3RvcCBieSBUQ0Qgc29tZXRpbWUsIHdlJ2xsIGNoYXQgaXQg dXAuIFlvdSdkIGJlIHN1cnByaXNlZCBob3cgbWFueSBwZW9wbGUgfVxxbHtcZjFcZnMyMFxj ZjBcdXAwXGRuMCBvbiB0aGlzIGZvcnVtIGFyZSBnb2luZyB0aHJvdWdoIHRoZSBzYW1lIHRo aW5nIHlvdSBhcmUuIE15IGdhbWUgaXMgU1RJTEwgdW5kZXIgfVxxbHtcZjFcZnMyMFxjZjBc dXAwXGRuMCBkZXZlbG9wbWVudCBhZnRlciBhbGwgdGhlc2UgeWVhcnMgKGdhd2QgSSdtIGxh enkpLiBJJ2QgYmUgbW9yZSB0aGFuIGhhcHB5IHRvIH1ccWx7XGYxXGZzMjBcY2YwXHVwMFxk bjAgdHJhZGUgdGFsayBhbmQgdGhlb3J5IGFueSB0aW1lLiBBbmQgdGhlIGZvbGtzIG9uIFRD RCBhcmUgZXh0cmVtZWx5IGhlbHBmdWwgd2hlbiB9XHFse1xmMVxmczIwXGNmMFx1cDBcZG4w IHlvdSBjYW4gY2F0Y2ggdGhlbSB1bmlkbGUufXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNm MFx1cDBcZG4wXHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCBHb29kIGx1Y2sh fXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wIC0gR3JpbX17XHBhcn1ccGFy ZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMFxwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVw MFxkbjBccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wID4gSGVsbG8sfXtccGFy fVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wID4gfXtccGFyfVxwYXJkXHFse1xmMVxm czIwXGNmMFx1cDBcZG4wID4gSSBjYW1lIGFjcm9zcyB5b3VyIHdlYnNpdGUgYWZ0ZXIgYSBz ZXZlbiBtb250aC1sb25nIHNlYXJjaCBmb3IgYSBjb2RlYmFzZSBvbiB9e1xwYXJ9XHBhcmRc cWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiB3aGljaCB0byBidWlsZCBhIG11ZCBnYW1lIEkg YW0gcGxhbm5pbmcuIEkndmUgcmV2aWV3ZWQgZXZlcnl0aGluZyBmcm9tIH17XHBhcn1ccGFy ZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+ICJQZW5uTXVzaCIgdG8gIlRoZSBEYXduIG9m IFRpbWUiIGNvZGViYXNlcy59e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAg PiB9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBOZWVkbGVzcyB0byBz YXkgaXQgaGFzIGJlZW4gd29ydGggdGhlIHdhaXQuIEkgYW0gdmVyeSBleGNpdGVkIGFib3V0 IHRoZSB9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBwb3RlbnRpYWwg eW91ciBwcm9ncmFtIG9mZmVycy59e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxk bjAgPiB9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBUaGUgYmFkIHRo aW5nIGhvd2V2ZXIgaXMgSSBhbSB2ZXJ5IG5ldyB0byBwcm9ncmFtbWluZyBhbmQgY2FuIHNl ZSB0aGF0IGlmIEkgfXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wID4gYW0g Z29pbmcgdG8gaW1wbGltZW50IHNvbWUgb2YgdGhlIGZlYXR1cmVzIEkgaGF2ZSBpbiBtaW5k IEkndmUgYWxvdCB0byB9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBs ZWFybi59e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiB9e1xwYXJ9XHBh cmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBJIHdhcyB3b25kZXJpbmcgaWYgeW91IGtu b3cgb2YgYW55IHJlc291cmNlcyAod2ViIGFydGljbGVzIG9yIGJvb2tzKSBJIGNvdWxkIH17 XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IGNoZWNrIG91dCB0aGF0IHdv dWxkIGhlbHAgbWUgbGVhcm4gdG8gdXNlIENvbGRDIGVmZmVjdGl2ZWx5LiBJICplbWJhcmFz c2VkIH17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IHRvIHNheSogZG9u J3Qga25vdyBDIHByb2dyYW1taW5nICh5ZXQpLn17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxj ZjBcdXAwXGRuMCA+IH17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IEkg YXNzdW1lIGtub3dpbmcgQyAoYW5kL29yIEMrKykgaXMgYSByZXF1aXJlbWVudCBiZWZvcmUg ZXZlbiBjb25zaWRlcmluZyB9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAg PiBidWlsZGluZyBhIG11ZC1nYW1lIG9uIENvbGRDP317XHBhcn1ccGFyZFxxbHtcZjFcZnMy MFxjZjBcdXAwXGRuMCA+IH17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+ IFRoZSBnYW1lIEkgaGF2ZSBpbiBtaW5kIGlzIGFsb3QgbGlrZSAiVGhlIEV0ZXJuYWwgQ2l0 eSIgc3R5bGUgLSB3aGljaCBydW5zIH17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAw XGRuMCA+IG9uIHlvdXIgY29kZWJhc2UufXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1 cDBcZG4wID4gfXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wID4gSSBkb24n dCB3YW50IHRvIHdhc3RlIHlvdXIgdGltZSBidXQgSSB3YXMgaG9waW5nIHlvdSBjb3VsZCBo ZWxwIG1lLi4gZ2V0IH17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IHN0 YXJ0ZWQgLSBwb2ludCBtZSBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uPyBJZiBub3QgdGhhdCdz IG9rLn17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IH17XHBhcn1ccGFy ZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IEZZSTogSSBhbSBydW5uaW5nIGFuIG9sZGVy ICgxOTk2KSBjb21wdXRlciB1c2luZyBXaW5kb3dzIDk4IDooLiBCdXQgSSBoYXZlIH17XHBh cn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IHBsYW5zIHRvIGJ1eSBhIG5ldyBj b21wdXRlci4gU2hvdWxkIEkgYnJlYWstb3V0IG9mIHdpbmRvd3MgYW5kIGpvaW4gdGhlIFVu aXggfXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wID4gY29tbXVuaXR5P317 XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IH17XHBhcn1ccGFyZFxxbHtc ZjFcZnMyMFxjZjBcdXAwXGRuMCA+IEkgYW0gZGV0aWNhdGVkLCBhbmQgSSB3aWxsIGRvIHdo YXQgSSBuZWVkIHRvIGRvIGFuZCBsZWFybiB3aGF0IEkgbmVlZCB0byB9e1xwYXJ9XHBhcmRc cWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBsZWFybiBpbm9yZGVyIHRvIGdldCB0aGlzIGdh bWUgb25saW5lLiBJIGp1c3QgbmVlZCBoZWxwIHdpdGggZGlyZWN0aW9ucywgSSB9e1xwYXJ9 XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBjYW4gaGFuZGxlIHRoZSBncnVudCB3 b3JrIG15c2VsZi59e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiB9e1xw YXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBUaGFuayB5b3UgZm9yIHlvdXIg dGltZS4gSSdtIGhvcGluZyB0byBoZWFyIGJhY2sgZnJvbSB5b3UufXtccGFyfVxwYXJkXHFs e1xmMVxmczIwXGNmMFx1cDBcZG4wID4gfXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1 cDBcZG4wID4gUm9iZXJ0IC0gSGFya2VuIC0gSGF4ZGV0aCAtIE1pY3JvcH17XHBhcn1ccGFy ZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IH17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxj ZjBcdXAwXGRuMCA+IFNpZ25lZCx9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxk bjAgPiBSb2JlcnQgSi4gU3RvdXR9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxk bjAgPiB0YWxvbnRoYWxhc0Bob3RtYWlsLmNvbX17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxj ZjBcdXAwXGRuMCA+IH17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19ffXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wID4gTVNOIFBo b3RvcyBpcyB0aGUgZWFzaWVzdCB3YXkgdG8gc2hhcmUgYW5kIHByaW50IHlvdXIgcGhvdG9z OiB9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBodHRwOi8vcGhvdG9z Lm1zbi5jb20vc3VwcG9ydC93b3JsZHdpZGUuYXNweH17XHBhcn1ccGFyZFxxbHtcZjFcZnMy MFxjZjBcdXAwXGRuMCA+IH17XHBhcn1ccGFyZFxxbHtcZjFcZnMyMFxjZjBcdXAwXGRuMCA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19ffXtccGFy fVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wID4gQ29sZC1Db2xkc3R1ZmYgbWFpbGlu ZyBsaXN0fXtccGFyfVxwYXJkXHFse1xmMVxmczIwXGNmMFx1cDBcZG4wID4gQ29sZC1Db2xk c3R1ZmZAY29sZC5vcmd9e1xwYXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiBo dHRwOi8vd2ViLmNvbGQub3JnL21haWxtYW4vbGlzdGluZm8vY29sZC1jb2xkc3R1ZmZ9e1xw YXJ9XHBhcmRccWx7XGYxXGZzMjBcY2YwXHVwMFxkbjAgPiB9e1xwYXJ9XHBhcmRccWx7XGYx XGZzMjBcY2YwXHVwMFxkbjAgIH19 --openmail-part-00996ced-00000002-- From coldstuff@cold.org Wed Sep 4 18:42:48 2002 From: coldstuff@cold.org (Jeremy Weatherford) Date: Wed, 4 Sep 2002 10:42:48 -0700 (PDT) Subject: [Coldstuff] The Cold Software Project In-Reply-To: Message-ID: Hello, While doing a few quick tutorials on C would certainly be helpful for ColdC, remember that they are distinct languages. If your goal is to be useful in ColdC quickly, don't spend too much time on obscure features and library calls in C, and especially don't learn the specifics of C++'s object orientation. Concepts are good, but don't learn the specifics unless you have to, since they're completely different under ColdC. ColdCore is an amazing resource... learn how to navigate and explore its code, keep a copy of its textdump under your pillow, etc. Just remember that There's More Than One Way To Do It. It's nice to be able to do ColdC development on a local box, although you'll want a publically-available server soon, especially if you share the development responsibilities. I've heard various things about Genesis on Win32, I'll let other people address that. Speed won't be a huge issue during development, so your box is probably sufficient for that if it can manage to run, e.g., IE. If you're new to UNIX, and want to take that route, I'd suggest getting an account with a hosting provider who can get you jump-started with Genesis (xidus.net is one such, there are many, kyndig.com and mudconnect.com maintain hosting provider directories) Good luck, and welcome to the fascinating world of run-time mutability... Jeremy Weatherford xidus@xidus.net http://xidus.net On Wed, 4 Sep 2002, Robert Stout wrote: > Hello, > > I came across your website after a seven month-long search for a codebase on > which to build a mud game I am planning. I've reviewed everything from > "PennMush" to "The Dawn of Time" codebases. > > Needless to say it has been worth the wait. I am very excited about the > potential your program offers. > > The bad thing however is I am very new to programming and can see that if I > am going to impliment some of the features I have in mind I've alot to > learn. > > I was wondering if you know of any resources (web articles or books) I could > check out that would help me learn to use ColdC effectively. I *embarassed > to say* don't know C programming (yet). > > I assume knowing C (and/or C++) is a requirement before even considering > building a mud-game on ColdC? > > The game I have in mind is alot like "The Eternal City" style - which runs > on your codebase. > > I don't want to waste your time but I was hoping you could help me.. get > started - point me in the right direction? If not that's ok. > > FYI: I am running an older (1996) computer using Windows 98 :(. But I have > plans to buy a new computer. Should I break-out of windows and join the Unix > community? > > I am deticated, and I will do what I need to do and learn what I need to > learn inorder to get this game online. I just need help with directions, I > can handle the grunt work myself. > > Thank you for your time. I'm hoping to hear back from you. > > Robert - Harken - Haxdeth - Microp > > Signed, > Robert J. Stout > talonthalas@hotmail.com > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > From coldstuff@cold.org Thu Sep 5 06:17:45 2002 From: coldstuff@cold.org (B. Jack) Date: Wed, 04 Sep 2002 22:17:45 -0700 Subject: [Coldstuff] The Cold Software Project Message-ID: >Hello, > >I came across your website after a seven month-long search for a codebase >on which to build a mud game I am planning. I've reviewed everything from >"PennMush" to "The Dawn of Time" codebases. The joy of canned mud servers. They tend to be difficult to upgrade and usually require the server to go down to add any significant new features to a mud. >Needless to say it has been worth the wait. I am very excited about the >potential your program offers. I was in the same boat for a while near the beginning of the year when I was looking for a mud erver system to design Anime Mayhem (http://anime-mayhem.brians-anime.com:8080)h >The bad thing however is I am very new to programming and can see that if I >am going to impliment some of the features I have in mind I've alot to >learn. Learning the basics of C would certainly help. Don't spend much time delving into C++ -- if at all. ColdC really does not do things the way C++ does. >I was wondering if you know of any resources (web articles or books) I >could check out that would help me learn to use ColdC effectively. I >*embarassed to say* don't know C programming (yet). >I assume knowing C (and/or C++) is a requirement before even considering >building a mud-game on ColdC? To build a game in ColdC there are two approaches: (1) use an existing core, such as ColdCore or ColdHell, or (2) build your own custom core. Choosing route one is the best option for someone wishing to run a typical mud. If you have some incredible functionality you need from your mud (such as webserver linked to the game world state, mudmail/email abstraction or things like that) you might need to choose route 2 (or try adding the additional functionality to an existing core). The drawback to choosing number 1 is that, though ColdC is itself well documented, the cores tend not to be. In the worst case you will get one gargantuan textdump to try and figure out. >The game I have in mind is alot like "The Eternal City" style - which runs >on your codebase. Aha! You chose potion #1. Good choice, sir. Unfortunately ColdCore is one of those cores that is very sparsely documented. You will need to spend a LOT of the time figuring out the source if you need to add any significant features. If you can use the in-game logic to create your world then you're cooking with propane, otherwise, time to start sleeping with a printout of the textdump... >FYI: I am running an older (1996) computer using Windows 98 :(. But I have >plans to buy a new computer. Should I break-out of windows and join the >Unix community? I am guessing your overall goal is to have a multiplayer system so you will need a computer with a constant connection to the internet (if you're using a phone-line modem (ie: k56) account - don't try this at home - if you have cable or DSL, proceed :) If you run the server on your own machine your machine will need to be continuously on from this point forward to keep the server running. From what I've heard genesis works in Windows 98 with a few gotchas (which I don't know off hand - there was a whole thread about this at one point in time). You can run the server on your own machine - and it will work - but you will probably find it a pain, especially if you like to use your computer as well (kinda like the having cake and eating it analogy). The first time that rockin new 3D game crashes your Windows 98 box you will start to realize the drawbacks of running the genesis server on the same computer you work with. The recommended approach is to run genesis in one of the unix variants on a separate machine. Another alternative is Windows 98 on a separate machine but if you have a separate machine why not use the best OS for the job (Windows 98 has some cheesy connection limitations on the number of users that will ultimately be able to connect simultaneously)? Once you get going a good place for advice comes from The Cold Dark community which lives at telnet://ice.cold.org:1138 _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From coldstuff@cold.org Thu Sep 5 15:52:06 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Thu, 05 Sep 2002 08:52:06 -0600 Subject: [Coldstuff] The Cold Software Project References: Message-ID: <3D776F96.5040003@roguetrader.com> B. Jack wrote: > > I am guessing your overall goal is to have a multiplayer system so you > will need a computer with a constant connection to the internet (if > you're using a phone-line modem (ie: k56) account - don't try this at > home - if you have cable or DSL, proceed :) If you run the server on > your own machine your machine will need to be continuously on from this > point forward to keep the server running. From what I've heard genesis > works in Windows 98 with a few gotchas (which I don't know off hand - > there was a whole thread about this at one point in time). You can run > the server on your own machine - and it will work - but you will > probably find it a pain, especially if you like to use your computer as > well (kinda like the having cake and eating it analogy). The first time > that rockin new 3D game crashes your Windows 98 box you will start to > realize the drawbacks of running the genesis server on the same computer > you work with. The recommended approach is to run genesis in one of the > unix variants on a separate machine. Another alternative is Windows 98 > on a separate machine but if you have a separate machine why not use the > best OS for the job (Windows 98 has some cheesy connection limitations > on the number of users that will ultimately be able to connect > simultaneously)? My recommendation is to just digup an old pentium 166 and install FreeBSD or Linux on it. That is plenty big for the average cold mud. The original Cold Dark ran on a decstation 5000 with is a 66 MHz MIPS CPU and 12MB RAM (this is why there are still some #ifdeffed out routines in the genesis code for memory cleanup, to reduce the memory footprint... kindof silly nowdays 8) -Brandon Gillespie From coldstuff@cold.org Sun Sep 22 00:03:17 2002 From: coldstuff@cold.org (Jonathan) Date: 21 Sep 2002 16:03:17 -0700 Subject: [Coldstuff] Login Procedure Message-ID: <1032649398.29374.39.camel@jwrtrumpet.attbi.com> Hey, Does anyone know the actual connection process for coldcore-3.0-1999-08-28. I need to know what happens with the connection as soon as the player connects to genesis, to entering "connect ", all the way to dropping them in their "startspot" Any help would be appreciated. I've been digging through connection and connection_interface. Thanks, Jonathan From coldstuff@cold.org Sun Sep 22 01:08:13 2002 From: coldstuff@cold.org (Levi Pearson) Date: Sat, 21 Sep 2002 18:08:13 -0600 Subject: [Coldstuff] Login Procedure In-Reply-To: <1032649398.29374.39.camel@jwrtrumpet.attbi.com> Message-ID: <62CF970A-CDBF-11D6-A074-0005028D7C67@cold.org> On Saturday, September 21, 2002, at 05:03 PM, Jonathan wrote: > Hey, > > Does anyone know the actual connection process for > coldcore-3.0-1999-08-28. I need to know what happens with the > connection as soon as the player connects to genesis, to entering > "connect ", all the way to dropping them in their > "startspot" > > Any help would be appreciated. I've been digging through connection and > connection_interface. > ColdCore sets things up so that the driver calls $login_daemon.connect() when a new connection arrives. $login_daemon passes the connection off to a child of $login_connection, which is associated with a $login_interface. $login_interface has the commands on it that are available at the login screen. When a login is completed, the connection changes its interface association from the $login_interface child, which is cleaned up, to the user object for that user. The .login() method is then called on that user object to set stuff up, unless this is not the first connection to the user object, in which case .login_again() is called. The process is similar, at least in the early stages, for the other types of connections ColdCore supports. Each has a $daemon object which listens for connections and passes them off to $connection objects. Data arriving through a connection is sent into the core by the driver calling the .parse() method on the child of $connection that the connection is associated with. It's parsed into lines, then passed onto the interface object associated with the connection. Hope this was helpful to you. --Levi From coldstuff@cold.org Sun Sep 22 01:31:16 2002 From: coldstuff@cold.org (Jonathan) Date: 21 Sep 2002 17:31:16 -0700 Subject: [Coldstuff] Login Procedure In-Reply-To: <62CF970A-CDBF-11D6-A074-0005028D7C67@cold.org> References: <62CF970A-CDBF-11D6-A074-0005028D7C67@cold.org> Message-ID: <1032654677.29374.51.camel@jwrtrumpet.attbi.com> One other quick question. With that in mind and I haven't looked in the core yet, but is it $login_interface that throws up the banner? The banner being everything before the initial prompt to connect. Currently it says The title of the game, the Administrators, and connected users. I know I've change this before but I can't recall where it is. motd is where the title is changed, but what about the other stuff. Say I want to take off the administrators or show something specific like an announcement. Jonathan On Sat, 2002-09-21 at 17:08, Levi Pearson wrote: > > On Saturday, September 21, 2002, at 05:03 PM, Jonathan wrote: > > > Hey, > > > > Does anyone know the actual connection process for > > coldcore-3.0-1999-08-28. I need to know what happens with the > > connection as soon as the player connects to genesis, to entering > > "connect ", all the way to dropping them in their > > "startspot" > > > > Any help would be appreciated. I've been digging through connection and > > connection_interface. > > > > ColdCore sets things up so that the driver calls $login_daemon.connect() > when a new connection arrives. $login_daemon passes the connection off to > a child of $login_connection, which is associated with a $login_interface. > $login_interface has the commands on it that are available at the login > screen. When a login is completed, the connection changes its interface > association from the $login_interface child, which is cleaned up, to the > user object for that user. The .login() method is then called on that > user object to set stuff up, unless this is not the first connection to > the user object, in which case .login_again() is called. > > The process is similar, at least in the early stages, for the other types > of connections ColdCore supports. Each has a $daemon object which listens > for connections and passes them off to $connection objects. > > Data arriving through a connection is sent into the core by the driver > calling the .parse() method on the child of $connection that the > connection is associated with. It's parsed into lines, then passed onto > the interface object associated with the connection. > > Hope this was helpful to you. > > --Levi > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff From coldstuff@cold.org Sun Sep 22 03:01:53 2002 From: coldstuff@cold.org (Levi Pearson) Date: Sat, 21 Sep 2002 20:01:53 -0600 Subject: [Coldstuff] Login Procedure In-Reply-To: <1032654677.29374.51.camel@jwrtrumpet.attbi.com> Message-ID: <43CB5EF1-CDCF-11D6-A074-0005028D7C67@cold.org> On Saturday, September 21, 2002, at 06:31 PM, Jonathan wrote: > One other quick question. With that in mind and I haven't looked in the > core yet, but is it $login_interface that throws up the banner? The > banner being everything before the initial prompt to connect. Currently > it says The title of the game, the Administrators, and connected users. > I know I've change this before but I can't recall where it is. motd is > where the title is changed, but what about the other stuff. Say I want > to take off the administrators or show something specific like an > announcement. > > Jonathan > $login_interface has a .motd() method which calls $motd.build() with args from the login-sequence @setting on $motd. So check out the code on $motd.build() and how it responds to its arguments, then set login-sequence appropriately for what you want. This stuff is easy to find with a quick look at the code. @display and @l ist are your friends. It's easier and faster to look them up yourself than to ask here, once you get the hang of it. --Levi From coldstuff@cold.org Tue Sep 24 20:07:06 2002 From: coldstuff@cold.org (coldstuff@cold.org) Date: Tue, 24 Sep 2002 12:07:06 -0700 (PDT) Subject: [Coldstuff] caller() vs calling_method() Message-ID: <20020924120707.13019.h009.c000.wm@mail.mudge.com.criticalpath.net> There is an inconsistency between caller() and calling_method(); after a pass() operation, calling_method() returns the pass()ing method, while caller() returns what the caller was before the pass(). It makes permission-checking very difficult, as I can't simply check caller().method_permissions(calling_method()). I understand that calling_method() reads the stack, where caller() reads from some frame information, which may be difficult to make changes to... Is there any possibility of getting it fixed? - Kipp From coldstuff@cold.org Tue Sep 24 20:14:25 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Tue, 24 Sep 2002 13:14:25 -0600 Subject: [Coldstuff] caller() vs calling_method() References: <20020924120707.13019.h009.c000.wm@mail.mudge.com.criticalpath.net> Message-ID: <3D90B991.5090807@roguetrader.com> michael@mudge.com wrote: > There is an inconsistency between caller() and calling_method(); after a > pass() operation, calling_method() returns the pass()ing method, while > caller() returns what the caller was before the pass(). It makes > permission-checking very difficult, as I can't simply check > caller().method_permissions(calling_method()). > > I understand that calling_method() reads the stack, where caller() reads from > some frame information, which may be difficult to make changes to... Is there > any possibility of getting it fixed? Kipp, weren't you the author of calling_method? I don't recall who wrote calling_method, but it is the new addition. -Brandon From coldstuff@cold.org Tue Sep 24 20:25:41 2002 From: coldstuff@cold.org (Bruce Mitchener) Date: Tue, 24 Sep 2002 13:25:41 -0600 Subject: [Coldstuff] caller() vs calling_method() References: <20020924120707.13019.h009.c000.wm@mail.mudge.com.criticalpath.net> <3D90B991.5090807@roguetrader.com> Message-ID: <3D90BC35.3030101@cubik.org> Brandon Gillespie wrote: > michael@mudge.com wrote: > >> There is an inconsistency between caller() and calling_method(); after a >> pass() operation, calling_method() returns the pass()ing method, while >> caller() returns what the caller was before the pass(). It makes >> permission-checking very difficult, as I can't simply check >> caller().method_permissions(calling_method()). >> >> I understand that calling_method() reads the stack, where caller() >> reads from >> some frame information, which may be difficult to make changes to... >> Is there >> any possibility of getting it fixed? > > Kipp, weren't you the author of calling_method? I don't recall who > wrote calling_method, but it is the new addition. He was and I'd guess that no else uses it. Fixes from Kipp are welcome. - Bruce From coldstuff@cold.org Wed Sep 25 01:39:27 2002 From: coldstuff@cold.org (coldstuff@cold.org) Date: Tue, 24 Sep 2002 17:39:27 -0700 (PDT) Subject: [Coldstuff] caller() vs calling_method() Message-ID: <20020924173928.22882.h012.c000.wm@mail.mudge.com.criticalpath.net> On Tue, 24 September 2002, Brandon Gillespie wrote: > Kipp, weren't you the author of calling_method? I don't recall who > wrote calling_method, but it is the new addition. Oh, heh heh... I suppose I sort of was. I'm sure this came from somewhere else (Psyclone) and I submitted it, as I don't really have any C-coding skills. :) As usual, it is just a matter of scratching my head and asking questions over the code until I get enough help to do it. If this isn't so complicated, I would appreciate suggestions. If I come up with a solution, I'll post it of course. - Kipp From coldstuff@cold.org Mon Sep 30 06:31:38 2002 From: coldstuff@cold.org (B. Jack) Date: Sun, 29 Sep 2002 22:31:38 -0700 Subject: [Coldstuff] Textdump format Message-ID: This is a request for the coldcc author(s) (or know(s) the entire answer to the question - which follows): What are all the recognized keywords, their syntaxes and context within a textdump? I'd like to finally do somethng about that empty "Textdump Structure" node that has been empty since the inception of coldc/genesis, or at least have the knowledge available to those who might do coldc documentation as I don't think I have access to change it on TCD proper. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From coldstuff@cold.org Mon Sep 30 16:48:33 2002 From: coldstuff@cold.org (coldstuff@cold.org) Date: Mon, 30 Sep 2002 08:48:33 -0700 (PDT) Subject: [Coldstuff] Textdump format Message-ID: <20020930084840.13901.h004.c000.wm@mail.mudge.com.criticalpath.net> I've written several textdumps... there are only about five statements. Here's a quick summary: The textdump is a series of statements, each ending with a semicolon. They can be broken into multiple lines in the same way ColdC methods can. Running coldcc with the -# argument causes decompile to always use objrefs, otherwise coldcc uses objnums combined with the 'name' statement. [new ]object [: ]; - If 'new' is specified, creates the object. - Selects the object as the current object. - Parents is a comma-separated list of objnums/objrefs. - $root and $sys already exist (#1 and #0). Do not use the 'new' clause for these. - Do not define parents for $root. name ; - Assigns an objref to an objnum. - $root and $sys are already named, do not use on $root and $sys. - This is only necessary if the object line used an objnum instead of an objref. var = ; - If definer is the same as the current object, adds a variable to that object and gives it the specified value. - If definer is an ancestor that defines such a varaible, this gives the variable owned by the definer the given value for this child. - If neither of the above two are true, the line is ignored. [ ]method [].[()][: ] code; - Defines a method. See the ColdC reference manual for the meaning of 'access' and 'flags'. - Flags is a comma-separated list. - 'Code' should be within a statement block. Example: public method .foo() { return bar; }; eval code; - Immediately executes code on the current object. - Not sure if there are any other options to this one... Email if you have more questions. - Kipp On Sun, 29 September 2002, "B. Jack" wrote: > > > This is a request for the coldcc author(s) (or know(s) the entire answer > to the question - which follows): > > What are all the recognized keywords, their syntaxes and context within a > textdump? From coldstuff@cold.org Mon Sep 30 16:58:12 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Mon, 30 Sep 2002 09:58:12 -0600 Subject: [Coldstuff] Textdump format References: <20020930084840.13901.h004.c000.wm@mail.mudge.com.criticalpath.net> Message-ID: <3D987494.40602@roguetrader.com> michael@mudge.com wrote: > I've written several textdumps... there are only about five statements. > Here's a quick summary: > > The textdump is a series of statements, each ending with a semicolon. They > can be broken into multiple lines in the same way ColdC methods can. Actually, only methods can have a line break as white text. Any other line must use a backslash to 'escape' the line break. > Running coldcc with the -# argument causes decompile to always use objrefs, > otherwise coldcc uses objnums combined with the 'name' statement. > > [new ]object [: ]; > - If 'new' is specified, creates the object. > - Selects the object as the current object. > - Parents is a comma-separated list of objnums/objrefs. > - $root and $sys already exist (#1 and #0). Do not use the 'new' clause for > these. > - Do not define parents for $root. > > name ; > - Assigns an objref to an objnum. > - $root and $sys are already named, do not use on $root and $sys. > - This is only necessary if the object line used an objnum instead of an > objref. > > var = ; > - If definer is the same as the current object, adds a variable to that > object and gives it the specified value. > - If definer is an ancestor that defines such a varaible, this gives the > variable owned by the definer the given value for this child. > - If neither of the above two are true, the line is ignored. > > [ ]method [].[()][: ] code; > - Defines a method. See the ColdC reference manual for the meaning of > 'access' and 'flags'. > - Flags is a comma-separated list. > - 'Code' should be within a statement block. > Example: > public method .foo() { > return bar; > }; > > eval code; > - Immediately executes code on the current object. > - Not sure if there are any other options to this one... > There is also the non-intiutive 'old' token which can be used where you would normally use 'new'. Old will remove the following object, method, variable. This is useful when running coldcc on a database in patch mode (-p). When running in patch mode it opens an existing db (DO NOT HAVE GENESIS RUNNING) and you can mangle it using the textdump format (and evals). At one point in time I had planned on using this to do core upgrades. -Brandon