From crossfire-request Wed Jun 28 23:42:28 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 28 Jun 1995 23:42:24 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id RAA29528; Wed, 28 Jun 1995 17:42:05 -0400 Date: Wed, 28 Jun 1995 17:42:05 -0400 From: Brian Thomas Message-Id: <199506282142.RAA29528@chaupher.gsfc.nasa.gov> To: woodruff@Cadence.COM Subject: Re: Race before rolling Cc: crossfire@ifi.uio.no Status: RO Hi, This is from a discussion on character generation I had with Ken, but its probably of great enough interest for group posting. b.t. > > [brian discusses the order of race,stat,profession selection] > > > I take that back, sortof. Probably the most desirable thing > > would be to be able to reroll your stats, repick your > > profession, and rechoose your race at *any* point in character > > generations. Thus the formal order could be 1) stat gen > > 2) race choice 3) prof choice. But you could skip to any > > point you like during the process. > > [ken responds] > > Since CF allows you to roll as many times as you like I think > that most people start with a goal profession in mind and then > keep rolling until they get appropriate stats. (Actually with > the new stat-swapping code they just roll until they get the > highest plausible stat total.) By choosing race first you > will be able to instantly see as you roll what your final > stats will be without having to do the mental calculations of > race based stat bonuses, thus achieving your desired stats will > be quicker. > > I personally think that the whole rolling system should be eliminated > and you should just start with perfectly average stats for your race plus > a pool of stat points (maybe slightly randomized for variation) which > you can use to increase your various stats as you see fit. You could > also move stat points around by decreasing a stat, which would return > points to the pool. > > As you adjust your stats a list of the professions available > to you based on your race and current stats would be shown. Choosing > a profession would mark the end of the process. Unused stat > points remaining in your pool could be converted to gold or > some other reward (+ on your main weapon perhaps). > > --Ken > From crossfire-request Wed Jun 28 20:31:11 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 28 Jun 1995 20:29:57 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id OAA29348; Wed, 28 Jun 1995 14:29:36 -0400 Date: Wed, 28 Jun 1995 14:29:36 -0400 From: Brian Thomas Message-Id: <199506281829.OAA29348@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: A proposal for CF Cc: thomas@chaupher.gsfc.nasa.gov Status: RO Hi all, Here is a more substantial proposal for new exp/race/skill/etc. system in CF. I fleshed most of this out with Peter and from comments on the mailing list. I know I probably don't need to say it, but 'comments anyone?' :) --b.t. ***************************************************** PROPOSAL for a New EXPERIENCE/SKILL/RACE system in CF: ***************************************************** Summary ======= In essence, a new system of experience is proposed. Under this proposal several kinds of experience (nominally known as 'experience catagories') can now be gained by the player. Each experience catagory will have skills associated with it, and experience will be gained by use of associated skills. Race and profession will be now be split apart as will the magic system into 'mage' and 'clerical' powers. (Most of) this system will be an option for play. (Short) list of specific important changes ========================================== Here is a list of things that are recommended to be changed. I have tried to break the changes up into related chunks : Part A - Race and Profession -------- A1 - Separate player choices of race and profession. A2 - Player image will be set by profession (all the bitmaps are already made!!), later the player will be able to choose any available image. A3 - Both race and profession may set flags. For example, characters who are either 'fireborn' or 'monk' will have the 'no weapons' flag set. Part B - Multiple experience catagories -------- B1 - Multiple catagories in which a player may gain experience. Type and amount will be viewable by the player. The naming and number of catagories will be configurable. One possible implementation is for each experience catagory to be treated as an (invisible) object in player inventory. Configuring the alignment of associated skills and the number of experience catagories could be done with the use of an ascii file--'skills_param' similar in scope to the 'spells_param' file. B2 - Experience gained will be tunable. One way to easily do this is through a single multi-purpose function add_experience(). B3 - Each experience catagory will have an associated stat(s)- (eg Str, Int, Wis, etc). As an option, the amount of experience gained by a player will be influenced by the value of relevant stat(s) they possess. B4 - Wc, hp and dam will become related to the appropriate experience catagory(s) at start. For hp, I expect to relate it to the sum of all experience. For dam, wc an equitable means of relating wc, dam to appropriate associated skills may later be devised. B5 - Lost experience will be subtracted and divided amoungst all exp catagories *which are non-zero* equally. Part C - Skills -------- C1 - Two kinds of skills will be available: "associated" skills which are associated with an experience catagory and "miscellaneous" skills which will not be associated with any experience catagory. *C2 - Skills will be objects in the character inventory. These objects may either be invisible or may be 'tools' with represenative bitmaps. Loss of a 'tool' means the player looses the ability to use the skill embedded in the tool. 'Lockpicks' are an example of a skill 'tool'. C3 - experience will be now only be gained through the use of skills associated to one of the catagories of experience. *C4 - Both NPC and players will be able to use skills. *C5 - Players will be able to learn skills by reading scrolls of knowledge ('skillscrolls'). Current implementation will allow players to buy scrolls in shops, but later, maps may be made to allow the creation of a 'guild' system whereby skillscrolls are acquired (and shops phased out...). *already implemented in the skills code. Part D - Magic system -------- D1 - Clerical and Magical power and spells will be sundered. "grace" and "mana" will come into use for the number of "spellpoints" available for the player to cast "magic" spells and clerical prayers. D2 - A new player stat will come into exsistence - "power". This stat will control the amount of magical power (both grace and mana ?) a player has. D3 - Use of Int and Wis will change. Possibly, Int will set the likely hood of a player learning magic spells, and Wis will set the likelyhood of a player learning new prayers. Strategy for coding - brief synopsis ==================================== I suppose many different ways exist to approach this. My plan is to finish objectives in catagory 'C' first. Creation of the 'power' stat and experience objects should come next. After the new experience system is up and running, the magic system should be altered. Once those steps are in place the experience system can be playtested and 'tuned'. Because the stuff in part 'A' is relatively independant of the other things, profession and race may be hacked at any point. I currently forsee most of parts 'B' and 'C' as being configurable, and made as an option for crossfire play. Parts 'A' and 'D' seem to be difficult to code as options and will be permanent changes to CF unless someone cleverer than me knows a good way to do it. From crossfire-request Wed Jun 28 15:41:13 1995 Return-Path: Received: from sps1.phys.vt.edu (sps1.phys.vt.edu [128.173.176.53]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 28 Jun 1995 15:41:08 +0200 Received: (from martinm@localhost) by sps1.phys.vt.edu (8.6.9/8.6.9) id JAA08317 for crossfire@ifi.uio.no; Wed, 28 Jun 1995 09:40:47 -0400 From: "Michael B. Martin" Message-Id: <199506281340.JAA08317@sps1.phys.vt.edu> Subject: Re: Merged proposal To: crossfire@ifi.uio.no Date: Wed, 28 Jun 1995 09:40:47 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 429 Status: RO Brian wrote: > > How the proposed system are going to give more hps? > > My thought is that the total running experience of the character > be used for this. Total running experience == sum of all > experience in the 'experience catagories'. Ok, but what happens if you die? How are the lost experience points removed? Equally from all categories? Or would you rather make death have different consequences? -Michael From crossfire-request Wed Jun 28 01:40:33 1995 Return-Path: Received: from bach.seattleu.edu (root@bach.seattleu.edu [199.237.224.11]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 28 Jun 1995 01:40:27 +0200 Received: by bach.seattleu.edu (4.1/SMI-4.1) id AA09138; Tue, 27 Jun 95 14:54:37 PDT Date: Tue, 27 Jun 1995 14:54:05 -0700 (PDT) From: "Kristofer M. Bosland" Subject: Re: Merged Merged proposal? To: Brian Thomas Cc: crossfire@ifi.uio.no, woodruff@cadence.com In-Reply-To: <199506271823.OAA28897@chaupher.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 27 Jun 1995, Brian Thomas wrote: > > > > Ken writes: > > > > - Players who choose a profession have access to the "Experience Point > > Economy" as previously described by me, et.al. > ^^^^^^^ > > > - Players who do not choose a profession are considered "you are what you > > do" (generalists?) > ^^^^^^^^^^^^^^ > > Hee hee. Generalists vs. Economists :) Time to form parties an > cross sabers lads! > > b.t. > I'm a Whig! -Kris Bosland krisb@seattleu.edu From crossfire-request Tue Jun 27 22:44:20 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 22:43:54 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id NAA05115 for ; Tue, 27 Jun 1995 13:43:26 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma005049; Tue Jun 27 13:43:02 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA00767; Tue, 27 Jun 95 13:42:55 -0700 Received: by pluto (5.65+/1.5) id AA24144; Tue, 27 Jun 95 16:42:59 -0400 Date: Tue, 27 Jun 95 16:42:59 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506272042.AA24144@pluto> To: crossfire@ifi.uio.no Subject: Skills as inventory items (Re: Merged proposal) Status: RO Tero (> >) and Brian (>) write: > > [...] memory requiments have to considered. If > > they are handled as invisible inventory objects then it slows both the > > normal inventory handling and skill handling code. Since each skill > > needs only about 16 bytes memory it also wastes memory. The simple and > > efficient method is make a pointer to a skill table or a pointer to table > > of skills pointers. This would need some own code for skills and looses > > flexibility that object only solution offers, but also removes many > > other problems, IMHO > > Yeah. I have thought about creating a separate structure for skills, > and having a pointer to a linked list of skills in the object > structure (so players and monsters can both use). Would improve > speed and memory, but coding such a thing takes time [...] How about a skills container object? Make this always the first item in the inventory and it's easy to navigate to, and skipping over one item is going to be faster than skipping the possible multitude of skills that would otherwise clog an inventory list. I don't think you'd have to do much work, since you can already customize containers to limit the sorts of things which they contain. --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Tue Jun 27 20:28:51 1995 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 20:28:51 +0200 Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by maud.ifi.uio.no ; Tue, 27 Jun 1995 20:28:38 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id OAA28897; Tue, 27 Jun 1995 14:23:28 -0400 Date: Tue, 27 Jun 1995 14:23:28 -0400 From: Brian Thomas Message-Id: <199506271823.OAA28897@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no, woodruff@cadence.com Subject: Re: Merged Merged proposal? Status: RO > Ken writes: > > - Players who choose a profession have access to the "Experience Point > Economy" as previously described by me, et.al. ^^^^^^^ > - Players who do not choose a profession are considered "you are what you > do" (generalists?) ^^^^^^^^^^^^^^ Hee hee. Generalists vs. Economists :) Time to form parties an cross sabers lads! b.t. From crossfire-request Tue Jun 27 21:04:38 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 21:04:34 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id OAA28891; Tue, 27 Jun 1995 14:19:05 -0400 Date: Tue, 27 Jun 1995 14:19:05 -0400 From: Brian Thomas Message-Id: <199506271819.OAA28891@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no, Tero.Haatanen@tel.vtt.fi Subject: Re: Merged proposal Cc: thomas@chaupher.gsfc.nasa.gov Status: RO Hi again, Several people have been wondering about how the skills are currently implemented, and where they might be going :).. > Tero writes : > >[skill implementation] > > Since skills don't need many attributes (name, type, how hard learn, how > good player is with that skill, level, exp, ...), the easiest way is Skills may also change dam, ac, wc, armour, and weapon speed of the user too. > make them as archetypes. How they are handled internal is a different > thing. The most important question is that does NPC have same skills as > players? Yes. I have no plans to make separate player and monster "skills". > If they have then memory requiments have to considered. If > they are handled as invisible inventory objects then it slows both the > normal inventory handling and skill handling code. Since each skill > needs only about 16 bytes memory it also wastes memory. Well, in the long run you are right (perhaps). Both the number of available skills will have to grow larger (currently 23 skills) and skill use by monsters will have to become incredibly commonplace. Also, current implementation does not allow any monster ('NPC') to use more than one skill; it would be pointless therefore to make monsters with a huge spectrum of skills (currently). Anyway, monsters already carry a host of 'objects' in their inventory already - books, weapons, abilities, etc... Skills are just the latest monster 'accessory' ;) > needs only about 16 bytes memory it also wastes memory. The simple and > efficient method is make a pointer to a skill table or a pointer to table > of skills pointers. This would need some own code for skills and looses > flexibility that object only solution offers, but also removes many > other problems, IMHO Yeah. I have thought about creating a separate structure for skills, and having a pointer to a linked list of skills in the object structure (so players and monsters can both use). Would improve speed and memory, but coding such a thing takes time, and loses some of the 'generality',flexibility, and simplisity I treasure :). When skills start hogging memory and CPU, then perhaps I will be more motivated :) Really, this discussion is leading towards cleaning up the object structure, which (to me) seems to have some redundancy in it and could use some 'pruning'. > ["associated" and "miscellaneous" skills] > > But aren't these same, "miscellaneous" skill is just "associated" skill > that have attribute which tells it gives 0 exp. points when used ? > Or a "miscellaneous" catecory is just like other 4/6 categories, but > experience is always ignored. The main differences between the "associated" and "miscellaneous" skills are: - associated skills are associated with a catagory of experience - associtated skills have 'graduated effectiveness', ie the higher you progress in level, the more effective the skill. Only the 'assocated' experience catagory will be used to determine the skill effectiveness. - successfull use of the associated skills will generate experience for the character. Experience generated by a given skill will be added only to the experience catagory the skill is associated with. - none of the above statements are true for miscellaneous skills. > Could Brian or Peter present a little more detailed proposition? Yes. I am working on one. > I'm confused what you are really doing with experience. The latest > proposition seems to be that there are 4/6 skill categories that > have level and experience. The "associated" skills are binded to > these categories. There is envisioned a flexible number of experience catagories to be available. Associated skills are bound to one of the possible catagories. Short of a redirection by the maintainer, the default bindings will be used. (changes in binding will be made through an ascii files like 'skills_param' similar to the 'spells_param' file) > Is these categories implemented as inventory objects or only the skills? Not completely determined yet :) I have reasently become enamoured with creating experience 'objects'. That is to say each experience catagory will be an invisible object in the player inventory. This is primarily Peter's idea, but I like it--it would allow alot of flexibility. > How the proposed system are going to give more hps? My thought is that the total running experience of the character be used for this. Total running experience == sum of all experience in the 'experience catagories'. > I assume that mana and grace depends on magical and clerical experience, > right? Yes, that is the plan. > How new skills can be learned? Buy a scroll of knowledge (or 'skillscroll'). This is allows later adoption of 'guilds' where the appropriate 'skillscrolls' may be found. Right now, skillscrolls are available randomly in the shops. > Also is there limitations how good or easily player can learn > these skills? Right now, no. Perhaps in the future-but it would'nt be a feature I would like to see implemented. b.t. From crossfire-request Tue Jun 27 19:15:06 1995 Return-Path: Received: from bham.ac.uk (bham.ac.uk [147.188.128.127]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 19:15:04 +0200 Received: from np.ph.bham.ac.uk by bham.ac.uk with SMTP (PP); Tue, 27 Jun 1995 18:14:11 +0100 Received: from nps4 by np.ph.bham.ac.uk (5.x/BHAM-SVR4) id AA17307; Tue, 27 Jun 1995 18:12:43 +0100 Received: by nps4 (5.x/SMI-SVR4) id AA04188; Tue, 27 Jun 1995 18:11:58 +0100 Date: Tue, 27 Jun 1995 18:11:58 +0100 From: Alex Murphy Message-Id: <9506271711.AA04188@nps4> X-Sun-Charset: US-ASCII To: crossfire@ifi.uio.no Status: RO UNSUBSCRIBE From crossfire-request Tue Jun 27 18:25:50 1995 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 18:25:50 +0200 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by maud.ifi.uio.no ; Tue, 27 Jun 1995 18:25:34 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA25794 for ; Tue, 27 Jun 1995 09:00:11 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma025704; Tue Jun 27 08:59:54 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA15549; Tue, 27 Jun 95 08:59:50 -0700 Received: by pluto (5.65+/1.5) id AA22251; Tue, 27 Jun 95 11:59:51 -0400 Date: Tue, 27 Jun 95 11:59:51 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506271559.AA22251@pluto> To: crossfire@ifi.uio.no Subject: Merged Merged proposal? Status: RO Peter writes: > if you want to add your Experience Point Economy after skills > are installed you can. > [...] > In order to control level of skill in this way, all you have to do > is have the guild do this, too, and remove the level-advancement > code from wherever b.t. et. all put it and put it under control of your > guilds. > > But for chrissake, if you do this, please #ifdef it. Perhaps it's possible to support both play styles in a single server? How about this: - A player, when they begin the game, may choose a profession, but they don't have to. - Players who choose a profession have access to the "Experience Point Economy" as previously described by me, et.al. - Players who do not choose a profession are considered "you are what you do" (generalists?) and their skills are refined not by spending EP in a guild but by the "successful use increases proficiency" model described by Peter, et.al. Ultimately a system for acquiring and abdicating membership in the various guilds could be devised to allow players to try both styles of play with a single character. --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Tue Jun 27 13:37:44 1995 Return-Path: Received: from rulway.LeidenUniv.nl (rulway.LeidenUniv.nl [132.229.8.6]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 13:36:58 +0200 Received: from rulglj.LeidenUniv.nl by rulway.LeidenUniv.nl with SMTP id AA01112 (5.65c+/IDA-1.4.4 for <@RULWAY.LEIDENUNIV.NL:crossfire@ifi.uio.no>); Tue, 27 Jun 1995 13:33:01 +0200 Received: by rulglj.leidenuniv.nl (920330.SGI/920502.SGI) for @RULWAY.LEIDENUNIV.NL:woodruff@cadence.com id AA18156; Tue, 27 Jun 95 13:36:29 +0200 Date: Tue, 27 Jun 95 13:36:29 +0200 From: frits@rulglj.leidenuniv.nl (Frits Daalmans) Message-Id: <9506271136.AA18156@rulglj.leidenuniv.nl> To: woodruff@cadence.com (Ken Woodruff) Subject: Re: Experience as "currency" (Re: Merged proposal) Cc: crossfire@ifi.uio.no Status: RO Your ideas on having a hierarchical system of skills/spells reminds me of what glimpse i saw of the spell system of DikuMud II; I believe their manuals/documentation are free to browse, ftp to ftp.stacken.kth.se, directory pub/mud/dikuii/docs maybe it is of interest to the Crossfire developers to take a look at how they did it. Greetings, Frits Frits Daalmans OIO Conformational Analysis Gorlaeus Laboratoria Leiden, The Netherlands E-mail: frits@rulglj.leidenuniv.nl Tel: [+31] (0)71-274505 From crossfire-request Tue Jun 27 12:35:50 1995 Return-Path: Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 12:35:49 +0200 Received: (from hat@localhost) by tel1.tte.vtt.fi (8.6.11/8.6.11) id NAA19409 for crossfire@ifi.uio.no; Tue, 27 Jun 1995 13:35:18 +0300 From: Tero Haatanen Message-Id: <199506271035.NAA19409@tel1.tte.vtt.fi> Subject: Re: Merged proposal To: crossfire@ifi.uio.no Date: Tue, 27 Jun 1995 13:35:17 +0300 (EETDST) In-Reply-To: <199506241806.OAA27107@chaupher.gsfc.nasa.gov> from "Brian Thomas" at Jun 24, 95 02:06:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3219 Status: RO Here are some my comments about presented ideas. It repeats probably little too much, but since there are so many ideas and the same ideas are called with different names, it hopefully makes clear what I talk about. [Player bitmaps] The one solution would be that each race (and/or profession) would have a pool bitmaps where player could choose what to use. This would be a simple and flexible solution. And human can't look like a wraith :). And if player wants to more customized bitmap, the server god could add it to server side, so the control is still server's side. [add_player_experience()] It's a good idea, but hopefully prototype is thought before implementation. The killer and killed needs to be objects but is there objects for every possible ways to gain experience? Also the function itself should be implemented so that it wont be another mega function, there are already too many of them :( [skill implementation] Since skills don't need many attributes (name, type, how hard learn, how good player is with that skill, level, exp, ...), the easiest way is make them as archetypes. How they are handled internal is a different thing. The most important question is that does NPC have same skills as players? If they have then memory requiments have to considered. If they are handled as invisible inventory objects then it slows both the normal inventory handling and skill handling code. Since each skill needs only about 16 bytes memory it also wastes memory. The simple and efficient method is make a pointer to a skill table or a pointer to table of skills pointers. This would need some own code for skills and looses flexibility that object only solution offers, but also removes many other problems, IMHO. ["associated" and "miscellaneous" skills] But aren't these same, "miscellaneous" skill is just "associated" skill that have attribute which tells it gives 0 exp. points when used ? Or a "miscellaneous" catecory is just like other 4/6 categories, but experience is always ignored. [Experience categories / hp / wc] Could Brian or Peter present a little more detailed proposition? I'm confused what you are really doing with experience. The latest proposition seems to be that there are 4/6 skill categories that have level and experience. The "associated" skills are binded to these categories. Is these categories implemented as inventory objects or only the skills? How the proposed system are going to give more hps? If it based only for fighting experience then it wizard has very hard to advance. I assume that mana and grace depends on magical and clerical experience, right? Where these categories' exp/level are really used for? How new skills can be learned? Also is there limitations how good or easily player can learn these skills? [Experience as "currency"] I'd like Ken's idea (maybe because have same kind system in my mind :) Peter said that it would require guilds but I have disagree (of course they could be used). The specialization don't prevent a single player games, but make them more interesting, IMHO. [Score] I think it can be dropped, since even now highscore list only tells high level players in the game. -Tero From crossfire-request Tue Jun 27 01:57:00 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 01:56:46 +0200 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id QAA20478; Mon, 26 Jun 1995 16:56:18 -0700 Message-Id: <199506262356.QAA20478@soda.CSUA.Berkeley.EDU> To: "Kristofer M. Bosland" cc: Ken Woodruff , crossfire@ifi.uio.no Subject: Re: Experience as "currency" (Re: Merged proposal) In-reply-to: Your message of "Mon, 26 Jun 1995 13:16:23 PDT." Date: Mon, 26 Jun 1995 16:56:16 -0700 From: Peter Mardahl Status: RO In message , "Kristofer M. Bosland" writes: > > > I am very much for an Experience Point Economy. A minus is that >it can greatly incease the time for some aspects of play, but I feel that >this is balanced by the enjoyment of "detailing" your character. I think Look. All this arguing can go on forever. But let me say this: if you want to add your Experience Point Economy after skills are installed you can. It is even straightforward. Experience points are being collected anyway, into whatever category. All you need to do is make your guild or whatever and have it give the player a way of changing one type of experience to another. In order to control level of skill in this way, all you have to do is have the guild do this, too, and remove the level-advancement code from wherever b.t. et. all put it and put it under control of your guilds. But for chrissake, if you do this, please #ifdef it. What b.t. has proposed is flexible enough to support everyone's dream. I can easily modify his 6-skills system into my 4-skills system at my own server. (Or his 2-skills system if he chooses to implement something simple at the start. b.t., please take note and have your implementation be flexible enough: editing the skill_arches should do most of the work toward setting up whatever system.) Let's take b.t.'s road for a while, since it is going the direction that all of us seem to want to go. Regards, PeterM From crossfire-request Tue Jun 27 00:23:35 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 00:23:30 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id SAA28430 for crossfire@ifi.uio.no; Mon, 26 Jun 1995 18:23:16 -0400 Date: Mon, 26 Jun 1995 18:23:16 -0400 From: Brian Thomas Message-Id: <199506262223.SAA28430@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: Re: Experience as "currency" (Re: Merged proposal) Status: RO Ken writes: > > Wow--conciliation and compromise. A Crossfire first? > Not so fast!! :) > > I don't see any real motivation for moving beyond the four basic classes, and > Hmm. Looks like time to do some "motivating" :) I have several good reasons for wanting something besides the "four basic classes". To briefly review, as currently hashed out (within my understanding) we have been talking about a new experience/race/skills system which will feature: - separate player choices of race and profession. - multiple catagories in which a player may gain experience. - Two kinds of skills will be available: "associated" skills which are associated with a catagory of experience and "unassociated" or "miscellaneous" skills which will not be associated with any experience catagory. - experience will be now only be gained through the use of skills associated to one of the catagories of experience. Currently, there has been some talk of 4 or more catagories of experience. Under a proposal by Peter, 4 catagories of experience would exist: cleric/fighter/magic/thief. It is not the number of catagories, but rather the naming which lies at the heart of my disagreement with this scheme. Why does it matter? The most important reasons are: 1) How to associate skills to the catagories. What about skills which are not related to cleric/fighter/magician/thief experience but should have a graduated effectiveness? For example, "bargaining". In which of the aforementioned 4 does it fit with? Adoption of "profession" names for each of the experience catagories will constrict the creativity with which new skills may be created. 2) Ecstetics. The creation of non-thief/fighter/magician/cleric/ characters will be impossible. Remember that this system is saying all character professions are a 'blend' of the available experience catagories. Creating professions from a blend of professions irks me too. With all due respects, this naming scheme is not very parsimonious (or elegant). What are the options? Well, I'm sure that there are a million ways to name kinds of experience available to a player. The point is to find names which will not lead to further degrees of freedom (if possible). What are the current independant measures of a CF character? I can think of 7; We describe a character by 6 "fundimental" stats: Str, Dex, Con, Int, Wis, Cha. and "experience". With the inclusion of spells, skills and possessions you may completely describe any character that can be generated in CF (I am of course omitting trival aspects like character name and title). Notice! none of the mentioned ways of "characterizing" has *anything to do with profession*! Why not choose to relate the experience catagories to one (or more) of the independant measures which already exist? For example, an alternative choice (which I advocate) is to relate the experience catagories to the "stats". This seems to be a more "natural" way. Ken has raised a good critism of this. > I'm not particularly compelled by assigning skills to particular stats. A typical > skill is dependant on several stats, e.g. lockpicking should be a factor of > dexterity for the physical aspect of jiggling the tools around, intelligence, > to figure out the intricacies of this particular lock, and wisdom, for how many > similar locks you've seen before. Skills (in real life) are certainly a mixture of many things. But in a game we cannot hope to simulate reality nor would I believe CF to be a very fun game if it did. Remember we have already done this in so many ways. Why have only 6 fundemental stats?? Why not 100 or a 1000? The reason is that it would be a nightmare to keep track of so many stats. Thus, I feel it is ok to simplify the relationship between the stats and the skills. You have to "make the cut" somewhere. As always, the implacable :), b.t. From crossfire-request Mon Jun 26 23:31:01 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 26 Jun 1995 23:30:53 +0200 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id OAA06139; Mon, 26 Jun 1995 14:30:32 -0700 Message-Id: <199506262130.OAA06139@soda.CSUA.Berkeley.EDU> To: woodruff@cadence.com (Ken Woodruff) cc: crossfire@ifi.uio.no Subject: Re: Experience as "currency" (Re: Merged proposal) In-reply-to: Your message of "Mon, 26 Jun 1995 12:16:25 EDT." <9506261616.AA21374@pluto> Date: Mon, 26 Jun 1995 14:30:31 -0700 From: Peter Mardahl Status: RO In message <9506261616.AA21374@pluto>, Ken Woodruff writes: > >Wow--conciliation and compromise. A Crossfire first? I've never felt anyone was unreasonable. Consensus can be pretty hard to build when so many people have different visions for the game. Having said that I'm going to object to your ideas below: >skills/classes/levels, etc. What if we considered experience not as an ever >increasing number but rather as a kind of currency which you accumulate by >adventuring and then "spend" (in a guild or similar place) to learn new skills We've seen this proposal before. So you've seen my arguments against it before. Nevertheless, I'll rehash those: 1) This requires the addition of guilds and requires maps with guilds. More work for implementation, more things to go wrong, and more things that any new world-maker would *have* to put in, to have a viable mapset. 2) It doesn't make sense to me to go kill monsters with fireballs and use the "experience" gained from this to "purchase" skills in say, levitation. Yet this is exactly what would happen. Either practicing fireballs automatically helped you become a better spellcaster or not. >or refine existing ones. This would allow players to have more flexibility in >developing their characters and would also free the code from analyzing every 3) Players already would have this flexibility. If they want a player to have a skill they practice it. They can tailor as much as they want. Furthermore, they wouldn't have the extra trips, bookkeeping and general hassle of having to go find guilds. > - Allow for transferrence of experience from one category to > another with some penalty, e.g. Physical EP could be spent for Subtlety s > at a cost of 3x the Subtlety cost. I really hate this idea. First, you'd need to build all the infrastructure needed to "buy" skills. THEN you have this weird thing where you can advance in your magery by having beaten up lots of kobolds with your +2 club. > - Add an actual cost (gold pieces) to certain skills in addition to the > experience cost. Again profession could have a multiplier effect here. > (So could charisma?) Yuck! Now you can sell things to advance in exp too? *sigh* > - Skills can have prerequisites, which can be levels (i.e. you must be at l > third level to learn this skill), or other skills (e.g. you must know how > make fire and levitate objects before you can throw fireballs) Having prerequisites for skills is a decent idea, but it is a frill which can be safely left for later. > - Fundamental skills (ones which serve as prerequisites to many other skill > could be given a much higher price to encourage specialization. (a simil I thought everyone had agreed at one point that while it's nice to encourage cooperation, we shouldn't make it too hard to play the game alone? Not everyone has a nice network connection. This means not forcing a great specialization on everyone. >Some obvious problems: > - how to keep "score". Currently score is based on experience, if this goe I've always felt that "score" was beside the point in this game. For me, the fun was always solving new maps. > stats, magic power, spirituality and hit points instead of experience. Can we please use the terms "grace" and "mana"? They're short and capture the ideas of "spirituality" and "magic power" very well, IMHO. PeterM From crossfire-request Tue Jun 27 00:45:55 1995 Return-Path: Received: from bach.seattleu.edu (root@bach.seattleu.edu [199.237.224.11]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 27 Jun 1995 00:45:43 +0200 Received: by bach.seattleu.edu (4.1/SMI-4.1) id AA27517; Mon, 26 Jun 95 13:21:28 PDT Date: Mon, 26 Jun 1995 13:16:23 -0700 (PDT) From: "Kristofer M. Bosland" Subject: Re: Experience as "currency" (Re: Merged proposal) To: Ken Woodruff Cc: crossfire@ifi.uio.no In-Reply-To: <9506261616.AA21374@pluto> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I am very much for an Experience Point Economy. A minus is that it can greatly incease the time for some aspects of play, but I feel that this is balanced by the enjoyment of "detailing" your character. I think that just about anything could become purchasable with experience, and there are several pencil-and-paper games where this is a premise (I particularly like the HERO role playing system). This could make the characters as flexible and abstract as the map system, which I think would be a good thing. -Kris Bosland krisb@seattleu.edu From crossfire-request Mon Jun 26 19:08:24 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 26 Jun 1995 19:08:15 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA20491 for ; Mon, 26 Jun 1995 10:08:06 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma020446; Mon Jun 26 10:07:56 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA29728; Mon, 26 Jun 95 10:07:51 -0700 Received: by pluto (5.65+/1.5) id AA21470; Mon, 26 Jun 95 13:07:51 -0400 Date: Mon, 26 Jun 95 13:07:51 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506261707.AA21470@pluto> To: crossfire@ifi.uio.no Subject: Map Playtester(s) Wanted Status: RO I'm in the process of completing a new set of maps and I would like for someone (or a small number of someones) to test the maps for playability. The maps are essentially puzzle oriented, not violence oriented, and may take some time to solve. I'm looking for people who are willing to simply play the maps without looking at the map files for clues in order to get a sense of how hard it will be to figure out the puzzles. Any volunteers? --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Mon Jun 26 18:19:21 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 26 Jun 1995 18:17:03 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA11037 for ; Mon, 26 Jun 1995 09:16:46 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma011007; Mon Jun 26 09:16:30 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA26918; Mon, 26 Jun 95 09:16:25 -0700 Received: by pluto (5.65+/1.5) id AA21374; Mon, 26 Jun 95 12:16:25 -0400 Date: Mon, 26 Jun 95 12:16:25 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506261616.AA21374@pluto> To: crossfire@ifi.uio.no Subject: Experience as "currency" (Re: Merged proposal) Status: RO Wow--conciliation and compromise. A Crossfire first? Peter and Brian hash out: > > I rather like this proposal. But if I may, I would like to instead suggest > > a "6-experience" system. Each catagory has a player "stat" associated with it. > > We can argue about how many experience divisions later. Your position > is viable in the long run, but it needs lots of prerequisites before > it will make sense. I don't see any real motivation for moving beyond the four basic classes, and I'm not particularly compelled by assigning skills to particular stats. A typical skill is dependant on several stats, e.g. lockpicking should be a factor of dexterity for the physical aspect of jiggling the tools around, intelligence, to figure out the intricacies of this particular lock, and wisdom, for how many similar locks you've seen before. The class division seems more natural to me. Since everybody else is coming up with new names, I'll suggest some as well: Fighting (this term is ok, although "Physicality" might be more general, this covers anything which requires a primarily physical effort, be it chopping orcs with a battle axe or bashing down doors with a mace.) Thievery (I'd like to call this "Subtlety", this basically covers any means of accomplishing a task through less than straigthforward means) Magical (this term is fine, this covers all activities which use or derive from magic power. I see spells as the primary manifestation of magic skills.) Clerical (I'd like to call this "Spirituality", this basically covers all interactions with God/gods/other higher powers) Now to the main subject of this message: I'd like to float a proposal to coincide with a new experience system that may make it easier to handle accumulating experience and doling it out to various skills/classes/levels, etc. What if we considered experience not as an ever increasing number but rather as a kind of currency which you accumulate by adventuring and then "spend" (in a guild or similar place) to learn new skills or refine existing ones. This would allow players to have more flexibility in developing their characters and would also free the code from analyzing every activity for its effect on players skills. That's the basics, what follows are some more advanced ideas: - Make starting "profession" affect a multiplier for EP cost, e.g. a thief could buy lockpicking skills cheaper than a wizard could. - Allow for transferrence of experience from one category to another with some penalty, e.g. Physical EP could be spent for Subtlety skills at a cost of 3x the Subtlety cost. - Add an actual cost (gold pieces) to certain skills in addition to the experience cost. Again profession could have a multiplier effect here. (So could charisma?) - Profession Levels become another purchaseable skill, e.g. you could either become a 2nd level thief with that 1000EP or you could improve your ability to conceal yourself. - Skills can have prerequisites, which can be levels (i.e. you must be at least third level to learn this skill), or other skills (e.g. you must know how to make fire and levitate objects before you can throw fireballs) - Fundamental skills (ones which serve as prerequisites to many other skills) could be given a much higher price to encourage specialization. (a similar notion exists with the path attuned/repelled features of the current magic system). This could help prevent high level players from simply accumulating every skill from every class (at least not until they're a *really* high level.) Some obvious problems: - how to keep "score". Currently score is based on experience, if this goes up and down (as you spend it to get skills) it no longer makes sense as a score. I see several possibilities: 1) eliminate the idea of score, who really cares anyway, 2) come up with a scoring system that calculates the EP value of all of your skills and levels, or 3) keep two experience numbers, one being the available EP to spend and one the total EP ever accumulated. - What to do about "draining" attacks. I suggest this be changed to suck stats, magic power, spirituality and hit points instead of experience. This is still a very rough idea so I encourage criticism. --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Mon Jun 26 02:25:55 1995 Return-Path: Received: from sps1.phys.vt.edu (sps1.phys.vt.edu [128.173.176.53]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 26 Jun 1995 02:25:51 +0200 Received: (from martinm@localhost) by sps1.phys.vt.edu (8.6.9/8.6.9) id UAA01645 for crossfire@ifi.uio.no; Sun, 25 Jun 1995 20:25:44 -0400 From: "Michael B. Martin" Message-Id: <199506260025.UAA01645@sps1.phys.vt.edu> Subject: A couple bugs...? To: crossfire@ifi.uio.no Date: Sun, 25 Jun 1995 20:25:44 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2201 Status: RO After way too much crossfire playing this weekend, I've stumbled across what appear to be a couple of bugs (well, ok, only one may really be a bug). One, which hit me twice this weekend (but never before), is that when changing maps the map window would go blank (i.e. every tile is just solid black). Everything else looked just fine. The first time happened when I entered the "downtown" inn in the starting city (Scorn?), and the second was when going between a couple levels of the Tower of the Stars. In both cases the console had a message reading something like (this example for the second one): No temporary filename for map /peterm/CTower/Laboratory Trying to insert object outside the map The second time I saved the game there (with the 'save' command) and then killed the process and restarted it. It put me outside the normal playing area (just like it said it had) and I had to restore from a backup character file (good thing I had one!). Can anyone say what would cause this? I still have room on the file system, so it shouldn't be due to lack of disk space. It almost sounds to me like it is trying to determine a unique name to use to save the temporary file (in /tmp), but it can't (all of them already in use?!?). But this doesn't sound right. The other problem (which I think really IS a bug) appears to be a problem with the inventory system. I had a Luggage with lots of stuff in it which I emptied on the ground. When I went to put some stuff back in it, it said that I couldn't (it said it couldn't hold it or something like that). I noticed then that the weight of the Luggage given in the inventory window was 3.0 kg, despite the fact that left-clicking on it with the mouse to display the stats for it in the message window listed it as weighing 20.0 (what it should). What gives? My only guess is that the inventory system messed up and took off too much weight when removing the contents of the Luggage and then that caused it to not accept anything else. My solution to this was of course to sell it and get another. But I still thought this was odd. I have done exactly the same thing many times before and never had this problem. -Michael From crossfire-request Mon Jun 26 00:08:13 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 26 Jun 1995 00:07:56 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id PAA28008; Sun, 25 Jun 1995 15:05:33 -0700 Message-Id: <199506252205.PAA28008@soda.CSUA.Berkeley.EDU> To: "Michael B. Martin" cc: crossfire@ifi.uio.no Subject: Re: firebrand gone wrong? In-reply-to: Your message of "Sat, 24 Jun 1995 15:20:14 EDT." <199506241920.PAA09965@sps1.phys.vt.edu> Date: Sun, 25 Jun 1995 15:05:26 -0700 From: Peter Mardahl Status: RO In message <199506241920.PAA09965@sps1.phys.vt.edu>, "Michael B. Martin" writes : > > >Actually, I noticed something like this myself just yesterday. I >managed to make it all the way to the Fire DragonMaster (or whatever >the correct name is) in the "Dragon Quest" cave, and beat it. I found >two special swords, one was a "Storm[something]" (maybe "Stormbringer"?) >and the other (I think) was a Firebrand. I tried then both out and >found them to be quite disappointing compared to the sword I enchanted >myself way back when I was 12th level or so (perhaps the 7 "Enchant" >scrolls are more important than I realized at the time). With the Any weapon you made yourself then was bound to be better than anything you could find. By a lot. When I made these maps I wanted to balance them with respect to the rest of the world, and believe me, you won't find weapons that nice in many other places. >supposed to have "weaponmagic" attacks as well (or does the >"weaponmagic" just do more damage?). I just figured that this was due Practically nothing is immune to "weaponmagic". That is the advantage of it. >BTW, is there a "reflector" shield that a 20th level character could >get to by himself? I am still getting clobbered by these lightning- >wielding monsters... If you look enough you'll find one. Or an amulet of reflection or defense or something. PM From crossfire-request Sun Jun 25 23:57:23 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 25 Jun 1995 23:57:21 +0200 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id OAA26986; Sun, 25 Jun 1995 14:54:20 -0700 Message-Id: <199506252154.OAA26986@soda.CSUA.Berkeley.EDU> To: simonm@bristol.st.com cc: crossfire@ifi.uio.no Subject: Re: firebrand gone wrong? answer: feature not bug In-reply-to: Your message of "Sat, 24 Jun 1995 12:11:37 BST." <436.9506241111@springbank.inmos.co.uk> Date: Sun, 25 Jun 1995 14:54:03 -0700 From: Peter Mardahl Status: RO In message <436.9506241111@springbank.inmos.co.uk>, simonm@bristol.st.com write s: >demons and all I kept getting was "you missed the demon" - I >couldn't hit them at all. I did better if I wielded nothing Since a Firebrand uses Fire as its attack instead of Physical (it attacks only with AT_FIRE) you will ALWAYS miss something which is immune to fire. It is a feature, not a bug. Other weapons will have this same effect somewhat differently, as in a weapon with a pure AT_MAGIC attack hitting something immune to magic, etc. >Anyone have any idea what is going on? Surely Firebrand has >a physical attack as well as a fire attack? This is all Read the archetype for Firebrand. The behavior you describe is exactly that of having only an AT_FIRE. PeterM From crossfire-request Sat Jun 24 21:20:54 1995 Return-Path: Received: from sps1.phys.vt.edu (sps1.phys.vt.edu [128.173.176.53]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 24 Jun 1995 21:20:24 +0200 Received: (from martinm@localhost) by sps1.phys.vt.edu (8.6.9/8.6.9) id PAA09965 for crossfire@ifi.uio.no; Sat, 24 Jun 1995 15:20:15 -0400 From: "Michael B. Martin" Message-Id: <199506241920.PAA09965@sps1.phys.vt.edu> Subject: firebrand gone wrong? To: crossfire@ifi.uio.no Date: Sat, 24 Jun 1995 15:20:14 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2208 Status: RO > Has anyone else had problems with archetypes going a bit wrong? > My relatively low-level character (lvl 10) just found Firebrand, > and I thought "Great!", the first really decent piece of > weaponry I'd found so far. But then I tried taking on some > demons and all I kept getting was "you missed the demon" - I > couldn't hit them at all. I did better if I wielded nothing > and hit them with my bare hands! It also wouldn't hit any > earthwall, which was really inconvenient. Other creatures > (low-ish level) it was mowing through very nicely. > > Anyone have any idea what is going on? Surely Firebrand has > a physical attack as well as a fire attack? This is all > happening with 0.91.8 with no whacky patches applied, > compiled under Solaris 2.4 and X11R5 using gcc etc etc. > (Going to try compiling under X11R6 sometime in the > next two weeks!) Actually, I noticed something like this myself just yesterday. I managed to make it all the way to the Fire DragonMaster (or whatever the correct name is) in the "Dragon Quest" cave, and beat it. I found two special swords, one was a "Storm[something]" (maybe "Stormbringer"?) and the other (I think) was a Firebrand. I tried then both out and found them to be quite disappointing compared to the sword I enchanted myself way back when I was 12th level or so (perhaps the 7 "Enchant" scrolls are more important than I realized at the time). With the Firebrand I had the same problem with always missing tough monsters that I only infrequently missed with my sword +7, even though it is supposed to have "weaponmagic" attacks as well (or does the "weaponmagic" just do more damage?). I just figured that this was due to the new sword not having as high a wc, and thus couldn't hit the tougher monsters, but the other person's situation makes it sound a little strange (if he could hit better with bare hands). Is it supposed to be this way? I got a fair amount of platinum for selling those two swords, but I would think that special weapons should seem more powerful. BTW, is there a "reflector" shield that a 20th level character could get to by himself? I am still getting clobbered by these lightning- wielding monsters... -Michael From crossfire-request Sat Jun 24 20:18:50 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 24 Jun 1995 20:18:44 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id OAA27117 for crossfire@ifi.uio.no; Sat, 24 Jun 1995 14:18:24 -0400 Date: Sat, 24 Jun 1995 14:18:24 -0400 From: Brian Thomas Message-Id: <199506241818.OAA27117@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: race/profession proposal Status: RO >>I would suggest that if a "class-as-skill" system is used (which, BTW, >>sounds fine to me), that each character at least start with the 4 >>basic class skills (or whatever the "basic" skills are; there could be > >Hear hear. I think we are building enough of a consensus to start >implementation of skills-as-objects. We can argue about what you >start out with later..... Skills-as objects has already been implemented! What we need to do is begin to agree on what kind of things we want to be able to do in the new '4 or more experience catagory' system. In this way we can more intellegently decide on how to 'reconfigure' the skills-objects. With this in mind one aspect is how implementation of the seperation of race/profession could be handled. I have tried outline what we might do in the following brief sketch. Below of some of the critical characteristics are shown. (because of personal bias I have pitched this slightly toward the 6-stat-based experience system, but it is all basically applicable to a 4-exp based system). ***************************************** CONCERNING CHARACTER STATS. ***************************************** Basically I would leave this alone, but the introduction of Power as a stat (6-experience proposal) requires a little bit of shuffling. Below is an outline of possible changes (I believe this falls in line with what Peter is suggesting?): Stat Old usage New usage ---- --------- --------- Int set #spell points Controls learning of spells/prayers Wis contr learn spells set max #grace points Pow ------- set #spell points ***************************************** CONCERNING MATTERS of RACE ***************************************** Suggested stat bonuses and limits by race: ----------------------------------------- This is based on current 1-30 range. The modifier is first and the limit in paraenthesis. For established races, I basically took current values. but in a few cases I changed things around a little (usually because the meanings of Int/Wis/Pow are little different than before). Race Str Dex Con Int Wis Pow Cha Mod sum. ---- ------- ------- ------- ------- ------- ------- ------- -------- dwarven...... +3 (23) -4 (16) +4 (24) +0 (20) +0 (20) -1 (19) -3 (17) -1 elven........ -2 (18) +3 (23) -2 (18) +1 (21) -3 (17) +1 (21) +1 (21) -1 fireborn..... -7 (13) +4 (24) -3 (17) +3 (23) +3 (23) +4 (24) -4 (16) 0 human........ +0 (20) +0 (20) +0 (20) +0 (20) +0 (20) +0 (20) +0 (20) 0 orc.......... +3 (23) +2 (22) +3 (23) -1 (19) -1 (19) -1 (19) -4 (16) +1 quetzalcoatl. +4 (24) -4 (16) +4 (24) +0 (20) -7 (13) +5 (25) +0 (20) +2 troll........ +5 (25) +2 (22) +5 (25) -3 (17) -3 (17) -3 (17) -3 (17) +0 wraith....... -4 (16) +4 (24) -4 (16) +2 (22) +2 (22) +3 (23) -10 (10) -7 Notice that for almost all races the sum of the modifiers comes near 0. In those cases which do not, this is because of a corresponding advantage/disadvantage that race has balanced this out. These are given below. Again, for established races, I took the default. Suggested inherent race abilities/advantages and disadvantages -------------------------------------------------------------- Race Advantages Disadvantages Base AC Base Dam Attacks ---- --------- ------------ ------- -------- -------- dwarven....... smithery skill ---- 10 1 physical elven......... woodsman, ---- 10 1 physical missle weapons spellcasting fireborn...... spellcasting, no weapon or 0 0 fire, immune to fear, armour use physical fire vuln to cold, ghosthit, drain human......... missle weapons ---- 10 1 physical orc........... missle weapons vuln to fear 10 1 physical quetzalcoatl.. spellcasting, vuln to cold, 5 10 physical immune to fire poison, paralyze 1 spell no armour use troll......... ---- vuln to fire 2 10 physical wraith........ immune to drain vuln to fire 6 1 cold, & ghosthit physical prot to cold, physical ***************************************** CONCERNING MATTERS OF PROFESSION ***************************************** In addition to an amount of starting cash (variable according to profession) a given profession would allow a player skills/benifits and disadvantages. I have included suggested possiblities for new and old professions. Profession Associated Skills Other ben/disadv. ---------- ----------------- ----------------- Archer missle weapons, bow + arrows, DEX potions bowyer Barbarian woodsman, mountaineer, Str potions jumping Bard singing, woodsman instrument Burgler stealing, hiding lockpicks, dex potion Cleric praying, oratory path_attuned protect Druid praying, woodsman path_attuned create Mage spellcasting, sen_magic spellbook, pow potion Merchant bargaining, oratory Cha potions Monk karate, jumping, no weapons, path_attuned self meditation,sen_magic Necromancer spellcasting,sen_magic path_attuned drain, summon and create. path_denied fire, spellbook Priest praying,sen_curse path_attuned abjure,protect, and restoration. path_denied missiles spellbook Rogue stealing str + dex potion Viking missle weapons prot to cold, vuln to fire str potion Warrior missle weapons, str + con potion wrestling I am by no means being complete here. But this should give a good idea of the possible things we will have to allow the software to do in order to set up professions. b.t. From crossfire-request Sat Jun 24 21:04:57 1995 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 24 Jun 1995 21:04:57 +0200 Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by maud.ifi.uio.no ; Sat, 24 Jun 1995 21:04:45 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id OAA27107; Sat, 24 Jun 1995 14:06:57 -0400 Date: Sat, 24 Jun 1995 14:06:57 -0400 From: Brian Thomas Message-Id: <199506241806.OAA27107@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, peterm@CSUA.Berkeley.EDU Subject: Re: Merged proposal Cc: crossfire@ifi.uio.no Status: RO > I think the key is to design the system so that we can have N experience > skills and a multitude of associated and misc. skills. Someone who ^^^^^^ Ok things are beginning to come together (I think :). I would now request that we all start using a common terminology in order to avoid confusion. For "experience skills" I would substitute "experience catagories" or "experience types". > Keeping N low is a good idea because then searches for awarding experience > would be relatively quick. Hmm. I am not sure I follow here. The performance of the "associated skill" should immediately deposit exp in the right "experience catagory". Each skill-as object has the right "experience catagory" tagged in its data field somewhere. > I and some others would ask that all players start with > praying, basic thievery, mage, and fighting skills. Ok. I think I can address this in the next post. Right now everyone does start with fighting skills. As far as praying thievery and magery, I can see a "racial" bias allowing some races to start with some of these, but not all races. What is the point of starting as a "wizard" or an "elf" if you don't get the chance of "spellcasting"? But I dont see why "orcs" or "trolls" or "humans" are innately capable of magic use. Again, Check out my next post, and we can discuss this further. > Furthermore, for a Fireborn, it is not appropriate for him to > have Hand Weapons: a fireborn's attack is by means of fire, and > fire composes his body. A fireborn cannot hold a weapon. Yes I have considered this too. The fireborn should be allowed some kind of hand-to-hand ("hth") attack. Not karate, but maybe something like "punching". > I do not like starting a char with limited skills. > Rare skills are one thing, but the 4 basic ones belong in everyone. I think we are getting hung up on semantics here (another reason to clear up our terminology!). In my conception, every character is allowed to acquire experience in *any* of the "experience catagories". The major point is that for some race/ profession combinations you would not start off with any associated skills in *that experience catagory*. Let's review what I suggested that a basic character start off with, and see which of the experience catagories that they will get: 'Basic' associated skill Exp Catagory ------------------------- ------------- hand weapons 'fighting' or 'strength' throwing 'fighting' searching 'intellegence' (but, if we must have 4 cat. only this would be 'thieving' disarm traps 'dexterity' or 'thieving' missle weapons^1 'fighting' (1 I didnt originally proposal 'missle weapons' skill as part of the basic 'package' of skills, but I relent under pressure :) So we see (under a 4 exp catagory system) *any* character a player might choose to generate will *automatically* be able to start garnering experience in 'fighting' and 'thievery'. In a stat-based 6 catagory system any basic character has associated skills in the 'strength' 'dexterity' and 'intellegence' catagories. I would suggest that 'spellcasting', 'prayer', 'stealing', or any of the more common associated skills be available either to appropriate characters to start, or by tromping down to the wizard's guild or your local temple and purchasing it (for a goodly, but not steep starting fee). I believe someone suggested getting away from 'fixed' starting inventories and instead suppling a starting player with more $. Sounds good. If a starting character wants to have the 'spellcasting' for their 'troll/barbarian' let them hike over to the wizards guild and use their starting cash. b.t. From crossfire-request Sat Jun 24 13:13:04 1995 Return-Path: Received: from daisy (daisy.inmos.co.uk [138.198.1.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 24 Jun 1995 13:13:02 +0200 From: simonm@bristol.st.com Received: by daisy id MAA11784; Sat, 24 Jun 1995 12:15:20 +0100 Message-Id: <436.9506241111@springbank.inmos.co.uk> Subject: firebrand gone wrong? To: crossfire@ifi.uio.no Date: Sat, 24 Jun 1995 12:11:37 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Has anyone else had problems with archetypes going a bit wrong? My relatively low-level character (lvl 10) just found Firebrand, and I thought "Great!", the first really decent piece of weaponry I'd found so far. But then I tried taking on some demons and all I kept getting was "you missed the demon" - I couldn't hit them at all. I did better if I wielded nothing and hit them with my bare hands! It also wouldn't hit any earthwall, which was really inconvenient. Other creatures (low-ish level) it was mowing through very nicely. Anyone have any idea what is going on? Surely Firebrand has a physical attack as well as a fire attack? This is all happening with 0.91.8 with no whacky patches applied, compiled under Solaris 2.4 and X11R5 using gcc etc etc. (Going to try compiling under X11R6 sometime in the next two weeks!) Simon From crossfire-request Sat Jun 24 03:09:01 1995 Return-Path: Received: from Amita.MontrealNet.ca (root@[204.19.33.10]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 24 Jun 1995 03:06:34 +0200 Received: from jmeunier ([204.19.33.83]) by Amita.MontrealNet.ca (8.6.9/8.6.9) with SMTP id UAA21578 for ; Fri, 23 Jun 1995 20:57:35 -0400 Date: Fri, 23 Jun 1995 20:57:35 -0400 Message-Id: <199506240057.UAA21578@Amita.MontrealNet.ca> X-Sender: jmeunier@amita.montrealnet.ca (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: crossfire@ifi.uio.no From: jmeunier@amita.montrealnet.ca (jean meunier) Subject: game X-Mailer: Status: RO I woud like to know about this game. JEAN MEUNIER CITE ELECTRONIQUE VIDEO JMEUNIER@MONTREALNET.CA From crossfire-request Sat Jun 24 00:54:18 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 24 Jun 1995 00:54:16 +0200 Received: from localhost (localhost [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id PAA00272; Fri, 23 Jun 1995 15:54:09 -0700 Message-Id: <199506232254.PAA00272@soda.CSUA.Berkeley.EDU> To: "Michael B. Martin" Subject: Re: What skills people should have at start, +misc comments Cc: crossfire@ifi.uio.no In-reply-to: Your message of "Fri, 23 Jun 1995 11:49:26 EDT." <199506231549.LAA07956@sps1.phys.vt.edu> Date: Fri, 23 Jun 1995 15:54:07 -0700 From: Peter Mardahl Status: RO In message <199506231549.LAA07956@sps1.phys.vt.edu>, "Michael B. Martin" writes : > > >I would suggest that if a "class-as-skill" system is used (which, BTW, >sounds fine to me), that each character at least start with the 4 >basic class skills (or whatever the "basic" skills are; there could be Hear hear. I think we are building enough of a consensus to start implementation of skills-as-objects. We can argue about what you start out with later..... >powerful mage in a distant tower who will increase your magical >ability, but first you have to do/get something for him? (I.e. could >relate skill acquisition/improvement to quests for more variety.) > >Well, these are just thoughts. What do you think? It'd be nice if there were a new archetype which when you stepped on it would grant you some type of experience. This could be a reward of quests. I've been meaning to do it for a long time but never have. PeterM From crossfire-request Fri Jun 23 22:18:55 1995 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 22:18:55 +0200 Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by maud.ifi.uio.no ; Fri, 23 Jun 1995 22:18:29 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id QAA26587; Fri, 23 Jun 1995 16:17:03 -0400 Date: Fri, 23 Jun 1995 16:17:03 -0400 From: Brian Thomas Message-Id: <199506232017.QAA26587@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no Subject: Merged proposal Cc: thomas@chaupher.gsfc.nasa.gov Status: RO >Peter Mardahl writes: > >Or leave spells as they are and have their use controlled by >cleric_skill and magic_skill? > >How about this as a direction? > >Initally, 4 basic experience skills. More can be added later, I guess, >as the game evolves. Hopefully the list will always be very short. >These would have a level and a #experience. > >Some misc. skills which, when used, give exp. to one of the exp. skills. > >Other misc. skills which are so weird that they don't need to be associated >with anything else, and don't need a #experience. I rather like this proposal. But if I may, I would like to instead suggest a "6-experience" system. Each catagory has a player "stat" associated with it. There would be "associated" skills for each catagory. Practice of "associated" skills would add experience in that catagory. "Miscellaneous" skills may also exist too. These skills are not associated with any experience catagory, and consequently the practice of these skills results in no experience gained by the player. 6 Experience Catagories *********************** Name Possible alternate name ---- ----------------------- Strength "fighting" or "pruissiance" Dexterity "thievery" or "acrobatics" Intellegence "knowledge" or "perception" Wisdom "grace" or "(un)holiness" Charsima "leadership" "personality" Power "magic" or "wizardry" Thus we achieve a more natural division of the experience catagories as each of these is no longer a "profession" per se. Player characters are now a blend of stat-based experience catagories. Astute readers will notice the introduction of a new player stat "Power". Also there is no experience catagory for "constitution". Perhaps the "strength" catagory also depends on it. Nontheless, as Peter suggested, "associated skills" are related to each catagory. The effect and success of each of these skills would be set by the character's experience in that stat-based catagory. Here's a possible breakdown of where I would put the "associated" skills: Associated skills ----------------- Str Pow Dex Wis Int Cha ---- ---- ---- ---- ---- ---- Hand Weapons*+ Spellcasting* Stealing Praying* Jeweler Oratory Missle Weapons* Writing Hiding Sense Curse Smithery Singing Karate Sense Magic Lockpicking Blessing Alchemy Bargaining Throwing*+ Enchantment Set traps Woodsman Boxing Disarm traps+ Find Traps+ Wrestling Thamaugery Literacy Medicine (the * denotes a skill which is required to perform an action, + denotes that all characters start with this skill). Note I have included skills on this list that currently dont exist in the game (throwing, medicine, enchantment, blessing, etc). I wont attempt to describe them here. Also, there can be skills which give no experience to any catagory, and I'll adopt "miscellaneous" skills to name these. Miscellaneous skills (awards no experience for use) -------------------- Mountaineer Jumping Meditation How this might work >>>>> A. implications for character profession and race -------------------------------------------------- Hand Weapons, Throwing, Find traps (currently called 'searching'), and disarm traps skills are available to all starting characters. This duplicates the current situation in CF closely. Now, at the beginning of the game a player would first pick a race, which would set stat modifications and stat limits. Then, a player would pick a "proffession". Choice of profession would give the character a blend of skills (skill scrolls in the starting inventory. Also, the player would start with a variable amount of money, and perhaps one or two special hard-to-find items which are indicative of the profession. B. Handling experience and skill levels ---------------------------------------- Practice of the available skills would then dicate which kind of experience was ultimately gained by the player. In this way, as new skills are gained the player he/she broadens the scope of their character. If the new associated skill is in a stat-based experience catagory outside of previously used ones, that player will start at 1st level. If the new skill is in a stat-based experience catagory that the player already has some experience in, the skill starts at the level of that catagory. Alternatively, we could set things up so that when the player gains an skill associated with a stat-based catagory for which they already have experience, they will have to use it a couple of times to bring it "up to speed". An asterix (or other symbol) on the skills menu might denote this status for a new skill (which might be used at 1/2 level to start, until its "up to speed"). C. Gaining experience -- stat advantages ---------------------------------------- With these catagories we can now assign higher or lower rates of 'learning' based on a player characters stat. For example, Stat value Experience Adjustment (%) (unadjusted) ---------- ------------------------- 1 - 3 35 % of nominal gain 4 - 6 45 % of nominal gain 7 - 9 75 % of nominal gain 10 - 14 nominal exp gain, no adjustment 15 - 17 110% of nominal gain 18 - 22 120% of nominal gain 23 - 30 130% of nominal gain Thus, for example, a while both "mage" and "fighter" characters start with the "hand weapons" skill, the figher will most likely have the higher Strength stat and gain experience by fighting with hand-held weapons faster than the mage. Well, that's my "merged" proposal. Comments?? -b.t. From crossfire-request Fri Jun 23 18:04:06 1995 Return-Path: Received: from sps1.phys.vt.edu (sps1.phys.vt.edu [128.173.176.53]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 18:04:02 +0200 Received: (from martinm@localhost) by sps1.phys.vt.edu (8.6.9/8.6.9) id MAA07988 for crossfire@ifi.uio.no; Fri, 23 Jun 1995 12:03:57 -0400 From: "Michael B. Martin" Message-Id: <199506231603.MAA07988@sps1.phys.vt.edu> Subject: Re: remarks on implementation of various skill proposals To: crossfire@ifi.uio.no Date: Fri, 23 Jun 1995 12:03:57 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1389 Status: RO > > Well. How about exp for healing monsters? Missonary work :) > > Also abusable, i assume this was a joke though. Yeah, you could imagine finding a solitary monster and then attacking and healing it over and over. > That's true. But you won't gain exp indefinitely. After you reach a certain > level, you will get no exp. from killing easy monsters. No exp at all. You could exclude the requirement of cutoffs by reworking the experience/level tables so that higher levels take a *lot* more experience (goes up sort of exponentially, maybe in base 2?), like in AD&D. Once your fighting ability is reasonably high, for example, it will take you a *long* time to advance further by killing easy monsters. No pain, no gain. > Neither do I have a problem with that. I'd award it based on dungeon > level and spell level, and sp. After all, if they cast a light spell successfully, > it counts as practice and should go to mage experience. And if they're > lame enough to stand around doing light spells all the time, well, they'll > find lots of other ways to cheat too. Right. Make each spell have a different amount of experience gained (in successful casting), so a powerful mage would have to cast a *lot* of light spells to gain much experience, but those destruction spells could boost you quickly. :) Changing the experience tables should be easy enough. -Michael From crossfire-request Fri Jun 23 18:00:26 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 18:00:24 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id JAA21427 for ; Fri, 23 Jun 1995 09:00:06 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma021332; Fri Jun 23 08:59:48 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA25240; Fri, 23 Jun 95 08:59:43 -0700 Received: by pluto (5.65+/1.5) id AA20127; Fri, 23 Jun 95 11:59:43 -0400 Date: Fri, 23 Jun 95 11:59:43 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506231559.AA20127@pluto> To: crossfire@ifi.uio.no Subject: Too many spells? (was Re: remarks ...) Status: RO Brian writes: > Are you being serious here? I note that there are currently about > 130 spells in CF; do you think that this is a "mental burden"? If it were, > would you advocate removing some of these spells?!? I rather think lots of > spells adds color to the game. There can never be too many. Ditto for > skills. Only poorly designed skills (or spells for that matter) should ever > be 'removed' from the game. Frankly, there *are* too many spells! Well, maybe not too many, but definitely a lot of redundant ones. For example: small, medium and large fireball should be one level dependant spell ditto for the lightning spells ditto for turn undead, holy word, banishment ditto for reincarnate, ressurrect, raise dead ditto for icestorm, large icestorm (I'd rather have a snow-ball than large icestorm if you want to update the DragonQuest :0) If you want to continue to provide non-level based control over a given spell then I suggest that there be an argument to the spell indicating how many sp you want to go into it, e.g. "cast fireball 10" would do less damage (and cost less sp) than "cast fireball 50". (Want to get fancy? Base chances of success on the ration of spell caster level to number of sp used.) --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Fri Jun 23 17:50:01 1995 Return-Path: Received: from sps1.phys.vt.edu (sps1.phys.vt.edu [128.173.176.53]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 17:49:40 +0200 Received: (from martinm@localhost) by sps1.phys.vt.edu (8.6.9/8.6.9) id LAA07956 for crossfire@ifi.uio.no; Fri, 23 Jun 1995 11:49:28 -0400 From: "Michael B. Martin" Message-Id: <199506231549.LAA07956@sps1.phys.vt.edu> Subject: Re: Critique of Summarized plans To: crossfire@ifi.uio.no Date: Fri, 23 Jun 1995 11:49:26 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3034 Status: RO > >>>>[From Brian Thomas] > > And so on. A player without "praying" or "wizardry" would > be unable to perform magic. A player without "arms" would be able to > attack with weapons, but would never advance without the skill. Lack > of "hth" skill would make martial arts attacks impossible. > > I liked it fine up until here. > > realistically speaking; > Anyone can pray, without an in-born "skill". > (but getting something back is going to be rather rare :-) > Anyone can fight,without a "skill".. and if they fight a lot.. they are > going to get better. I agree. For example, a "fighter" may start with a very small but non-zero amount of clerical ability. (You could have a "Paladin" as a "fighter" with good clerical ability :) (And I don't mean clerical ability in the sense of typing, filing letters, etc. ;) > magic is the only thing I could see as "you got it or you don't" > kind of thing. > > If a "magic user", maybe you need the special "magic-chanelling gene". > If you're doing clerical type magic, you obviously need to have > devoted your life to your god toget special favours I'm not sure I agree with this. An old Atari/Amiga game called Dungeon Master used a 4-way class system like what has been proposed, and each character had experience to some degree in each of the classes. Even my fighters had at least a little magical ability (but they started with quite a small amount), and by the end of the game (after working on their magical experience a lot) they could cast usable spells (like light spells). But, of course, they were always well behind the mages. I think this helped to provide better game balance (in the end, I needed every last spell point I could get). I would suggest that if a "class-as-skill" system is used (which, BTW, sounds fine to me), that each character at least start with the 4 basic class skills (or whatever the "basic" skills are; there could be a few "basic" thief skills). Additional skills could also be granted initially (maybe selecting the "class" of your character initially and receiving related additional skills, like smithery for a fighter), or just let the characters have to acquire them later in the game. Also, I just had another thought. In addition to gaining skill experience through direct use of the skill, why not add "mentors", who you could visit (and pay a large sum of money or something else very valuable, no doubt) to increase a particular skill. Perhaps even something along the lines of a real-world university (a place with a lot of NPC's of different "classes" who could teach you skills). You could even place limits on how high an NPC might be able to take you (can't teach you beyond their ability/knowledge). How about a powerful mage in a distant tower who will increase your magical ability, but first you have to do/get something for him? (I.e. could relate skill acquisition/improvement to quests for more variety.) Well, these are just thoughts. What do you think? -Michael From crossfire-request Fri Jun 23 06:56:15 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 06:56:10 +0200 Received: from localhost (localhost [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id VAA14144; Thu, 22 Jun 1995 21:56:03 -0700 Message-Id: <199506230456.VAA14144@soda.CSUA.Berkeley.EDU> To: "Brian Thomas" Cc: crossfire@ifi.uio.no Subject: Re: remarks on implementation of various skill proposals In-reply-to: Your message of "Thu, 22 Jun 1995 23:09:24 EDT." <9506230309.AA16426@griffle.astro.psu.edu> Date: Thu, 22 Jun 1995 21:56:02 -0700 From: Peter Mardahl Status: RO In message <9506230309.AA16426@griffle.astro.psu.edu>, "Brian Thomas" writes: > > Well. How about exp for healing monsters? Missonary work :) Also abusable, i assume this was a joke though. >> About the only viable means of awarding exp in the game is via kills of >> monsters. (A trap is just another kind of 'monster', really.) Alternately, > I strongly disagree. With proper forthought using each of the skills >could be a source for experience. For example.. lockpicking, *any* of the >idenification skills, etc. would be hard to abuse. Let's face it though, These are in the category I mentioned. I generalized 'monster' and 'kill' to include one-time things like disarming traps, picking locks, doing first identifications, etc. I just didn't mention them all by name. >some one can *already* abuse the current system by bracing their character That's true. But you won't gain exp indefinitely. After you reach a certain level, you will get no exp. from killing easy monsters. No exp at all. >way. A little forthought with the skills would be what is needed. BTW, I >see no reason not to allow spellcasters some reasonable amount of exp for >successfull casting. Neither do I have a problem with that. I'd award it based on dungeon level and spell level, and sp. After all, if they cast a light spell successfully, it counts as practice and should go to mage experience. And if they're lame enough to stand around doing light spells all the time, well, they'll find lots of other ways to cheat too. > I am currently implementing the skills. Some skills (2-4) do increase >in effect with level, but you are basically correct. I had decided to leave >the issue of experience effecting (and being gain though the use of) skills >for the future. I guess the future is here now :) At some point, will you please describe a bit to me about how skills are implemented? I'd rather not hack code to find out. Save your mail as a document for posterity..... >> 1) there CAN be so many skills that it becomes a mental burden for the >> player > Are you being serious here? I note that there are currently about >130 spells in CF; do you think that this is a "mental burden"? If it were, I think it would become a mental burden if you had a different skill level in each spell. >would you advocate removing some of these spells?!? I rather think lots of >spells adds color to the game. There can never be too many. Ditto for >skills. Only poorly designed skills (or spells for that matter) should ever >be 'removed' from the game. There are some spells in that category, but fortunately, I think most of them are turned off already. >> Losing your inventory could destroy your skills > > How often does a player's character loose their inventory??? I >have never had this happen. Oh. Maybe not in the versions you've worked on, but certain earlier versions really had trouble with this. Happened all the time, in fact. > Yes, that is how it is done now. In monsters this is'nt a problem, >and really isnt much problem for most players either. What could be >done is that the object structure could have a pointer to 'next_skill' and >the player structure could point to the 'first_skill' ie > > first skill in list op->contr->first_skill > second skill op->contr->first_skill->next_skill > etc. This becomes an O(n) search on the number of skills. With many skills, this could get really cumbersome a search to do if it's done a lot. >> GUI complexity of displaying what skills are around. > > I don't follow you here. Skills as impletmented are either visible 'tools' >(like lockpicks) which allow the use of skills or are invisible. The 'tools' >very naturally should be in the inventory window, whereas the inherent 'player' >skills are not visible. A command 'skills' currently lists all available skills. >Were we to have each skill having exp, the 'tools' implementation would have to >be rethought. You're not contemplating turning all spells into skills? This would saturate any list far beyond acceptable levels. Imagine 200 skills or so.... Maybe a couple of types of skills? Experience skills and misc. skills and spell skills? Or leave spells as they are and have their use controlled by cleric_skill and magic_skill? Also, what should be done in cases where the misc. skills should give experience in a general skill by their use? (Use of lock-pick-skill to thief-skill exp) In any case I have no problem with implementing experience-skills as objects. I think experience-skills should be very limited in number however, and the greater number of misc. skills should funnel exp into the experience-skills (as appropriate) when used. I'm not willing to assume leadership of the experience-skills-as-objects. Are you (Brian Thomas) willing? I can give some help, but most of the work is going to have to be by you. How about this as a direction? Initally, 4 basic experience skills. More can be added later, I guess, as the game evolves. Hopefully the list will always be very short. These would have a level and a #experience. Some misc. skills which, when used, give exp. to one of the exp. skills. Other misc. skills which are so weird that they don't need to be associated with anything else, and don't need a #experience. PeterM From crossfire-request Fri Jun 23 06:00:51 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 06:00:39 +0200 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id VAA10861 for crossfire@ifi.uio.no; Thu, 22 Jun 1995 21:00:20 -0700 From: Philip Brown Message-Id: <199506230400.VAA10861@soda.CSUA.Berkeley.EDU> Subject: Re: Critique of Summarized plans To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 22 Jun 1995 21:00:15 -0700 (PDT) In-Reply-To: <199506230336.XAA26044@chaupher.gsfc.nasa.gov> from "Brian Thomas" at Jun 22, 95 11:36:07 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 839 Status: RO >>>>[From Brian Thomas] And so on. A player without "praying" or "wizardry" would be unable to perform magic. A player without "arms" would be able to attack with weapons, but would never advance without the skill. Lack of "hth" skill would make martial arts attacks impossible. I liked it fine up until here. realistically speaking; Anyone can pray, without an in-born "skill". (but getting something back is going to be rather rare :-) Anyone can fight,without a "skill".. and if they fight a lot.. they are going to get better. magic is the only thing I could see as "you got it or you don't" kind of thing. If a "magic user", maybe you need the special "magic-chanelling gene". If you're doing clerical type magic, you obviously need to have devoted your life to your god toget special favours From crossfire-request Fri Jun 23 05:36:23 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 05:36:20 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id XAA26044; Thu, 22 Jun 1995 23:36:07 -0400 Date: Thu, 22 Jun 1995 23:36:07 -0400 From: Brian Thomas Message-Id: <199506230336.XAA26044@chaupher.gsfc.nasa.gov> To: thomas@nexus.astro.psu.edu, martinm@sps1.phys.vt.edu Subject: Re: Critique of Summarized plans (fwd) Cc: crossfire@ifi.uio.no Status: RO > > Where we have 1 experience variable, we would have 4 > where we have 1 level, we would have 4 > (and all associated things like tables would be 4x) > > disarming traps would go toward thief exp I would also add lockpicking and stealing too! > I agree that the "4-class" method is rather limiting when skills are > included into the picture. I am still working on that one, although > it would be much easier if each fell into one of the basic categories. > Perhaps the skills could be separate things in themselves, so > experience for a skill increases only by using that skill, and doing > so does not affect any other experience levels. This would separate > skills from classes. Yes this is true. But if you are going to all the work to have each (little) skill have experience, why not make fighter/mage/cleric/ thief into (little) skills too? I think the main point of the 4-skills proposal is that each skills catagorie would have "associated skills". For example, "thief" skill would have associated with it: "lockpicking" "stealing" "hiding" "find/remove/set traps" If you increase in thief skill, then all the "associated" skills also increase too. What is good about this is that you get differentiation in the kinds of experience a player may earn (as opposed to now). What (I think) is bad about it is that all "thieves" now have the mix of "associated" skills. Adding new skills in this system becomes harder to do too, and you must always have a fighter/thief/mage/cleric blend (the least ill of the 3, I could live with this :). > > This may be going a bit overboard, but a simple conceptual model would > be to treat spell-casting and fighting ability as just two more > skills (or maybe more than two if you wished to split them up). Then > every thing would be based on a skill system, with each particular > skill having its own experience level. "Class" would have little > meaning in this context, excepting for the allowance of a character to > concentrate effort in only one or a few skills. Perhaps this is too > realistic. :) > This would be some effort to code. But I like it alot. The overall experience of a player is kept as the *sum* of all the experience in each of the skills. Overall player level is based on the summed experience score. No new interface would be needed :) Now, instead of 4-experience system we could have Name of new skill Exp in it increases ---------------------------------------- --------------------------- "praying" skill (for casting cleric spells) - "grace" and effect of prayers "wizardry" skill (for casting magician spells)- sp, and effect of spells "arms" skill wc,speed,dam using weapons "bow" skill wc,speed,dam using bows "hth" skill(s) for unarmed combat wc,speed,dam using martial arts And so on. A player without "praying" or "wizardry" would be unable to perform magic. A player without "arms" would be able to attack with weapons, but would never advance without the skill. Lack of "hth" skill would make martial arts attacks impossible. From crossfire-request Fri Jun 23 05:09:56 1995 Return-Path: Received: from nexus.astro.psu.edu (nexus.astro.psu.edu [128.118.147.20]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 05:09:53 +0200 Received: from griffle.astro.psu.edu by nexus.astro.psu.edu (4.1/Nexus-1.3) id AA06004; Thu, 22 Jun 95 23:09:37 EDT Received: by griffle.astro.psu.edu (4.1/Client-1.3) id AA16426; Thu, 22 Jun 95 23:09:24 EDT Date: Thu, 22 Jun 95 23:09:24 EDT From: "Brian Thomas" Message-Id: <9506230309.AA16426@griffle.astro.psu.edu> To: crossfire@ifi.uio.no, peterm@csua.berkeley.edu Subject: Re: remarks on implementation of various skill proposals Status: RO Hey all, ...some return thoughts....., ON EXP AWARDING > Awarding experience is a big pain. How do you award experience without >allowing abuse? For example, once I proposed that clerics be given exp. >for healing friendly players. Someone pointed out how readily you could > Well. How about exp for healing monsters? Missonary work :) > About the only viable means of awarding exp in the game is via kills of > monsters. (A trap is just another kind of 'monster', really.) Alternately, I strongly disagree. With proper forthought using each of the skills could be a source for experience. For example.. lockpicking, *any* of the idenification skills, etc. would be hard to abuse. Let's face it though, some one can *already* abuse the current system by bracing their character in front of a portal and just kill monsters created by a generator on the other side. With enough time (bracing does decrease the exp gain) there is *no* limit on how much exp you can gain. What matters is not whether it is *possible* to cheat, but rather if it is *easy* (or worthwhile) to cheat that way. A little forthought with the skills would be what is needed. BTW, I see no reason not to allow spellcasters some reasonable amount of exp for successfull casting. ON SKILLS > where there is now one. Furthermore, skills as someone (i forget who) > is currently implementing them don't seem to involve experience at all. I am currently implementing the skills. Some skills (2-4) do increase in effect with level, but you are basically correct. I had decided to leave the issue of experience effecting (and being gain though the use of) skills for the future. I guess the future is here now :) > I'd rather see: > 1) there CAN be so many skills that it becomes a mental burden for the > player Are you being serious here? I note that there are currently about 130 spells in CF; do you think that this is a "mental burden"? If it were, would you advocate removing some of these spells?!? I rather think lots of spells adds color to the game. There can never be too many. Ditto for skills. Only poorly designed skills (or spells for that matter) should ever be 'removed' from the game. >Undetermined number of skills >--------------------------------------- > >I really am not sure how those advocating this were thinking >of implementing it. Here's one possible approach to implementation: > >Re-implement skills as objects. When you do a relevant action, >you find the skill object in that person and add experience to it. >(I'd appreciate if someone would fill this out.) Ok sure :). Skills (as currently implemented) are objects in the inventory of the player. Adding an exp field (to only be used by skills objects) would allow keeping track of a character's exp in each skill. > Cons: > Losing your inventory could destroy your skills How often does a player's character loose their inventory??? I have never had this happen. > inventory search needed for knowing what skills exist Yes, that is how it is done now. In monsters this is'nt a problem, and really isnt much problem for most players either. What could be done is that the object structure could have a pointer to 'next_skill' and the player structure could point to the 'first_skill' ie first skill in list op->contr->first_skill second skill op->contr->first_skill->next_skill etc. > coding complexity of assigning experience based on skill when > you have a multitude of them This is true. Play testing would be required to 'tune' this. Not trivial to do. > GUI complexity of displaying what skills are around. I don't follow you here. Skills as impletmented are either visible 'tools' (like lockpicks) which allow the use of skills or are invisible. The 'tools' very naturally should be in the inventory window, whereas the inherent 'player' skills are not visible. A command 'skills' currently lists all available skills. Were we to have each skill having exp, the 'tools' implementation would have to be rethought. b.t. From crossfire-request Fri Jun 23 04:02:37 1995 Return-Path: Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 04:02:37 +0200 Received: from aachen.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id EAA00728 for ; Fri, 23 Jun 1995 04:02:35 +0200 Received: from chapelle.aachendom by aachen.ericsson.se (4.1/SMI-4.1/AACHEN1.2) id AA29561; Fri, 23 Jun 95 04:02:35 +0200 Received: by chapelle.aachendom (4.1/SMI-4.1) id AA20286; Fri, 23 Jun 95 04:02:34 +0200 Date: Fri, 23 Jun 95 04:02:34 +0200 Message-Id: <9506230202.AA20286@chapelle.aachendom> To: crossfire@ifi.uio.no Subject: Re: many thoughts. From: Raphael.Quinet@aachen.eed.ericsson.se Reply-To: Raphael.Quinet@aachen.eed.ericsson.se Status: RO On Thu, 22 Jun 1995 18:03:51 -0700, Mark Wedel wrote: > > What a character wears will determine much more what he looks like than > his class. A cleric wearing chain and a fighter wearing chain will look > much closer than a fighter wearing chain and a fighter wearing nothing > at all. > Good point! But this mean that the pixmap should change each time you change your equipment. And what about a backpack that grows as you add more objects to your inventory? Only joking... > One solution would just be to let the player choose which image they > want to represent their character. Players could choose images that don't > look like their characters, but that will happen if they are assigned > via race or class in anycase. > If they choose an image among a limited set available on the server, then it's OK. But we should not allow players to create their own image. There are (at least) three reasons against that: - there would be too many pixmaps and some machines that are low on memory could suffer from that. - there is no way to upload bitmaps/pixmaps to the server. - last year, when we were discussing the client/server protocol, I said that it would be nice if some clients could ignore the pixmaps from the server and replace them by their own versions (larger, maybe). Although I doubt that such a feature will ever be implemented, the player-specific pixmaps would make it impossible. > What would probably be the best way to change the experience system would > be have an add_player_experience function. What would be passed would > be what was killed (monster, trap, door, etc.), who killed it (player), > and what killed it (sword, fireball, lockpick, etc..) > Good idea. The code would be cleaner. Note: I think it should also be possible to add experience when a player completes a quest, even if he doesn't have to fight any monster to complete that quest. Or maybe there should be an archetype for that: an invisible object which is killed when the player walks over it and gives some exp points. That you be compatible with add_player_experience. -Raphael From crossfire-request Fri Jun 23 03:04:13 1995 Return-Path: Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 03:04:09 +0200 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA10573 (5.67b8/IDA-1.5 for ); Thu, 22 Jun 1995 18:04:03 -0700 Received: from foxtrot.rahul.net by bolero.rahul.net with SMTP id AA11765 (5.67b8/IDA-1.5 for ); Thu, 22 Jun 1995 18:04:01 -0700 From: Mark Wedel Received: by foxtrot.rahul.net (5.67b8/jive-a2i-1.0) id AA21924; Thu, 22 Jun 1995 18:03:51 -0700 Date: Thu, 22 Jun 1995 18:03:51 -0700 Message-Id: <199506230103.AA21924@foxtrot.rahul.net> To: crossfire@ifi.uio.no Subject: many thoughts. Status: RO While having a unique bitmap for each race & class, there are a few problems: What a character wears will determine much more what he looks like than his class. A cleric wearing chain and a fighter wearing chain will look much closer than a fighter wearing chain and a fighter wearing nothing at all. One solution would just be to let the player choose which image they want to represent their character. Players could choose images that don't look like their characters, but that will happen if they are assigned via race or class in anycase. Experience: It seems to me, that additional experience fields only need to be added to the player structure. Monsters gaining experience doesn't really happen, so why are 4 experience fields stored in the object structure (only thing I could think of would be if you want to give different types of experience for killing a monster..) What would probably be the best way to change the experience system would be have an add_player_experience function. What would be passed would be what was killed (monster, trap, door, etc.), who killed it (player), and what killed it (sword, fireball, lockpick, etc..) This would then make it easier to add and tune experience. Mages are getting to much for killing things with fireball? In that case, by just modifying that functin, you can tune it. Likewise if you do want to add new experience or skills - only that function needs to be updated (door was killed by lockpick, so we increase lockpick skill instead of thief experience.) --Mark From crossfire-request Fri Jun 23 02:10:17 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 02:10:14 +0200 Received: (peterm@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id RAA23068 for crossfire@ifi.uio.no; Thu, 22 Jun 1995 17:10:03 -0700 Date: Thu, 22 Jun 1995 17:10:03 -0700 From: Peter Mardahl Message-Id: <199506230010.RAA23068@soda.CSUA.Berkeley.EDU> To: crossfire@ifi.uio.no Subject: remarks on implementation of various skill proposals Status: RO To those concerned: Someone brought up implementation. I'd like to remark on how I had planned to implement the 4-skills proposal I have made. Implementation of 4-skills: _____________________________________________________________ It is very simple-minded and doesn't involve any new data-structures, nor any greatly increased code complexity. This is partly why I have proposed it: I knew that it could be done in a reasonable time period. Where we have 1 experience variable, we would have 4 where we have 1 level, we would have 4 (and all associated things like tables would be 4x) disarming traps would go toward thief exp killing w/ magic spells would go toward wiz exp via AT_MAGIC killing w/ godpower would go toward cleric via AT_GODPOWER killing w/ physical means would go toward fighting Weaknesses: Artifacts with AT_MAGIC would give mage exp upon kills in a naive implementation (which is what the 1st cut would be) not flexible, really clunky to add any new skills quadruples the space required by each obj. for experience related stuff not elegant Remarks: I'll take leadership of implementing this, though I'll need some support from people who know X (so that I can update the client) ________________________________________________________________ Undetermined number of skills --------------------------------------- I really am not sure how those advocating this were thinking of implementing it. Here's one possible approach to implementation: Re-implement skills as objects. When you do a relevant action, you find the skill object in that person and add experience to it. (I'd appreciate if someone would fill this out.) Pros: flexible, adding skills is easy. All conceivable skills could be maintained separately Cons: Losing your inventory could destroy your skills inventory search needed for knowing what skills exist coding complexity of assigning experience based on skill when you have a multitude of them GUI complexity of displaying what skills are around. From crossfire-request Fri Jun 23 01:32:13 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 01:32:01 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id TAA25956; Thu, 22 Jun 1995 19:31:55 -0400 Date: Thu, 22 Jun 1995 19:31:55 -0400 From: Brian Thomas Message-Id: <199506222331.TAA25956@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, peterm@CSUA.Berkeley.EDU Subject: Re: Consensus on race/class separation? Cc: crossfire@ifi.uio.no Status: RO > In message <199506211823.OAA25191@chaupher.gsfc.nasa.gov>, Brian Thomas writes: > > > > bitmap for each posible combination (ie there is an "elf-wizard" map and a > > "elf-barbarian" map set, etc.) It would be alot of work however. > > Lack of available maps might set the available professions for races (initia > >lly :). > > It is a lot of work, but we really only need 1 bitmap per race. > fireborn, wraith, troll, human, dwarf, elf. > > However, I'd really hate to have to stop using the wizard bitmap. > One thing i proposed once was to have your maximum level or levels > in the 4 skill areas set your bitmap: a powerful wizard, weak fighter, > intermediate cleric, weak thief would look like a wizard. > > PeterM > Well, I am willing to do a large fraction of this work. What/how many races/classes are being thought of here? Let review a bit: My guess is for races: Human Elven Dwarf orc? troll? wraith fireborn quetzequaltl (sp?) Because they are so unusual, for the last 4 I would advocate using the race archetype for the player object. For professions: Barbarian Mage Monk Ninja Swashbuckler(rogue?) Thief Warrior If we just change the colors in the maps to allow for "fire" "frost" "nature", etc "Mages" and similarly "Northern" "jungle" "barbarians" we can expand each profession by a bit with little extra work. Really, we still only have 7 "professions" here, and thus need to generate about 21 maps (for troll, elf, dwarf races). If you want to start limiting the available classes (or exp catagories) for certain races (very D&D like :) you will cut down further on the bitmaps needed. b.t. From crossfire-request Fri Jun 23 01:15:27 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 23 Jun 1995 01:15:14 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id TAA25950; Thu, 22 Jun 1995 19:14:55 -0400 Date: Thu, 22 Jun 1995 19:14:55 -0400 From: Brian Thomas Message-Id: <199506222314.TAA25950@chaupher.gsfc.nasa.gov> To: thomas@chaupher.gsfc.nasa.gov, peterm@CSUA.Berkeley.EDU Subject: Re: Critique of Summarized plans Cc: crossfire@ifi.uio.no Status: RO > > in a new experience system. What about skills > > which don't seem to be associatable with any of the > > 4 kinds of exp like "smithing" or "bargaining"? > > I remark that if you create a > sage/tourist/mechanic, you also have > to create something for each of these > to do. Right now, there aren't > any internal combustion engines. It Hmm. The 'mechanic' I had in mind was someone handy with medieval technology--skills for that character include "smithing","find traps","set traps",etc. I would also hope to see such a character actually be able to *make* objects too from raw materials found/purchased in the game. > doesn't therefor make sense to > have a mechanic. Similarly, I don't > see places in the game for merchants, > sages, or tourists, unless you mean > some blend of cleric/magic/fighter/thief. > In the case of merchants I would like to see a "fighter" who may bargain, trade and sell well, in the case of a "tourist" someone ("fighter"?) who travels well (not really serious about this class BTW), and by a sage someone who "studies" well (learns spells, deciphers runes, can write scrolls of magic spells). I guess at the base of my unease about a "4-experience" system is : 1) Very D&D like. 2) I want to do more than bash monsters all the time. Lets have flexibilty--allow characters to steal things, sneak in/out with monsters treasure, lead followers, etc. Right now exp is *only* awarded for killing monsters and removing traps. I wish CF had a "wider" scope. If you tie skills to certain experience catagories, then the future creation of skills become fixed to fitting with in those catagories. Also, I would hate to see every "fighter" (for example) have the exact same skills, to my mind this is like having every wizard have the exact same spells. Silly. I think this brings up one last point too. I see skills as being *just like spells*. By this I mean: 1) There cannot be too many of them 2) profieceny is linked to character level 3) effect is particular and unique. > > Not really. The 4-skills one is > pretty simple. I've assessed the coding > involved, and while not nothing, I know > what to do and know I can do it. > The playing complexity is manageable in > my opinion, players only have to adventure > to gain levels, and generating a character > will be exactly as it is now: he'll choose > a race, roll a char, and start with zero > exp in all categories. > I am still willing to help particpate in this effort. But I would like to see a better proposition as to how the skills (and spells) should be related to character class. For example, why cant we have "fire wizards". This would be a player with the "wizard" profession who has path_attuned "fire" and path_denied "frost". This character would start with a few fire spell books. Similarly, "fighter" characters could be diverse, like "smith" and "archer" and "barbarian". Each type of fighter would start with a different blend of skills and possessions. b.t. > Well, you also get 4 degrees of freedom. Right now, mages > advance really, really easily once they get fireball, compared > to fighters. You can tune the experience required for levels > for each category appropriately, providing an easy mechanism > for play balancing. > > > PeterM > From crossfire-request Wed Jun 21 23:57:42 1995 Return-Path: Received: from bach.seattleu.edu (krisb@bach.seattleu.edu [199.237.224.11]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 21 Jun 1995 23:57:37 +0200 Received: by bach.seattleu.edu (4.1/SMI-4.1) id AA13897; Wed, 21 Jun 95 14:57:03 PDT Date: Wed, 21 Jun 1995 14:54:53 -0700 (PDT) From: "Kristofer M. Bosland" Subject: Re: Consensus on race/class separation? To: Ken Woodruff Cc: crossfire@ifi.uio.no In-Reply-To: <9506211517.AA19586@pluto> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 21 Jun 1995, Ken Woodruff wrote: > > If no one has any objections to these changes I believe we should begin to discuss > how to implement them, specifically whether player objects will reference race > archetypes ("elf", "orc", "human", etc.) or profession archetypes ("fighter", > "mage", "ninja", etc.). > > --Ken > Oh! Oh! I smell hints of Multiple Inheritance! (hehe!) I think it would be neat if someone could be IS-A elf _and_ IS-A ninja! -Kris "!" Bosland krisb@seattleu.edu From crossfire-request Wed Jun 21 20:24:09 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 21 Jun 1995 20:24:05 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id OAA25191; Wed, 21 Jun 1995 14:23:55 -0400 Date: Wed, 21 Jun 1995 14:23:55 -0400 From: Brian Thomas Message-Id: <199506211823.OAA25191@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no, woodruff@cadence.com Subject: Re: Consensus on race/class separation? Status: RO > we can get a consensus opinion on one thing, which is that race should be separate > from class (or "profession"). Anyone object to this? I'm not trying to read I think its a good idea. (I want to have an elf wizard :) > any implications about experience, skills, or stats into this decision, just that > these features should be separate, i.e. you can be an elf *and* a wizard, not an > elf *or* a wizard. It may be that we'll decide to link class and race in some way > in the future (say by giving certain races predilections or aversions to particular > classes) but that's not part of the current decision. > While I would push for skills to be largely associated with the character profession, I would also vote for making some "skill-like" abilities available to races too. For example, I would like to see all elves have some woodsman skill. To me, for elves to not have woodsman like ability would imply that the elf in question was from an entirely different sub-race of elves (like dark elves). > That said I would like to push for a consensus opinion on the following: the choice > of race should have an effect on stats, particularly starting bonuses and maximums. > I'm specifically not making any statement about whether class/profession should > or should not also have an effect on stats. > I agree (mostly) here. Stat bonuses and maximums should be largely set by the character race. > If no one has any objections to these changes I believe we should begin to discuss > how to implement them, specifically whether player objects will reference race > archetypes ("elf", "orc", "human", etc.) or profession archetypes ("fighter", > "mage", "ninja", etc.). > This is a good point. Which bitmap gets used for the player character? In an ideal world the player would get to use a "customized" icon for their character. The best way (IMHO) would be to have a separate race/profession bitmap for each posible combination (ie there is an "elf-wizard" map and a "elf-barbarian" map set, etc.) It would be alot of work however. Lack of available maps might set the available professions for races (initially :). b.t. > --Ken > > +------------------------+---------------------------------------------+ > | Ken Woodruff | Most Latin words in -us have plural in -i, | > | woodruff@cadence.com | but not all, & so zeal not according to | > +------------------------+ knowledge issues in such oddities as hiati, | > | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | > | bag full of $20 bills? | Fowler, "Modern English Usage" | > +------------------------+---------------------------------------------+ > From crossfire-request Wed Jun 21 19:48:11 1995 Return-Path: Received: from dior.it.lut.fi (hevi@dior.it.lut.fi [157.24.23.48]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 21 Jun 1995 19:48:11 +0200 Received: (from hevi@localhost) by dior.it.lut.fi (8.6.8/8.6.6/1.17.kim) id UAA09319; Wed, 21 Jun 1995 20:48:00 +0300 Date: Wed, 21 Jun 1995 20:47:59 +0300 (EET DST) From: Petri Heinila X-Sender: hevi@dior.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: Consensus on race/class separation? In-Reply-To: <9506211517.AA19586@pluto> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Wed, 21 Jun 1995, Ken Woodruff wrote: One suggestion more ;) How about approach of races/guilds. You start by selecting race that modifies stats and maxstats (maximum stats attached to race seems resonable if thinking about humans vs. elfs vs. orcs, the basic structure of body determines the capasity how much stat can develop). Starting items may also exist by race. When entering game you decide the guild (fighters,assasinates (ninja),thieves,healers(cleric),mages,..). You enter to the guild and if accepted you get some items (eg. broadsword and platemail for fighters, books for mages, and maybe some stat potions). It maybe limited for balance in that way player can belong one guild at time, so to change guild player have to sigoff from guild. And in guild when you get experience and make quests get can advance and get new items and quests. Somewhat this kind of systems exists in omega (but no races), if someone is interested how it works. btw. I don't mentioned priest here, and reason is that I see the status of priest is somewhat problematic because there exist no gods. Petri.Heinila@lut.fi From crossfire-request Wed Jun 21 17:19:51 1995 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 21 Jun 1995 17:19:51 +0200 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by maud.ifi.uio.no ; Wed, 21 Jun 1995 17:19:36 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id IAA13348 for ; Wed, 21 Jun 1995 08:18:04 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma013317; Wed Jun 21 08:17:52 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA08276; Wed, 21 Jun 95 08:17:48 -0700 Received: by pluto (5.65+/1.5) id AA19586; Wed, 21 Jun 95 11:17:49 -0400 Date: Wed, 21 Jun 95 11:17:49 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506211517.AA19586@pluto> To: crossfire@ifi.uio.no Subject: Consensus on race/class separation? Status: RO After reading Brian's summary (which was well done, BTW) it would appear that we can get a consensus opinion on one thing, which is that race should be separate from class (or "profession"). Anyone object to this? I'm not trying to read any implications about experience, skills, or stats into this decision, just that these features should be separate, i.e. you can be an elf *and* a wizard, not an elf *or* a wizard. It may be that we'll decide to link class and race in some way in the future (say by giving certain races predilections or aversions to particular classes) but that's not part of the current decision. That said I would like to push for a consensus opinion on the following: the choice of race should have an effect on stats, particularly starting bonuses and maximums. I'm specifically not making any statement about whether class/profession should or should not also have an effect on stats. If no one has any objections to these changes I believe we should begin to discuss how to implement them, specifically whether player objects will reference race archetypes ("elf", "orc", "human", etc.) or profession archetypes ("fighter", "mage", "ninja", etc.). --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Wed Jun 21 18:44:44 1995 Return-Path: Received: from csunb0.leeds.ac.uk (csunb0.leeds.ac.uk [129.11.144.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 21 Jun 1995 14:13:25 +0200 Received: from dream1.dcre.leeds.ac.uk (dream1.leeds.ac.uk [129.11.144.128]) by csunb0.leeds.ac.uk (8.6.9/8.6.9) with ESMTP id NAA22430 for ; Wed, 21 Jun 1995 13:07:25 +0100 Received: from csindy03.dcre.leeds.ac.uk by dream1.dcre.leeds.ac.uk; Wed, 21 Jun 1995 13:10:05 +0100 From: "Paul Rhodes" Message-Id: <9506211310.ZM12716@dcre> Date: Wed, 21 Jun 1995 13:10:04 +0100 In-Reply-To: Brian Thomas "Critique of Summarized plans" (Jun 20, 8:44pm) References: <199506210044.UAA24871@chaupher.gsfc.nasa.gov> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: crossfire@ifi.uio.no Subject: Re: Critique of Summarized plans Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: RO On Jun 20, 8:44pm, Brian Thomas wrote: > Subject: Critique of Summarized plans > 2) Fluidity of professions. None of the systems allow > a player to change profession. I highly dislike this. > At least in the old system you could do things not > suited to your initial choice of profession with > little problem (especially after you get a few rings, > artifacts and the like). Okay how about this option. Link experience to skills as mentioned before, but instead of linking these with the characters profession link them to the characters race and/or their stats. When a player is rolled up you could then allocate a 'initial' experience quota to a set of given skills. -- Paul From crossfire-request Fri Jun 16 13:45:35 1995 Return-Path: Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 16 Jun 1995 13:45:34 +0200 Received: (from hat@localhost) by tel1.tte.vtt.fi (8.6.11/8.6.11) id OAA15111 for crossfire@ifi.uio.no; Fri, 16 Jun 1995 14:45:02 +0300 From: Tero Haatanen Message-Id: <199506161145.OAA15111@tel1.tte.vtt.fi> Subject: Re: More on classes/skills/races/etc. To: crossfire@ifi.uio.no Date: Fri, 16 Jun 1995 14:45:01 +0300 (EETDST) In-Reply-To: <199506161038.AA208539085@lenkkari.cs.tut.fi> from "Juha Leskel{" at Jun 16, 95 01:38:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1100 Status: RO > I am almost sure that someone has proposed this earlier, but here is what > I think how this experience thing could be hadled easiest: I'm almost sure that everything has been proposed earlier :) The proposed idea was very similar that I had in my mind. In earlier post I didn't specify how players learn those skills, since I don't think it makes a big difference. My main point was that player can specify what skills he wants to learn (instead of a skill group). The players race and class would affect how hard it's learn each of available skill. The learning could have happen in guilds, reading the books or just typing 'practice steal' and it would require enough experience. For example: every time you advance level you could learn some skills. In addition to this, there could be some amount what could be learned just using the skill. E.g. If a thief uses active lock picking skill, he could learn it some amount, but needs more experience. Or players could even teach each others some skills. Also any player should not able learn all skills available him. -Tero From crossfire-request Fri Jun 16 12:38:46 1995 Return-Path: Received: from lenkkari.cs.tut.fi (lenkkari.cs.tut.fi [130.230.6.23]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 16 Jun 1995 12:38:46 +0200 Received: from localhost (zori.cs.tut.fi) by lenkkari.cs.tut.fi with ESMTP (1.37.109.16/16.2) id AA208539085; Fri, 16 Jun 1995 13:38:06 +0300 Message-Id: <199506161038.AA208539085@lenkkari.cs.tut.fi> X-Mailer: exmh version 1.6.1 5/23/95 To: crossfire@ifi.uio.no Subject: Re: More on classes/skills/races/etc. In-Reply-To: Your message of "Fri, 16 Jun 1995 02:38:40 EETDST." <199506160938.AA24054@foxtrot.rahul.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jun 1995 13:38:05 +0300 From: Juha Leskel{ Status: RO I am almost sure that someone has proposed this earlier, but here is what= I think how this experience thing could be hadled easiest: Split all the exp a charcter gets into portions depenting on charcters race and class. For example a human fighter would get his exp split so that most of it goes to fighting abilities and so on. You would still have to create these different abilities to divide the exp in. There could also be skills that are out of this experiece scheme and they would= have different skill points which would improve when you use that skill. This is how I see would be nice, but I do understand the need to do this according to existing rules like AD&D. In my model it would also be easy = to deal with parties. IMHO. Juha Leskel=E4 From crossfire-request Fri Jun 16 11:58:35 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 16 Jun 1995 11:58:27 +0200 Received: (xkd@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id CAA09227 for crossfire@ifi.uio.no; Fri, 16 Jun 1995 02:58:10 -0700 From: Kundi Xue Message-Id: <199506160958.CAA09227@soda.CSUA.Berkeley.EDU> Subject: Question about adding new archetypes To: crossfire@ifi.uio.no (Mailist Crossfire) Date: Fri, 16 Jun 1995 02:58:07 -0700 (PDT) X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 404 Status: RO Hello all, I was adding some new archetype with some new bitmaps and pixmaps. After I added them to the appropriate directory in the arch directory, I did make collect and make all in lib. After that I restart the game again. Everything seems fine except xpm doesn't work. It show wierd pictures. I wonder what I missed. Anyone known what I did wrong, please help me. Thanks a lot! Regards -kundi From crossfire-request Fri Jun 16 12:05:20 1995 Return-Path: Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 16 Jun 1995 12:05:13 +0200 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA09781 (5.67b8/IDA-1.5 for ); Fri, 16 Jun 1995 02:38:41 -0700 Received: from foxtrot.rahul.net by bolero.rahul.net with SMTP id AA22389 (5.67b8/IDA-1.5); Fri, 16 Jun 1995 02:38:41 -0700 From: Mark Wedel Received: by foxtrot.rahul.net (5.67b8/jive-a2i-1.0) id AA24054; Fri, 16 Jun 1995 02:38:40 -0700 Date: Fri, 16 Jun 1995 02:38:40 -0700 Message-Id: <199506160938.AA24054@foxtrot.rahul.net> To: krisb@seattleu.edu, woodruff@cadence.com Subject: Re: More on classes/skills/races/etc. (long) Cc: crossfire@ifi.uio.no Status: RO While re-training should be time consuming, the problem is how to deal with this in crossfire. In AD&D, you could say the character ages 4 years or whatever (and if part` of a party, either the rest of the party waits a like amount of time and ages that much, or they go adventuring without himm.) I can't really think of a good way to do this in crossfire. If it takes a certain amount of real time, the player just starts the process, goes grab lunch, let it do it overnight, or so on. If it is mundane in that fashion, it doesn't add anything to the game. However, at the same time, if all it takes is to go to a guild and plunk down 5000 (or whatever amount) of gp, you pretty quickly have high level characters learning everything in sight (if they think it is worth it.) The idea of gaining exp in different skills is nice. The problem you will always have is people using this to their best advantage (casting those cleric spells to get exp (there are not many offensive cleric spells out there that will kill monsters.)) Getting experience with mage spells is pretty easy. Hand to hand can be more difficult, but you can pretty easily abuse that one by weakening the monster with spells, and moving into the kill with your sword. And this doesn't even address the problem of party in experience. Right now, it gets split between everyone in the party. How do you work it with skills? However, going to a skill based system (with perhaps different races having different propensity toward different skills) is certainly going to be better than the present system. As for code seperation: In general, all the X11 code is in the common/xutil.c and server/xio.c files. --Mark From crossfire-request Fri Jun 16 11:30:58 1995 Return-Path: Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 16 Jun 1995 11:30:55 +0200 Received: (from hat@localhost) by tel1.tte.vtt.fi (8.6.11/8.6.11) id MAA13422 for crossfire@ifi.uio.no; Fri, 16 Jun 1995 12:30:22 +0300 From: Tero Haatanen Message-Id: <199506160930.MAA13422@tel1.tte.vtt.fi> Subject: Re: More on classes/skills/races/etc. To: crossfire@ifi.uio.no Date: Fri, 16 Jun 1995 12:30:21 +0300 (EETDST) In-Reply-To: <9506152037.AA17460@pluto> from "Ken Woodruff" at Jun 15, 95 04:37:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1398 Status: RO From: woodruff@cadence.com (Ken Woodruff) I agree with what Ken said. It's clear that human, fighter, elf and fireborn don't belong the same category. If crossfire have races and classes, then abilities and stats could used like Ken said. > However, I'm not sure that the goal should necessarily be simplicity, > just more logical behaviour. I think that a wide variety of classes > (such as the Paladins, Rangers, Druids and Illusionists added by AD&D) > would add to the game. The only thing that I don't like Peter's proposal is dividing experience in four categories. It makes some sense, but I'm not convinced that it's a good idea. The old mails are archieved and available from http://www.ifi.uio.no:/~frankj/crossfire/archive/ so there you you should find already proposed ideas (May-June 94 has some skill related articles). [Hint: Someone could do nice html-interface for archieves. ;)] I prefer a system where experience affects some generic things like hp's and sp's and skills tell how good a player is in the specific skill. If a thief practices lock picking, he can become a good lock picker, but it doesn't makes he better in stealing. Also a fighter could consentrate for the specific weapon type. It would be little more complicated but much more flexible. New classes could be added easily, just defining how easily they can learn a specific skills. -Tero From crossfire-request Fri Jun 16 06:05:01 1995 Return-Path: Received: from bach.seattleu.edu (krisb@bach.seattleu.edu [199.237.224.11]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 16 Jun 1995 06:04:59 +0200 Received: by bach.seattleu.edu (4.1/SMI-4.1) id AA10698; Thu, 15 Jun 95 21:04:44 PDT Date: Thu, 15 Jun 1995 20:54:33 -0700 (PDT) From: "Kristofer M. Bosland" Subject: Re: More on classes/skills/races/etc. (long) To: Ken Woodruff Cc: crossfire@ifi.uio.no In-Reply-To: <9506152037.AA17460@pluto> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I personally like skills more than classes. I think that the average person goes through 4 to 5 careers, and several people retrain or go to college twice. How about this: there are 4-5 (you could have more) basic "skill colleges", i. e. Fighter, Magic-User, Cleric, Theif. Each of these have a set of associated skills, such as weapons fighting or spell casting. A player gets to pick what "college" his character just graduated from on creation. You start with all the skills in your college, and can advance them relatively easily. You can also go to "Guild Halls" or something, and learn other skills from other "Colleges", but you advance in these skills much more slowly (you just don't have the background...). If you want to, you can train at another college/guild, but this is expensive, time consuming, boring, and doesn't always work. If you do gain 2 or more colleges, you have many more skills, but you advance slower than the "purists" (brain overload). You could even have advancement modifiers based on characteristics. How does this sound? Comments? BTW, if the non-graphical guts of crossfire are easy to program, could someone make a short guide showing where the separation is, so that those of us with many other projects can still make some contributions? -Kris Bosland krisb@seattleu.edu From crossfire-request Fri Jun 16 03:38:35 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 16 Jun 1995 03:38:29 +0200 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 21:36:43 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 21:36:09 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 13 Jun 1995 21:35:00 -0400 Date: Thu, 15 Jun 1995 20:35:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.869:16.05.95.01.36.09] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: An "easy"... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"20904 Thu Jun 15 21:36:24 1995"@bnr.ca> To: peterm@csua.berkeley.edu Cc: peterm@csua.berkeley.edu, woodruff@cadence.com, crossfire@ifi.uio.no Subject: Re: An "easy" MU/Fighter balance fix? Status: RO In message "Re: An "easy" MU/Fighter balance fix?", 'peterm@CSUA.Berkeley.edu' writes: >In message <"19799 Thu Jun 15 16:34:13 1995"@bnr.ca> , "tuan (t.) doan" writes: >>In message "Re: An "easy" MU/Fighter balance fix?", > >> Hmm...then why have any classes or races; why not have just one and the >>skill of the player depends on what the player does. Or perhaps you feel >>that classes/races only contributes to the initial characteristics of >>a character; which is a good assumption but an unrealistic one. > > Having one type of player would forbid having inborn immunities, >inborn vulnerabilities, inborn affinity to magic, and >inborn fighting characteristics such as size and strength. > > Does it not seem intuitive to you that a human would be general, >and elf weaker physically but more capable magically, a fireborn >immune to fire but vuln. to cold and a strong spellcaster, etc? Sure it does, different races has different inborn abilities. But inborn abilities should not be the only type of abilities available. Classes will allow non-inborn abilities such as choosen path or environmental constrainst. I guess I should underline the word 'only' in the above paragraph. > But why should different different types of humans have different >BASE characteristics? Is there a subrace of humanity which has >a 30% higher intelligence? Well, if you are referring to class, different types of humans (fighter, mage, thief) have different base characteristics because 1. they are born into those characteristics (ie: str, int, etc...) 2. the player choose to play that particular characteristics Sure there are "subrace" of humanity which has higher intelligence. If you are refering to the "subrace" as actual subraces, the reason is obvious (inheritance). If you are refering to the "subrace" as classes, the reason is the path the character wish to choose and the environment that allow a character of a class to be more intelligent than another (years of education) >> Races could served as inborn abilities and determine the initial >>characteristic of a player while classes can served at how well a particular >>character may advance in a particular skill/characteristics. It is the > > Well, why have classes? How do you work? You have some inborn >predilections, but do you not improve at what you practice? All I'm >saying is, so what if you're called a "cleric": if you smash things >with your mace all the time you'll become very good at smashing things >with your mace, but no better at praying. Classes are mainly used for non-inborn abilities. It could be that a player happen to choose a particular path (ie: training) or due to some environmental constrainst (ie: living underground gives better vision) >> Personally, I think there will be a balance and it will be determined not >>by the people doing the coding/designing of the game but the players. The >>best design is one that allow flexible changes dictated by the players. > > I've gotten so little feedback from players that I doubt they're much >interested in giving the game a direction, in general. They just play. >The ones who DO care end up on this mailing list and begin coding if they >want changes, or make maps. I disagreed. I found that players has many ideas and will indeed speak out if asked. Also most (not all players) will assumed that the game is rigid and does not changes, therefore will not speak out. But given the opportunity they will. There are players and there are implementors. The players should worry about playability (the why) and the implementors should worry about the flexibility of the system (the how) >> I think for starter we can experiment with the 4 classes/races because >>of its simplicity. However, if your design/coding is flexible enough to >>allow expansion of additional classes/races, it would be great. > > Races would be objects. All players would have all 4 skill divisions, >just in varying degree depending on what they do. In practice, >they'd have a MU-EXPERINCE, a CLERIC-EXPERIENCE, a Fighter, and thief. >What "class" you'd be would depend on what you did. I'm going to forward >you (tuan) a copy of my class-proposal from long ago--if i can find it. I haven't had a chance to read your proposal; but as I have said, there is not wrong with your 4 classes. All I wanted to add was if you make the design flexible enough to incorporate additional classes or races, then it will be a "good" design. As far as whether it would be a successful design really depends on the players :-) >PeterM Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Thu Jun 15 23:42:21 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 15 Jun 1995 23:42:14 +0200 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id OAA17137; Thu, 15 Jun 1995 14:41:12 -0700 Message-Id: <199506152141.OAA17137@soda.CSUA.Berkeley.EDU> To: "tuan (t.) doan" cc: peterm@csua.berkeley.edu, woodruff@cadence.com, crossfire@ifi.uio.no Subject: Re: An "easy" MU/Fighter balance fix? In-reply-to: Your message of "Thu, 15 Jun 1995 15:33:00 CDT." <"19799 Thu Jun 15 16:34:13 1995"@bnr.ca> Date: Thu, 15 Jun 1995 14:39:57 -0700 From: Peter Mardahl Status: RO In message <"19799 Thu Jun 15 16:34:13 1995"@bnr.ca> , "tuan (t.) doan" writes: >In message "Re: An "easy" MU/Fighter balance fix?", > Hmm...then why have any classes or races; why not have just one and the >skill of the player depends on what the player does. Or perhaps you feel >that classes/races only contributes to the initial characteristics of >a character; which is a good assumption but an unrealistic one. Having one type of player would forbid having inborn immunities, inborn vulnerabilities, inborn affinity to magic, and inborn fighting characteristics such as size and strength. Does it not seem intuitive to you that a human would be general, and elf weaker physically but more capable magically, a fireborn immune to fire but vuln. to cold and a strong spellcaster, etc? But why should different different types of humans have different BASE characteristics? Is there a subrace of humanity which has a 30% higher intelligence? > Races could served as inborn abilities and determine the initial >characteristic of a player while classes can served at how well a particular >character may advance in a particular skill/characteristics. It is the Well, why have classes? How do you work? You have some inborn predilections, but do you not improve at what you practice? All I'm saying is, so what if you're called a "cleric": if you smash things with your mace all the time you'll become very good at smashing things with your mace, but no better at praying. > Personally, I think there will be a balance and it will be determined not >by the people doing the coding/designing of the game but the players. The >best design is one that allow flexible changes dictated by the players. I've gotten so little feedback from players that I doubt they're much interested in giving the game a direction, in general. They just play. The ones who DO care end up on this mailing list and begin coding if they want changes, or make maps. > I think for starter we can experiment with the 4 classes/races because >of its simplicity. However, if your design/coding is flexible enough to >allow expansion of additional classes/races, it would be great. Races would be objects. All players would have all 4 skill divisions, just in varying degree depending on what they do. In practice, they'd have a MU-EXPERINCE, a CLERIC-EXPERIENCE, a Fighter, and thief. What "class" you'd be would depend on what you did. I'm going to forward you (tuan) a copy of my class-proposal from long ago--if i can find it. PeterM From crossfire-request Fri Jun 16 00:18:18 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 16 Jun 1995 00:18:11 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id NAA16974 for ; Thu, 15 Jun 1995 13:37:52 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma016913; Thu Jun 15 13:37:38 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA23994; Thu, 15 Jun 95 13:37:24 -0700 Received: by pluto (5.65+/1.5) id AA17460; Thu, 15 Jun 95 16:37:14 -0400 Date: Thu, 15 Jun 95 16:37:14 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506152037.AA17460@pluto> To: crossfire@ifi.uio.no Subject: More on classes/skills/races/etc. (long) Status: RO I think it might help to clarify the issues surrounding experience, skills, races and classes if we could make a decision about what experience a character might already of had when they start the game. I think the idea behind classes as they were originally envisioned by Gygax in the original D&D works was that the character you role-played had a prehistory, primarily they had received some rudimentary training in whatever skills were appropriate to that class. It is this training that the rest of your life's experiences will build on. To pull an example from real life you could think of a starting character as someone who has just graduated from college and is seeking a profession. If they majored in mathematics then it doesn't really make sense for them to try to find a job as an archeologist, they would spend too much time just learning the basics. This isn't to say they couldn't do it, but they'd progress in the profession at a much slower pace then someone who came to it with the proper background. Given this rationale, the assigning of different experience scales, different skills and different attributes to the various classes seems to make a lot of sense. Basically, no matter how hard they try a magic-user will never learn to be as skilled with weapons as a trained fighter, likewise a fighter will struggle to learn even the most rudimentary spells. As for dividing experience into skills as opposed to class (i.e. if you killed it with a sword you should gain fighting experience, if you killed it with magic you should gain magic experience) I don't have a fundamental problem with this, only that there should be a multiplier based on class which effects how quickly experience in the skill is gained. I also think that some experience spill over is natural, we all find ways to apply what we learn to our fields of expertise no matter how unrelated they may seem, so you should gain at least some class experience no matter what the source. If the notion of class experience is to be eliminated altogether then we should assign a "primary skill" to each class that the experience can be applied to. I believe race should be treated seperately from class excepting that certain races may have a propensity towards a particular class. This should be divided and made a separate choice from class, e.g. "Choose a race: [Elf, Dwarf, Human, Orc, ...]" before "Choose a class...". I believe that attribute maximums and starting bonuses should be race based, e.g. orcs generally have low charisma, elves tend to be good looking. The choice of a class should derive from your attributes, not change them--you became a mage because you're smart, not the other way around. I also believe that classes should have minimum stat requirements, e.g. you won't be admitted to fighter school if you have a weak constitution. Anyone get this far? Good. All of this said I'm willing to give qualified support to Peter's reccommendation for revamping the class/race/experience system, including coding if needed. However, I'm not sure that the goal should necessarily be simplicity, just more logical behaviour. I think that a wide variety of classes (such as the Paladins, Rangers, Druids and Illusionists added by AD&D) would add to the game. We can just see to it that the new classes are logically built up out of the fundamental skills. (Paladin = Cleric + Fighter, Ranger = MU + Fighter, Druid = MU + Cleric with different path attuned/repelled, etc.). --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Thu Jun 15 23:04:44 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 15 Jun 1995 23:04:34 +0200 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 17:01:16 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 16:34:12 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 16:33:00 -0400 Date: Thu, 15 Jun 1995 15:33:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.798:15.05.95.20.34.12] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: An "easy"... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"19799 Thu Jun 15 16:34:13 1995"@bnr.ca> To: peterm@csua.berkeley.edu Cc: woodruff@cadence.com, crossfire@ifi.uio.no Subject: Re: An "easy" MU/Fighter balance fix? Status: RO In message "Re: An "easy" MU/Fighter balance fix?", 'peterm@csua.berkeley.edu' writes: [stuffs deleted] >My philosophy of the game is that you are what you do: an elf might have >a predilection for wizardry (stat bonus) but if instead he slashes >things dead or shoots them with arrows, it is his fighting which >improves and not his magic. Hmm...then why have any classes or races; why not have just one and the skill of the player depends on what the player does. Or perhaps you feel that classes/races only contributes to the initial characteristics of a character; which is a good assumption but an unrealistic one. Races could served as inborn abilities and determine the initial characteristic of a player while classes can served at how well a particular character may advance in a particular skill/characteristics. It is the decision of picking which races and classes that makes the game more challenging. Personally, I think there will be a balance and it will be determined not by the people doing the coding/designing of the game but the players. The best design is one that allow flexible changes dictated by the players. >The four class idea also brings balance to the game easily: you >simply make it harder to advance in MU levels. > >Additionally, I'm prepared to back up my 4-class proposal with coding. >Many of those who advocated having a multitude of skills were willing >to "help", but I didn't see any volunteers to be responsible for it. I think for starter we can experiment with the 4 classes/races because of its simplicity. However, if your design/coding is flexible enough to allow expansion of additional classes/races, it would be great. >Regards, > >PeterM Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Thu Jun 15 22:52:10 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 15 Jun 1995 22:52:02 +0200 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 16:48:58 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 16:20:38 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 16:17:00 -0400 Date: Thu, 15 Jun 1995 15:17:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.582:15.05.95.20.20.38] X400-Content-Type: P2-1984 (2) Content-Identifier: re:An "easy" ... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"17597 Thu Jun 15 16:20:47 1995"@bnr.ca> To: woodruff@cadence.com Cc: crossfire@ifi.uio.no Subject: re:An "easy" MU/Fighter balance fix? Status: RO In message "An "easy" MU/Fighter balance fix?", 'woodruff@cadence.com' writes: > > >Currently Weapon Class (wc), used to calculate chance to hit (anything >else?) improves (by decreasing) with each level. Would it be possible >to change this so it's dependant on class, i.e. for fighter classes it >still decreases with each level, but for magic users it doesn't? This >might go a long way towards improving MU/fighter balance without drastically >changing the game or the code. If you wanted to get sophisticated you >could introduce a multiplier based on class, e.g. barbarians improve 1.5 wc >per level, warriors 2.0 wc per level, thieves 1.0 wc per level and wizards >0.1 wc per level. I like the idea of multiplier. Whatever the implementation, please do not restrict any particular skill to a particular class (ie: only fighters can wear armours or wield weapons) >Comments? I'd have to say overall this is one of the more conservative >ideas in fixing this problem. > >--Ken > >+------------------------+---------------------------------------------+ >| Ken Woodruff | Most Latin words in -us have plural in -i, | >| woodruff@cadence.com | but not all, & so zeal not according to | >+------------------------+ knowledge issues in such oddities as hiati, | >| Disclaimer: What tote | octopi, omnibi, & ignorami; ... | >| bag full of $20 bills? | Fowler, "Modern English Usage" | >+------------------------+---------------------------------------------+ Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Thu Jun 15 22:51:03 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Thu, 15 Jun 1995 22:50:58 +0200 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 16:49:07 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 16:20:40 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 15 Jun 1995 16:17:00 -0400 Date: Thu, 15 Jun 1995 15:17:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.586:15.05.95.20.20.40] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: An "easy"... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"17597 Thu Jun 15 16:20:48 1995"@bnr.ca> To: woodruff@cadence.com Cc: peterm@csua.berkeley.edu, crossfire@ifi.uio.no Subject: Re: An "easy" MU/Fighter balance fix? Status: RO In message "Re: An "easy" MU/Fighter balance fix?", 'woodruff@cadence.com' writes: [stuffs deleted] >BTW, I happen to have already coded my suggested change, you'll find a >context diff file for common/living.c attached to this mail. However I >wouldn't go so far as to send this to Mark for official inclusion until >I felt like at least a plurality of this list agreed with the idea. > >--Ken > >+------------------------+---------------------------------------------+ >| Ken Woodruff | Most Latin words in -us have plural in -i, | >| woodruff@cadence.com | but not all, & so zeal not according to | >+------------------------+ knowledge issues in such oddities as hiati, | >| Disclaimer: What tote | octopi, omnibi, & ignorami; ... | >| bag full of $20 bills? | Fowler, "Modern English Usage" | >+------------------------+---------------------------------------------+ Ken, Thanks for the diff file, I will put it in for our server and see how our players like it. Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Thu Jun 15 16:39:18 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 15 Jun 1995 16:39:15 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id KAA21752; Thu, 15 Jun 1995 10:38:59 -0400 Date: Thu, 15 Jun 1995 10:38:59 -0400 From: Brian Thomas Message-Id: <199506151438.KAA21752@chaupher.gsfc.nasa.gov> To: peterm@csua.berkeley.edu Subject: Re: An "easy" MU/Fighter balance fix? Cc: crossfire@ifi.uio.no Status: RO > Additionall, I'm prepared to back up my 4-class proposal with coding. > Many of those who advocated having a multitude of skills were willing > to "help", but I didn't see any volunteers to be responsible for it. Ok, I have to call you out on the "carpet" on this. I have been working on a skills code which (as of the last release to mark in a few days) comprised of 23 skills, all but one of which could be aquired by *any* character. About two months ago, I also (briefly) discussed unifying the skills code with (within) the spell code. However I never got a response back from you on whether you wished to collaborate with me. Can I assume that you have changed your mind? I am (and have been) working towards most of the goals you have esposed in your mail. I too am willing to "back up my ... proposal with coding". Any one else out there ? brian. From crossfire-request Thu Jun 15 12:38:17 1995 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 15 Jun 1995 12:38:17 +0200 Received: from spaunton.octacon.co.uk (spaunton.octacon.co.uk [193.118.80.14]) by maud.ifi.uio.no ; Thu, 15 Jun 1995 12:38:08 +0200 Received: (from rp10@localhost) by spaunton.octacon.co.uk (8.6.9/8.6.9) id LAA03842; Thu, 15 Jun 1995 11:35:47 +0100 Date: Thu, 15 Jun 1995 11:22:37 +0100 (BST) From: Robin Poole Subject: Re: An "easy" MU/Fighter balance fix? To: crossfire@ifi.uio.no In-Reply-To: <9506141858.AA16048@pluto> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I am somewhat concerned about the idea that the different classes are somehow unbalanced. It is not hard to create a "fighter" class character who is able to cast spells effectively as well. If one reduces the wc of magic oriented characters then a trade off should be made (perhaps giving them more spell points?). On another issue, I've recently tried to add new character types to my own installation of crossfire, mainly by hacking around with the archetypes file. I have had problems in adding character with skills (such as smithing, bowyer etc) although I can start playing when I try and use the skill crossfire crashes. Is this a problem with these skills in general or could it be my implementation? Bye, Robin Poole robin.poole@octacon.co.uk From crossfire-request Thu Jun 15 09:41:22 1995 Return-Path: Received: from tel1.tte.vtt.fi (tel1.tte.vtt.fi [130.188.12.3]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 15 Jun 1995 09:41:21 +0200 Received: (from hat@localhost) by tel1.tte.vtt.fi (8.6.11/8.6.11) id KAA01058 for crossfire@ifi.uio.no; Thu, 15 Jun 1995 10:40:50 +0300 From: Tero Haatanen Message-Id: <199506150740.KAA01058@tel1.tte.vtt.fi> Subject: Re: Coding style suggestion To: crossfire@ifi.uio.no Date: Thu, 15 Jun 1995 10:40:49 +0300 (EETDST) In-Reply-To: <9506142005.AA16065@pluto> from "Ken Woodruff" at Jun 14, 95 04:05:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 3142 Status: RO From: woodruff@cadence.com (Ken Woodruff) > foo = pl->stats.Str vs > #define get_player_strength(PL) ((PL)->stats.Str) and #define set_player_strength(PL, val) ((PL)->stats.Str = (val)) ? #define get_object_strength(PL) ((PL)->stats.Str) ? > foo = get_player_strength(PL); > > This has many benefits, I'll try to outline a few: Yes. It has advantages, but most of them requires that macros are used everywhere in code. And that means changing all existing code. D_LOCK(pl) is global macro for preventing inventory redraws, but it's not used much in the (new?) code. > - If you actually need a method you can implement one by swapping > a function for the macro. For example if we wanted strength to > decrease with a players age (say 5% per year over 50) you could > simply write a get_player_strength() function that implemented > this algorithm. Otherwise you would have to add another piece > of code after each use of the Str field. I don't think this is a good example, even idea behind it is. I think that get_function should return real value without modifications and set_function should make all modifications. It goes too complicated if some functions make modifications and others don't (no way to access the real value). query_value() ?? use flag for this, put adding (afterwards) flags to get_ functions isn't resonable. > - A lot of object types use the fields in strange ways. If I remember right then converters, altars amd some map functions already uses this at least locally. Of course these should be globally defined to avoid conflicts. I think that using indirect access to attributes is a good idea, but it also should be considered very carefully when/if implemented. A few things to note: - There should be minimum difference between players and monster. E.g. handle similar can_use_bow for monsters and players, also Str should be same effect for monsters and players. So does it make sense have get_player_str and get_object_str or is later enough. - How those access functions are designed and named? Is it get_player_str(pl) or query_value(pl, STR)? The later is similar to the current flag handling. The proposed name get_player_strength(PL) is too long, IMHO. Example: new_wc = get_player_wc(op) - get_player_level(op) - get_thaco_bonus (op); set_player_wc (op, new_wc) vs op->stats.wc -= (op->level + thaco_bonus[op->stats.Str]); The both examples are readable, but since those values are used in many calculations, they could be shorter (get_[pl_]str[ength]). Compare op_is_player(op) vs is_player(op), since in crossfire all are objects, is there need op_ (ob_?) prefix? The current flag macros repeat FLAG part twice, and it makes code just harder to read, IMHO. - It has been discussed before that object structure should be cleaned, and some how get memory requiments lower. It would require change access to attributes, so it would make sense consider both the same time. I don't know if Mark has some idea how this should be done. -Tero From crossfire-request Wed Jun 14 22:29:42 1995 Return-Path: Received: from eklinedi.async.vt.edu (eklinedi.async.vt.edu [128.173.23.94]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 14 Jun 1995 22:29:38 +0200 Received: by eklinedi.async.vt.edu; id AA02807; Wed, 14 Jun 1995 16:29:38 -0400 Date: Wed, 14 Jun 1995 16:29:36 -0400 (EDT) From: "Evan M. Klinedinst" X-Sender: eklinedi@eklinedi.async.vt.edu Cc: crossfire@ifi.uio.no Subject: Uh! In-Reply-To: <199506141817.LAA27109@soda.CSUA.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Uh, how do I unsubscribe from this list? Evan Klinedinst CS @ Virginia Tech Virginia Tech Hokies-The NIT champions!!!!!!! email: eklinedi@vt.edu : eklinedi@csugrad.cs.vt.edu Internet: http://csugrad.cs.vt.edu/~eklinedi : http://eklinedi.async.vt.edu From crossfire-request Wed Jun 14 22:05:52 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 14 Jun 1995 22:05:41 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id NAA21455 for ; Wed, 14 Jun 1995 13:05:36 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma021382; Wed Jun 14 13:05:21 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA03459; Wed, 14 Jun 95 13:05:14 -0700 Received: by pluto (5.65+/1.5) id AA16065; Wed, 14 Jun 95 16:05:07 -0400 Date: Wed, 14 Jun 95 16:05:07 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506142005.AA16065@pluto> To: crossfire@ifi.uio.no Subject: Coding style suggestion Status: RO To the Crossfire coders: Recently I've been delving more and more into the code and I'm pleased to say that in general it's in better shape than the typical "many-developer" public domain game one finds floating around the net. However, I'd like to make one suggestion for a change in coding style that I think would go a long way towards improving Crossfire's long term stability and the ease of adding new features. Currently there are many assumptions about the contents of various fields in the object structure. Access to values is (by and large) done through direct use of the ->, . and = operators. For example if you want to find out a players strength you write something like: foo = pl->stats.Str I believe that it's better to use a method to access object attributes, and not having the luxury of C++ operator overloading we're left with using macros or functions to implement them. I would prefer to see something like: #define get_player_strength(PL) ((PL)->stats.Str) foo = get_player_strength(PL); This has many benefits, I'll try to outline a few: - If the object structure changes (say we introduce a new level of structure hierarchy containing the attributes, so the access is now object->stats->atts.Str) you only need to change one macro in one place, not numerous individual lines of code. - If you actually need a method you can implement one by swapping a function for the macro. For example if we wanted strength to decrease with a players age (say 5% per year over 50) you could simply write a get_player_strength() function that implemented this algorithm. Otherwise you would have to add another piece of code after each use of the Str field. - A lot of object types use the fields in strange ways. For example runes use stats.Cha to determine the chance of their being seen. This code would be much clearer if a macro called get_rune_visibility() was used to access this field. - It's easier to turn massive amounts of debugging code on and off. For example you could add a check in the get_player_* macros to ensure that the object passed in is in fact of type PLAYER. --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Wed Jun 14 20:59:12 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 14 Jun 1995 20:59:06 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id LAA07987; Wed, 14 Jun 1995 11:58:54 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma007912; Wed Jun 14 11:58:32 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA29474; Wed, 14 Jun 95 11:58:26 -0700 Received: by pluto (5.65+/1.5) id AA16048; Wed, 14 Jun 95 14:58:20 -0400 Date: Wed, 14 Jun 95 14:58:20 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506141858.AA16048@pluto> To: peterm@CSUA.Berkeley.EDU Subject: Re: An "easy" MU/Fighter balance fix? Cc: crossfire@ifi.uio.no Content-Type: X-sun-attachment Status: RO ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 36 Peter, you write: > > [my suggestion for new wc adjustments deleted] > > [your response/counter proposal deleted] > > Additionally, I'm prepared to back up my 4-class proposal with coding. > Many of those who advocated having a multitude of skills were willing > to "help", but I didn't see any volunteers to be responsible for it. I don't know whether your final comment here was directed at *me*, but I think you're off base on this accusation. The "game play" sections of the Crossfire code (i.e. everything not relating to graphics, file I/O and server client stuff) are really pretty simple-minded. Doing work in this area goes quite quickly with relative safety in comparison to the other coding work. Given this fact I think it is more important to come to a consensus about how game playing should be changed than it is to find people to do actual coding. In fact I think the tendency to code first and ask questions later leads to generally poorer code, the zillions of conditional compile flags we now suffer from is one symptom of this. BTW, I happen to have already coded my suggested change, you'll find a context diff file for common/living.c attached to this mail. However I wouldn't go so far as to send this to Mark for official inclusion until I felt like at least a plurality of this list agreed with the idea. --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: liv.diff X-Sun-Content-Lines: 73 *************** *** 718,719 **** --- 718,776 ---- + /* Adjust the player's weapon class based on their + * level, class and attributes. In the future other + * adjustments could go here. This routine simply + * applies a modifier (rather the setting an absolute + * value) since fix_player() has already calculated + * ring and weapon bonusses. + */ + + #define op_is_player(OP) ((OP)->type == PLAYER) + #define get_player_level(PL) ((PL)->level) + #define get_player_class_name(PL) ((PL)->arch->name) + #define get_player_strength(PL) ((PL)->stats.Str) + typedef char *String; + + /* just in case there's no math.h */ + extern double floor(double); + + static void + adjust_player_wc(object *pl) + { + int level_wc; + double class_mult; + String class_name; + + if (!op_is_player(pl)) { + LOG(llevError, "adjust_player_wc called for non-player\n"); + return; + } + + /* original algorithm from fix_player(): + * op->stats.wc-=(op->level+thaco_bonus[op->stats.Str]); + */ + + /* get multiplier for class */ + /* TO DO: use some field in the arch? */ + class_name = get_player_class_name(pl); + if (!strcmp(class_name, "wizard") || + !strcmp(class_name, "mage")) { + class_mult = 0.25; + } else if (!strcmp(class_name, "fighter") || + !strcmp(class_name, "ninja") || + !strcmp(class_name, "warrior")) { + class_mult = 2.0; + } else if (!strcmp(class_name, "barbarian") || + !strcmp(class_name, "viking")) { + class_mult = 1.5; + } else { + /* thief, priest, elf, etc. */ + class_mult = 1.0; + } + + level_wc = (int)floor(class_mult * (double)get_player_level(pl) + 0.5); + pl->stats.wc -= (level_wc + thaco_bonus[get_player_strength(pl)]); + + return; + } + /* *************** *** 894,896 **** op->stats.ac-=dex_bonus[op->stats.Dex]; ! op->stats.wc-=(op->level+thaco_bonus[op->stats.Str]); if(op->contr->braced) --- 951,955 ---- op->stats.ac-=dex_bonus[op->stats.Dex]; ! ! adjust_player_wc(op); ! if(op->contr->braced) From crossfire-request Wed Jun 14 20:17:59 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 14 Jun 1995 20:17:55 +0200 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id LAA27109; Wed, 14 Jun 1995 11:17:49 -0700 Message-Id: <199506141817.LAA27109@soda.CSUA.Berkeley.EDU> To: woodruff@cadence.com (Ken Woodruff) cc: crossfire@ifi.uio.no Subject: Re: An "easy" MU/Fighter balance fix? In-reply-to: Your message of "Wed, 14 Jun 1995 13:09:49 EDT." <9506141709.AA15664@pluto> Date: Wed, 14 Jun 1995 11:17:48 -0700 From: Peter Mardahl Status: RO In message <9506141709.AA15664@pluto>, Ken Woodruff writes: > > >could introduce a multiplier based on class, e.g. barbarians improve 1.5 wc >per level, warriors 2.0 wc per level, thieves 1.0 wc per level and wizards >0.1 wc per level. > >Comments? I'd have to say overall this is one of the more conservative >ideas in fixing this problem. > C'mon, this has been the most divisive issue ever. *I* think that fighting experience should improve your fighting ability, MU experience should improve your MU ability, clerical experience should improve your clerical ability, thieving improve your stealth ability (level). Why should smacking something with your sword improve your spellcasting? I like the 4-experience class (cleric, MU, fighting, thief) because it is simpler in terms of player-bookeeping than having 100 different skills, simpler in coding, but DOES make it so that you don't become a better fighter (go up in fighting levels) by frying monsters with fireballs. But I think having varying wc/level makes sense for different RACES. Why shouldn't each race gain fighting ability differently? But this boils down to stat differences. I'd actually like to see "classes" go away and "races" dominate the game. Trolls, humans, elves, gnomes, undead players, fireborn, rather than: fighter mage cleric ... My philosophy of the game is that you are what you do: an elf might have a predilection for wizardry (stat bonus) but if instead he slashes things dead or shoots them with arrows, it is his fighting which improves and not his magic. The four class idea also brings balance to the game easily: you simply make it harder to advance in MU levels. Additionally, I'm prepared to back up my 4-class proposal with coding. Many of those who advocated having a multitude of skills were willing to "help", but I didn't see any volunteers to be responsible for it. Regards, PeterM From crossfire-request Wed Jun 14 19:11:59 1995 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 14 Jun 1995 19:11:58 +0200 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by maud.ifi.uio.no ; Wed, 14 Jun 1995 19:11:54 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA12379 for ; Wed, 14 Jun 1995 10:10:32 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma012239; Wed Jun 14 10:10:02 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA20472; Wed, 14 Jun 95 10:09:55 -0700 Received: by pluto (5.65+/1.5) id AA15664; Wed, 14 Jun 95 13:09:49 -0400 Date: Wed, 14 Jun 95 13:09:49 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506141709.AA15664@pluto> To: crossfire@ifi.uio.no Subject: An "easy" MU/Fighter balance fix? Status: RO Currently Weapon Class (wc), used to calculate chance to hit (anything else?) improves (by decreasing) with each level. Would it be possible to change this so it's dependant on class, i.e. for fighter classes it still decreases with each level, but for magic users it doesn't? This might go a long way towards improving MU/fighter balance without drastically changing the game or the code. If you wanted to get sophisticated you could introduce a multiplier based on class, e.g. barbarians improve 1.5 wc per level, warriors 2.0 wc per level, thieves 1.0 wc per level and wizards 0.1 wc per level. Comments? I'd have to say overall this is one of the more conservative ideas in fixing this problem. --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Wed Jun 14 15:42:12 1995 Return-Path: Received: from fu. (fu.bekkoame.or.jp [202.11.252.7]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 14 Jun 1995 15:42:05 +0200 Received: from [202.251.251.213] (ppp3_213.bekkoame.or.jp) by fu. (5.x/SMI-SVR4) id AA00542; Wed, 14 Jun 1995 22:35:41 +0900 Date: Wed, 14 Jun 1995 22:35:39 +0900 Message-Id: <9506141335.AA00542@fu.> To: crossfire@ifi.uio.no From: nor@ppp.bekkoame.or.jp (SUZUKI Norimiti) Subject: please add to me the list Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.7-J12) Status: RO I would like to join the video geme mailing list From crossfire-request Tue Jun 13 05:35:47 1995 Return-Path: Received: from bach.seattleu.edu (krisb@bach.seattleu.edu [199.237.224.11]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 13 Jun 1995 05:35:45 +0200 Received: by bach.seattleu.edu (4.1/SMI-4.1) id AA14623; Mon, 12 Jun 95 20:35:33 PDT Date: Mon, 12 Jun 1995 20:27:28 -0700 (PDT) From: "Kristofer M. Bosland" Subject: Weird Bug To: CrossFire Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I am running crossfire 0.91.8, and I happend across a weird bug. I noticed that make install doesn't create all the directories that dangle off lib (which I think it should) and crossfire itself doesn't create them, but it complains about them. I ran crossfire -o and found all the lib directories and added them. The next time I ran crossfire, this is all I got: obie:~/crossfire-0.91.8/bin$ crossfire Welcome to CrossFire, v0.91.8 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. obie:~/crossfire-0.91.8/bin$ crossfire -h Welcome to CrossFire, v0.91.8 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. obie:~/crossfire-0.91.8/bin$ crossfire -v Welcome to CrossFire, v0.91.8 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. obie:~/crossfire-0.91.8/bin$ cd As you can see, I tried to run it several times, and this header is all I got. It didn't bring up a window. I also tried -o. Then, I deleted most of the directories that I created (all except lib/players/) and it started working again. -Kris Bosland krisb@seattleu.edu From crossfire-request Tue Jun 13 01:38:11 1995 Return-Path: Received: from eklinedi.async.vt.edu (eklinedi.async.vt.edu [128.173.23.94]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 13 Jun 1995 01:38:07 +0200 Received: by eklinedi.async.vt.edu; id AA11031; Mon, 12 Jun 1995 19:38:20 -0400 Date: Mon, 12 Jun 1995 19:38:19 -0400 (EDT) From: "Evan M. Klinedinst" X-Sender: eklinedi@eklinedi.async.vt.edu Cc: crossfire@ifi.uio.no Subject: Re: TODO list (long.) In-Reply-To: <"2856 Mon Jun 12 15:47:34 1995"@bnr.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO How do I unsubscribe??? What address do I send mail too? Evan Klinedinst CS @ Virginia Tech Virginia Tech Hokies-The NIT champions!!!!!!! email: eklinedi@vt.edu : eklinedi@csugrad.cs.vt.edu Internet: http://csugrad.cs.vt.edu/~eklinedi : http://eklinedi.async.vt.edu From crossfire-request Tue Jun 13 00:37:44 1995 Return-Path: Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 13 Jun 1995 00:37:41 +0200 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA14538 (5.67b8/IDA-1.5 for ); Mon, 12 Jun 1995 15:10:29 -0700 Received: from foxtrot.rahul.net by bolero.rahul.net with SMTP id AA18113 (5.67b8/IDA-1.5 for ); Mon, 12 Jun 1995 15:10:29 -0700 From: Mark Wedel Received: by foxtrot.rahul.net (5.67b8/jive-a2i-1.0) id AA14533; Mon, 12 Jun 1995 15:10:27 -0700 Date: Mon, 12 Jun 1995 15:10:27 -0700 Message-Id: <199506122210.AA14533@foxtrot.rahul.net> To: crossfire@ifi.uio.no Subject: Re: TODO list (long) Status: RO On Mon, 12 Jun 1995, Kjetil Torgrim Homme wrote: > | Also, throwing boulders might be a problem, since this could > | trap players in, or make some maps easier, as the boulders are > | moved to a place that they normally could not get to. > > The player should not be able to throw the existing, 1000kg boulders. > Make a new archetype. My thought on this would be it should be a consideration of strength. A 15 strength monster should not be able to throw this, just like a 15 strength character should not. But if a 30 strength titan can, then any 30 strength fighter/character should probably be able to do this. The exception would be for the case where the object being thrown is as large as the character (ie, I don't care what your strength is, because pickign up and throwing a 6' diameter boulder would be very difficult.) >>| - Fix bug that makes game crash on HP-computer (hplos) if it can't >>| fix the font. >>| Anyone know if it still does this? Does anyone even care? >> >>hplos.ifi.uio.no has been disconnected for a long time. I don't think >>it's been compiled there since 0.87 or thereabouts. Delete the entry. > > Er, please don't delete the entry. There are people that still have >to use HP with fonts. Well, I have no access to systems running hplos. As such, it is unlikely I will ever fix this problem until I do get such access --Mark From crossfire-request Tue Jun 13 00:06:24 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 13 Jun 1995 00:06:19 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id PAA01411 for ; Mon, 12 Jun 1995 15:06:04 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma001380; Mon Jun 12 15:05:48 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA18010; Mon, 12 Jun 95 15:05:41 -0700 Received: by pluto (5.65+/1.5) id AA13605; Mon, 12 Jun 95 18:05:43 -0400 Date: Mon, 12 Jun 95 18:05:43 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506122205.AA13605@pluto> To: crossfire@ifi.uio.no Subject: Another approach for starting at levels 1-10 (LONG) Content-Type: X-sun-attachment Status: RO ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 40 This mail includes a compressed, uuencoded map for something I call the "Experience Factory". It's basically a place full of helpless creatures that are overvalued in terms of experience gained for killing them. The premise of answering questions to show appropriate experience (which I suggested but no one else really seconded) is maintained. There are three example questions implemented, there's space for a total of 12. If you answer all of the questions, kill all the creatures, and follow instructions properly you can end up with half a million exp. points (i.e. level 11) starting from just a few hundred. I placed this map in the city inside the unused guild building next door to the Bank. If you don't put it there you'll have to fix the door back to the outside, which currently returns you to that building. I tried to make this map a little more interesting than simply bashing as much as possible as quickly as possible, and have taken pains to remind the player that cheating isn't generally condoned. I imagine the perverse sadists among you may actually enjoy this map, I hope some of you will be horrified or at the very least amused. Note: the unimplemented questions all have answers like "answer_N" where N is the number of the question. If you want to add your own questions you'll need to edit the map to sync up the question cards and magic ears which listen for the answers. --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: efactory.uu X-Sun-Content-Lines: 185 begin 644 efactory.Z M'YV08>2,00.B31@X"MR$:5,&1!DS8<;0>2,GCX(V<\XH&"*G3)B)-F3!D78]ZT44#D M8QF11N2D :&DCAL0('* B%%#1PP;.FK V)HC1PT%1,E@U(B'+%HW9!0$'%@P MS)DT8[Z(">/&39FX:>4*)(A3IQF3%-_&G4OX3A@V;+[(D"Q9L6"ZAS;NW[U\%GF. '@SBCF/(E&-\49UZ-5V#H_7R]1O7LPS;A'-J1MP9 MQ._ H5T_CCRCLF_@HO'J-MT;Q SHF3667G\@V."> M@)RM)R& K=7W17._>7:A@:&=1QI_U=TPX7 5>F8BAN!%)MZ"*C:X'W7KX7 B M?#5BIR&'.6(HXG3J>9;#C0,*J6."+Y(WI(_ZC4AC:C 0F>)64;*XXWTQ5 DB M:S\^6%T,JK'X7I%;A;DE?4C.!F.9,CH9Y%;'G1D@BMO!>21L/*86YV)<-@DD MA#%T)V=K8TX9Z)TNJDG>H4PZ2.)Z,<@W:'9D1HJH@HM*RN=M?GH):8&;SHEC M:J >F&&:XGTJ96)MF1GJJ>&I^5NK;?X9%ZVUB4DAJY_E.B@9CLEAQA=WI*%' M0@LU!,5!88 P11MU"'M11@H 81 ==/$UQQTP?2%A$780!<(1 9V1+!N$UL$& M&6Z<0 <(8C1$!QIIS '"&#R5P48(("BVE@)HP/$9&0M]9I5=9W0TQQQIA/M9 M&7@(7,,-.$2)ZV=LE!$NNF+5ZNG%>YI*:84@7_KBK+T:Y_&C%POZZLB\DN>R MJ6V\4<<<92#+$ A-R#&'"R!$5:\8%OUK[4=TJ:# %''44489:[C@+[40"SP# M#C6T1W ;G[6LP!QP/$T&""W X()8,*0=9<8;@]!Q4')4E(8;9U 9Y<%G)%S& MP@TWI%IH:Y21QV\*[5R$$2 L(?AG<[ 11AYSU_W0%_2>@<:"@34ZHWH7:RIR MH3&OYWER&IZL0.\#=W\%P@3@7!&&>\R0T<:,@<8$1J:?D71"@X!WR] 3)R< &8 M7)4ZSJ7L0R]SW>E>:#)9S9 \,*19IUB6LA5-2H87\^&K:J:_\#G+@ %Y%Q/2 MP+N,H25X,;A!#'Y3/-4$\6MAVU_9SJ:VM#U/8]%[6T"J5[5,8P[AG MJN\1+EGW&E_YSO>XR#ED6/2;(_SD%\?VE<]^5XD7"/0WMO[]+X #!$$!#YC M#BZE@2!X8-BD,L&&&,&"%,$@2#8(@@XJY6=3T\@("6A"%*H03);1G)M.@R!;[T MCPA*F5L:YAB$.W@R)R$(I>\>!L5(4;%@5M0E%I6WQ>9Y$7HEI1CV\H:0 M:JG(:BD;E+$4E[=*&2I?B:.+[?17PC3B$]8%@BSH*V,Q"1@W!78#&WR3:^%< ME&J2IT7F=7%M8$RG JC'SNN]]*QJ^OKY[0T M#Y]1.0^!OD M0?F7T$,RE( /1: "'XD&!T*0DD6Q)"8KHE$Y<-*3']2F2$O805.>-',IW:'J M=!JRUKW4IY7]#DTK@UF':9K/IZ;EE*,F MFZE5^1)2HSLM7X+9AB_0X3'U,LAK=9I;V6XNEXMBW7> J%/EHBE6-24M5SS; MELQBAKG611!T.:LR5=IJAAUZ&"]'6UU(02=A3OG"&$QRT,H0$[TOB1!XS9L4 MTTAD?SD,D61=&-[L$NJR*GN.E1(DF^N45\"1G2U_UQ-;40WHP.7!$'S+H%[V M_L6]<)RPV^;+G:V6SR_W'9MS":+2R8:WN XF68#Q,V#8%)C#+$[P<7,:WA'_ ME[PKMO&$*_R&]M:S(1IN#X3/4E\0OV1L*([.*FEL(=O".+^:)?"&GDS=%0OQ M

-K8"M[V+Y'CK",EPSC6;H4Q^%U\TRE7.8X5SF\ MNWQS3U><9U-UV<)DP/#.-(PR/)_9R/OS;XD7#"4G0SA+EWKQHV6J7P7G,KP_ MU?.#5YQI/X^9PE[VL1$U'$Y,JZ;(90BQ>(>XWTM#RK\PBR6F8;W90K_ZSI!J M\(WWC&E=FV0,@0MT,"GRFWRBE9]^]*=&LF S$/AE?\VZ)UU!\(:P765> 1UV M"K7Y:%TOVM6I27*L86RI%D=F/.1.\K>93"I'<]K&+=K0@AYMXW7/4-?C;@N^ M:WWO*E_'5YI6\;]7K"0FRD0:0;3%+3EX:R,4Z8A$0 B7?^F;OA].=9JA M3!>&G<%\Q&S:WEK[1S@X#FYQ^9?("^C:AX.4+>4!>,%GW&\$!YQ7 U=TJW,Z M<'PSM^>U.OA:J[7,A;MA6]TZRQ BKG&*JX5:%^\PJE5M8X^#'(XK)_E53!Z1 M@*2<6EEO.:@L'G,UL]K2/!>=NP>N[IW7?,,\W?3 Z^TGH2<<6T9'NL/;L_2X M-9W;92=RQE6=9*L;,>PE/[G7AXYX-WQ!4V2?N[^;''>!4W[-WXTZ"+:\7 / MG//&S8O=J74TO#O+F0F%9AND.<>^2YP.3H_\>DPT]33KVO A=QK+$]]U.7Q= M(U'0O=:MHP,%*. *N7M70"%)S#<@L(%;9:)G_@C)I!SS761PFK,I,B\%.-]9 M29&#&WX ^,]/WC-R%NV>!Y[^/J'][7U6O]S7$W_W2V?T&BD]7082AKE!W.\3 M5W[T=V@:EVBQDP8?=WC"YUH@P'4H-W3!-W(,* /%=WS)!P++UU<->$S;0A%C M\VQ#@5#]4FWB DGF\A+V\GU3$'[C)X!&XET?4W:05GDX%U/GQR8T&$L#UVF5 M=G\!,73Z1Q!'0!%K\'^O%WM0)X.G-GAIQD*A@7M8MX"\]X#_$H&[=Q4Q4('( MEU !U01$> +V$B\%U$@2!!?D]W)OQX/VQV::-T5K=VOFIB9EMH,Z]WYMZ'.> MEVO0@5J\]07) QESD(;>YG9M*&X_AUM[N%NJ]8=L$(B%>(/3E8-I"&_\UH9T M9XRR& UE(JW.(B@J':2J(K$2$NU&$ZE^(DT9XS^X6ZE2(G) M.$/16&6ER'$IQBO7^(NVN(TPR$.E"'K9N(FSQXW*6([?.%FEV'[7!6#K:([4 MV".Y"(X#6(RW6'_/E2C 6(KX2&*$>(LS.%Y[MHJ4%F6QDBK.2"76""FLV(Z] MF!H-Z8_#J"?0"(>#\FO!]@7:-E7H8T=IE6Q#QVQUX&S*$VUOU3\D>&U\I&U( M"'.K6(?-")"\.)!ZB"%\N(AA XCQ"%H+&6X5Z9,VJ8B]Q8B.")#,R(8 "6_, MM8K2N%THPY15II0 UI3ZR%V7&)-G(8J=AV-9:8JL,10?@09B(!5T Q,SU)41 MJ62NV)6PQEQL"1T8>6$;>58>.2R59;K M 9-(V94SN6F*>5YIX'L9XX=T(!!SU!:-F8XNU)6&.)7'^"IQ*6R& ME0=%F9NVZ2'NUI786!)O &QR&9ITN4^48YJ5D9HCN9I^*0.O68*#21&%:9F7 M=W98B8X"R9CD^2H=<1@:QRM=*8YJ&8-=R8[C:)CH!Y?-F9%S:6QU.9V6LR#6 MR9=CXY29OR*)Z)68_EJ6)=V8_OR4-H69 .N6<3RHTH9QV@IL6^3*U-!D96J(SMZ \2:(MBHS;%4YH*8SC"90-RIZ(&(=) M0I];<91KJ2HNNA54*6\R"J3S.%G+^:%)VHDSM)SVUA82HI45NFE1ZI7YB"E- M:EX;FE-5VI8 UJ7P"*6'6655NI@J5J9A*E\=MJ59ZAF;B6-5RHG3**9N2J:W M>:.Q5*5#NJ-T"G='ZD)5FJ3,%:AI2JALVJ?NJ:3G.6JBP M&I":Z*BTRJB66F95>JL]B)2[ZJ&#RI"9ZH:2JJ*GZ&)3UJ?$^J>YM*MFRBO. M&CN_94 Y0TQ*\ :+(P1UP#MA8 9UD!1#US- HZW"N3AB\ ;SLH&SDT 4@8%TD$UHJ*PTZJLYBJ>V6GC3ZC1&% 3H,@0' M43[)1"WB"@(,ZSXLD:YIQJ[+%P9XL#?PRD2#U%K7HB^>D11C2"]+1)NTW 8S4S<+4S@#)#JQKH)#U5-K1>BF-@:Y_."9H4 M(9K'QI]X&9*JJ3Q^20,$&IOVPI* -[8^ZXOV.+2Z9K3U,K7$Q+01\;1IQK=( MZQ=)]3M/)# RL+B,.T-Z^T5MTS%W6Z=YVYFF\ID:"9WZ*9UW.67_B9V+XYHH M"9O8-K>SR;)#Z[(\-+0QNV>L"QV$Z[=+V[2"NS^Q:[A4F[@]B@.18B-"RR!= M*[G,FE-#*Z@ 5KQDBY^:VY&<2YV_\;ENNSC:.;K<::#;AKKAN:*N.+0Y>[R+ M&AJW:Y9_2[M0&[Z'NU19@0--)2&_&R/!2Z$2&9-#2ZD?.K_)^YQG&YVDJ;;^ M22U[";JI$;>E"P)TB[V1.KR.RZ"UVKZQ.BB&]Y_0,H9NSLZ_U]5O29#TUTQ$.<4R>4345%5A20P4) M!4D>,8:[U1HC=\$P''Y2$4P^$TBBY,Q+0_@Q4*BR[SDDA" MG,)%K#_SJDC)\C4+]7W?,P*],4(I #:]E$5 MEX1#"Z%/^JB-5KE[#%04\06(L0:VN+51,L&KQ8$@ +\1.EE;"ZS>&Z(84J]O M(,@=(11&Y,$%Q!,2X5J!N$=^-4EE2$&7A%&$Y1B!B"\NL3]J<#,!I,(6"Q/V MDA*!0\)U #18,05,5 =0.S<1=17?!TE;M4&QW,)UH\/7=\'RRBUC6!^!^,L: M.$(7! )F/)+% AD)-#=CXX:-UX"*YWM1'$D14;3='!?5C"['M ;2W&S-TGBV M/ 5A$P;H/,TQP7 P06W;RIQU0 :VG 0(-,U G#-"K'%;K&VDJH%!\3\*4,[4 M!IL][,\$I4B.4P>6@ZH,I(&[:7)@=2^5;$ P/#<,,Q0*8 ;[VA'!0@8IB$!# MC!?J8C/V(A=$%,(G[1!_%YWOU/,TG8,WFPLO00A<9LS R#QVGG-+D]ZFY;6W@(J&Q,D<,YK(&-W6X8 M\@;PK&WZ"P(OX+1TD ZQ5&4Y. M/N-WRMHXOJ>*,D-9;N7(:8\XOJ1SVN39VZNNB./=BV-HKN0Q4N0):N$W_N92 M;DMD?L 3'H,X#J$?FN<'^'%?\+!LU:ZC^M@:*")R5<\448:LFE>ORN=NWL=8 M;H-Q*!M"5N<*^>@X2+ \GNEWSD,XOJR13I&3_GA<_MGQBY2??N2EOMI^=MWK M8A!5K;2#MMN!4P:3!(1%!P*S73"V[10Q@?"\9HSN><>U;+'$>6'PB ML.NUC:ZW[0(BH-YUK!%*U3RK[MJ87FZ:;NGZ_BJ_)0:166:?KKJ3]>FM&^<8 M#J.66ND&7V5ZSEQZSK-X_(]#4N,?6O$Y3C!Y([YPU 0;!(8$C#!F63Q#8NC( MH[@*X,'OHAI7$%#7\1&_!6PA'C94(@,FTA88GY9YC/% OFD\?[]F*P=HNY^= MFY?^V[9]N3AP2[T%:KH'RK(_+ZL8K^HXO^3HJ<15OZ9,CO%/[O-1SAJ8FY_, MN[^=BYI'?YW1RQT"W)W7.^\SQ/4.?^5PKF(8KYOZTIN_.2QC61,IP1=&\?9R M;^8QB/'&BV.$#_29F[^;2_;.R[9HG_2^L?;6^ZJ'+_7?V]E>W^:#LA#J D" MK_F=/ED8[^( -OJ(+_:C>4?\JQK0"_E;(?E.W_:8_?ED;ODON.\8/_&8F/.* M?/&2KO *@C*\'_>0C/O":OLC:ORB#OPHFJR:NORA[T(Y3_7/C^_,O^59;_W1 MGTLYW_5T+^&XNN/5W^_:._@5/HJ\DO-#VASAI/Y5QJN8KV+P?Z7-46;S?^JN M"&D6SUSZG^/QQJ<*JP M\E\#]'X0\.M=*05X 1E@X(M_&? 9Z2CL%P#]U/;+*?VO\.V9%)BF6*"LZG]I M;@4VP)TU 6>@![1S#]"7-$ 85P/E7"N*0?WOX0&8(-@"&Z#NBTG][_[9. /X M^VC602)UK:(!*L$\E@0=&8ZI@C"O] @!XF%1Q"#47 /_L"5 M(@4/'A-,>$ZP*MF40OC^K. *]% \2PV%GORW*-P-*A& !@>VD9Y<1\\0!TI%!7^)/1J%1U#T MD,.#:'H2HHU@B.UP )5"2B4/GV'O^3T*H/%\ 1S0+V+B[3N!VA#2[<*.V 3+ MWTJ1*O[P^&$>@SCL$J*)@(G(4%B50O=4$UTA-[N)T3 CWH">&!6+'U DBM!O M*+*)L#CG*%U0-(6"[RC6I#>X*.*@4/)#]$)?H,"V^!&3VTFL+4$IM?26>G4' MSB+Y2XNT);DD1408_DP'6!12[\\6^A):Y)1N"&+*?YC&$D9&"?-I>(RH>2^[ MS0VUBLBH#!\C$.PODG%,C;I*YX80X""D+>&%^I5&!\AE*F.H 3.C)C-&E=3X M#IO0+,1$JS$;;L9MJ./,XFZD7$QN-1K"F%%CSHMK!#2"1K,,E1D M5#"\J,!-LQK%'+(BC=(Q,1+$)4@;X$-%,1-2.(!$$+D8? M>*5\HYU(CY/P,RHPL;@:(=1WA(V8<3GZKO>HJ68B>KQT;Q#3]#X-X1Y7XQ0< M@*8F-'I%3Y->7F.@"3,:YN;Q1U0R%?\CJ*./LP9#.493M\A">.< M8W\;TD>>1@^I&B5@8VP5UG"E["!+N"0Q!+ (",.";XT<(P(%2!!5> -HX"HL M"W6AZY( KD.(Y[!;N"&/YQE,D'!@3KY'7\F!N^ PIEEA4BJJH8I@#S2B/<(* M^K(!-0 'T #2N"3?U_O+.4Q2-%Z_Z((D!:6,/!1:;PL"'0P!!YS)?C,BWDH/ MZ '/L :8R$MP;DTQ3'K"* $%HH4<&&-PP%.Z@%&I3>"D[J(!5R,'2 @Y62@[ M#%49&^7DJD"N,')&$ 8\82,OD.T$2N"8"(/?#=&5N=(;!BW7)@('Q1IX _5J M71B1O4 TX,4;*!K L"5JRG1X?,) &$ #_"((8$L0< 6L);8LE8BK:AB''" # M;(#6 ">_DD&\RN7!1;K(K-0J7V5[B)5@^>7>X,"QCHHP7=;+0VE^3F*_'!1\ M*[ L#".2$IH(D'E,;.!+2LMA."2>@#C;864 5(X[G"$Q(6:+C&\*H%):,X; M+W3="> ::PR#I(&VD <.3@I:%_[*[9E*<1D#S (,V(^(\E'Y2:YB1U+;/ $? MQ.1P) ZEU^$F1]%#*?R2/0[+F,D#CR2QK'W!<> (P2NH-*$#_Y$#.$&X&)%B M$4RXQ=BH&0TD5?TRG* PL\6TM!'0)+ZQ)KY7$"*FK@,!N<-AT &<@*YJPDX@ M"@PDHI&;&69TIN)PE2729U*G MF4$O :2B+(H)D,[%S .)&W>0(Z2.EC-V;! CDYO/\BT,2N>P@'JD]M1RAQ)WB$ A^3SGU!.U?CD0NJ\@2 MYL\1"(PL!29$@K-(?QK*\-<<2&, ?8&[2( FRL)( OTG:TR?*' 9*=!,1$"A M8'+CE=S30U:CD[A!!^6-[*"'TAN]01':*POH#2&A&11_;L'H M_;TC#BHT=9P)A:$UE KRHPD:\2;@#D6@D%,]GM @2O\LJ .EG !4*6[!500) M?:@23:$1E$.RT)=T*6[H!86>W'"EK"+5N$4O!1T49*I!I,2;&G!*HDH7!:(V M:HD*P@W80%?1_8RB0E(@^A*H- (G@P$]?ZP!X-TGY&)C]&C9NB%H"3KXT6 # M2 =H:!BD?%07'M+/5$@QZ"+=HRC0.$4R1MHJE),@I:2($?29"D0:26LH)VVD M#>Q5?-)*2D0)PBC-I)QNDV+2Z4(6\^@JG5$)X0T<,KRFR$XI*TUNAJQ1TM)+ M"DE!Z8H[E--1_N%+RH"B;HB3&H"[RA(F4_YY(Y=I< 13)Q&:>M"H(DV!J2(5 MHJT"33%3:GI-HR=MB5/*E#?^OP8*3E^@G@JGQ;)7*L!S:D[+'#;="H9JFAI3 M=^I-/625BH'4\9ZV0'W:3N'CT,14VW2>^M,.B5PX%3H-I0RT?QK4?NHXZ>.N M&I 3\*&^OU]U4)>ACENG3Q0PVE,IRO]V%6.<<@(5BQ)4%!BMHNGT3*C-]*1J MU(*Z1O]I2]5Q7W1!B%$-049/2C9]J5009E54+8>0X"D>K:?(!9_*/Q?J/+>" M>Z*"6\L2)E5&::]:3AH0;!TD7-R0I.H&.@@"B9\KQ6Z]0:WZ*K!G^> _4W5, M5=7O@U5IR^,ZB6<58#;5\E$LBE(4\45C]:J^O]2E5'FC5TUB(2RLUJFX:@*A MJ%[MJ\JS5;PNIJIUZLM?/0M\M:QZ2.2%5NEIT5JK< %B_%4)D5CGZ@KE?]P+ M=D'63/97341E?8'VJ[$.U%B 6PVMP?&.U=6?:"HR&!O[ @*.*/P/7Z): M06LIY8ZT];9F$#G0!O9>664?VXVRRY(X7I#/IUB MK+-2=+-$%3L;2V>IO8".6[9Z2M=4)V>UWXSULA*VRXK91 MF%># :[,_U<9& )VHM*&4ACPPL, end From crossfire-request Mon Jun 12 23:39:33 1995 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 12 Jun 1995 23:39:32 +0200 Received: by utu.fi id <172940-1>; Tue, 13 Jun 1995 00:39:27 +0300 Subject: Re: TODO list (long.) From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no (Crossfire) Date: Tue, 13 Jun 1995 00:39:26 +0300 (EET DST) In-Reply-To: <199506121032.AA21575@foxtrot.rahul.net> from "Mark Wedel" at Jun 12, 95 03:32:00 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Length: 409 Message-Id: <95Jun13.003927+0300_eet_dst.172940-1+3@utu.fi> Status: RO > - When dropping items onto objects that blocks view, make them "fall beneath". > Is there actually any one to do this? I can't think of anything that > actually blocks line of sight that someone can stand on/drop on object > on. Think of the earthwall like structures that you can walk through (false walls). Just dropping arrows or anything on those squares lets you see over all the blocks. From crossfire-request Mon Jun 12 21:58:49 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id ; Mon, 12 Jun 1995 21:58:04 +0200 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 12 Jun 1995 15:48:02 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 12 Jun 1995 15:47:31 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 12 Jun 1995 15:47:00 -0400 Date: Mon, 12 Jun 1995 14:47:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.852:12.05.95.19.47.31] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: TODO list... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"2856 Mon Jun 12 15:47:34 1995"@bnr.ca> To: kjetilho@ifi.uio.no Cc: crossfire@ifi.uio.no Subject: Re: TODO list (long.) Status: RO In message "Re: TODO list (long.)", 'kjetilho@ifi.uio.no' writes: >| My assumption is that the typedefs are set up so that the actual >| variable is at least that many bytes. Is there actually any >| cases where a variable is assumed to be exactly a set number of >| bytes, and will break if it is more bytes? > >With careful coding and use of offsetof and sizeof, there should not >be. Using fread and fwrite to store/send structures is out of the >question, anyway. > >| - Fix bug that makes game crash on HP-computer (hplos) if it can't >| fix the font. >| Anyone know if it still does this? Does anyone even care? > >hplos.ifi.uio.no has been disconnected for a long time. I don't think >it's been compiled there since 0.87 or thereabouts. Delete the entry. Er, please don't delete the entry. There are people that still have to use HP with fonts. >| Also, throwing boulders might be a problem, since this could >| trap players in, or make some maps easier, as the boulders are >| moved to a place that they normally could not get to. > >The player should not be able to throw the existing, 1000kg boulders. >Make a new archetype. Huh? I didn't know players can throw things much less 100kg boulders. >| Also, how much damage certain thrown objects do would need to be >| worked out, and perhaps an entirely new entry in objects would >| be needed (a thrown dagger should do about normal damage, but a >| thrown sword probably should not. > >Add a number for how likely it is to do damage? A dagger could have a >200%, meaning it at most can do 200% it normal damage, but on average >100%. (The 200 means pick a random number from 0-200 and use as a >modifier.) How about compute the damage based on thrower strength, weight of objects, terrain layout, etc... Use existing modifier field whenever possible and avoid creating field just for throwing damage. If you want to create a field just for throwing damage, how about revamp the way physical damages are done (ie: slashing, piercing, smashing, etc...) >| Likewise, a thrown dagger should go farther than a thrown >| sword..) > >Just make this dependent on weight. Of course, a small rock should go >farther than a bag of the same weight, but I think this is too >complicated to implement (air resistance). Well, why not have a field to indicate 'virtual size'. Or at the worst case, check for a specific exceptions (if they aren't that many) In this particular case, classifying dagger as a piercing weapon has advantages. One being about to inflict a specific type of damages. A rock of the same weight as a dagger _should_ do a different type of damage. >Kjetil T. Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Mon Jun 12 15:26:20 1995 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 12 Jun 1995 15:26:19 +0200 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id QAA24999; Mon, 12 Jun 1995 16:26:05 +0300 Date: Mon, 12 Jun 1995 16:26:04 +0300 (EET DST) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: TODO list (long.) In-Reply-To: <199506121119.26412.gjalp.ifi.uio.no@ifi.uio.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 12 Jun 1995, Kjetil Torgrim Homme wrote: > | Also, throwing boulders might be a problem, since this could > | trap players in, or make some maps easier, as the boulders are > | moved to a place that they normally could not get to. > > The player should not be able to throw the existing, 1000kg boulders. > Make a new archetype. Why not ? I think that every item should be able to throw (hehe, demon lord throwing minor demons ;). If there is used somewhat equation for velocity of object: vel = floor(str/(weight+1)) # 1 just not to get divide-by-zero vel is just the amount of squares the object flies, so for boulder with max str; it's floor(30/1000+1) = 0, boulder is "dropped" on players feet. also the throwing damage can be based from the vel. vel might require one field more in structure, but it can be used on other fun situations. Like in explosion the vel could be added to object, as well direction from explosion center, and object the flies some squares, cause of impact. And massive weapons can add vel to the target. Petri.Heinila@lut.fi From crossfire-request Mon Jun 12 13:19:13 1995 Return-Path: Received: from gjalp.ifi.uio.no (1232@gjalp.ifi.uio.no [129.240.84.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 12 Jun 1995 13:19:12 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by gjalp.ifi.uio.no ; Mon, 12 Jun 1995 13:19:04 +0200 Date: Mon, 12 Jun 1995 13:19:04 +0200 Message-Id: <199506121119.26412.gjalp.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no In-reply-to: <199506121032.AA21575@foxtrot.rahul.net> (message from Mark Wedel on Mon, 12 Jun 1995 03:32:00 -0700) Subject: Re: TODO list (long.) Status: RO | My assumption is that the typedefs are set up so that the actual | variable is at least that many bytes. Is there actually any | cases where a variable is assumed to be exactly a set number of | bytes, and will break if it is more bytes? With careful coding and use of offsetof and sizeof, there should not be. Using fread and fwrite to store/send structures is out of the question, anyway. | - Fix bug that makes game crash on HP-computer (hplos) if it can't | fix the font. | Anyone know if it still does this? Does anyone even care? hplos.ifi.uio.no has been disconnected for a long time. I don't think it's been compiled there since 0.87 or thereabouts. Delete the entry. | Also, throwing boulders might be a problem, since this could | trap players in, or make some maps easier, as the boulders are | moved to a place that they normally could not get to. The player should not be able to throw the existing, 1000kg boulders. Make a new archetype. | Also, how much damage certain thrown objects do would need to be | worked out, and perhaps an entirely new entry in objects would | be needed (a thrown dagger should do about normal damage, but a | thrown sword probably should not. Add a number for how likely it is to do damage? A dagger could have a 200%, meaning it at most can do 200% it normal damage, but on average 100%. (The 200 means pick a random number from 0-200 and use as a modifier.) | Likewise, a thrown dagger should go farther than a thrown | sword..) Just make this dependent on weight. Of course, a small rock should go farther than a bag of the same weight, but I think this is too complicated to implement (air resistance). Kjetil T. From crossfire-request Mon Jun 12 12:32:30 1995 Return-Path: Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Mon, 12 Jun 1995 12:32:14 +0200 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA26082 (5.67b8/IDA-1.5 for ); Mon, 12 Jun 1995 03:32:02 -0700 Received: from foxtrot.rahul.net by bolero.rahul.net with SMTP id AA01099 (5.67b8/IDA-1.5 for ); Mon, 12 Jun 1995 03:32:02 -0700 From: Mark Wedel Received: by foxtrot.rahul.net (5.67b8/jive-a2i-1.0) id AA21575; Mon, 12 Jun 1995 03:32:00 -0700 Date: Mon, 12 Jun 1995 03:32:00 -0700 Message-Id: <199506121032.AA21575@foxtrot.rahul.net> To: crossfire@ifi.uio.no Subject: TODO list (long.) Status: RO This is a somewhat edited copy of the TODO list, with many comments by me on it. Some are just thoughts on whether the features are actually needed, other ones are the fact that I'm not really sure if some things are still a problem. - A flag so that when an object burns it becomes other_arch (random chance?) This is an interesting idea, and would not be really hard to do. Probably the best way to do this would be to use a treasurelist - this would allow the random chance, and the possible creation of several items. However, might it also be a good idea to extend this idea for items that are destroyed other ways? And should this be an object or archetype flag. - Add a ring of warning/ spell of warning, which compares your level with the level of the most high-level monster on the current map. Would not be hard to do. I am not sure of the usefulness of such a feature - the level can mean much less than the abilities and items that the creature has. It would probably be best to add another field to the map structure that the map creator sets - this would be the level a character should be to take at that level. Difficulty is a rough approximation, but since you can get the difficult with the 'maps command, either that needs to be removed from the maps command, or not be used. It isn't always an accurate measure in any case. - Rewrite all variables, using own typedefs of type: int8, int16, int32 : Variables that should be exactly this size. int8u, int16u, int32u : Variables that can be larger to increase speed. Add stuff about this in config.h or other place. (The needed #ifdefs will need some debugging...) Probably will take a very long time to do. It is being used in most of the structures now, but with a bit different naming convention ([us]int{8,16,32}). My assumption is that the typedefs are set up so that the actual variable is at least that many bytes. Is there actually any cases where a variable is assumed to be exactly a set number of bytes, and will break if it is more bytes? - Expand the features of parse_message(): Support for state-variables in messages. Better parse_message is needed. I remember that some people wanted to go to a very complex/external function. If anything, it would probably be nice to greatly expand the features of npc control, so that they can also give and take items. - Fix bug that makes game crash on HP-computer (hplos) if it can't fix the font. Anyone know if it still does this? Does anyone even care? - When two players using pixmaps enters the game at the same time, the first player will be freezed while the pixmaps are loaded for the second. The other players won't notice anything though, so don't know if this is worth fixing. (Shouldn't be noticable without debug option) Is this still happening? Does anyone have more details on what does happen? If the first player hasn't actually joined the game, I don't see this as a major problem. Will probably disappear with the new client server stuff in any case. - Fix throw, and make giants throw boulders (medium size) Being able to throw anything would be really neat. Would actually give a use to poison. How to deal with effects when a monster is hit by some things would be difficult. Also, throwing boulders might be a problem, since this could trap players in, or make some maps easier, as the boulders are moved to a place that they normally could not get to. Also, how much damage certain thrown objects do would need to be worked out, and perhaps an entirely new entry in objects would be needed (a thrown dagger should do about normal damage, but a thrown sword probably should not. Likewise, a thrown dagger should go farther than a thrown sword..) This would open up a whole new set of weapons to be added. - The game can crash when a part of a monster is killed by a fire-wall. (There is a temporary fix for this though, so the chance of crash is small) Anyone more familiar with this? I don't every remember seeing a crash with this problem. Has this perhaps been fixed in other ways? - Debug all use of the friendly flag. As above - anyone have more details on what needs to be debugged? IT seems to work fairly good right now. - Maybe improve the way speed is used on spells (ie, getting disturbed, etc). The new CASTING_TIME options pretty much does this, no? - Is it worth it to make the blocks_view routines more perfect? They way they are now they are very fast, and works 99.9% of the time. (100% if all maps were designed correctly) Is this a problem? It seems fine to me. AT one time, there were different LOS options. - When dropping items onto objects that blocks view, make them "fall beneath". Is there actually any one to do this? I can't think of anything that actually blocks line of sight that someone can stand on/drop on object on. - IDEA: Make spells be objects. One object for each spell you know. Same system for the monsters. For now let the objects be invisible. Then later create a spellbook into which the spells can be "put". Thus knowing a spell consists of having the spell-object in some spellbook. This is already true for some spells, correct (things like fireball, lightning bolt, etc..) Spellbooks already have a use, but I could see something like rings of spell storing. Most every spell has an archetype/ object associated with it. I am not sure what would be needed to do this. - Make a better time-scheme. For instance using an integer as a counter, and compare this to the variable next_move in each object. Thus a float doesn't have to be increased in *each* object *each* round. Of course, to get a resolution larger than 1/x, another variable, time_debt, must be made. Are the floating point additions typically that costly right now? Most machines do have good floating point processing speed. The other problem I see with this is that if you calculate when an object would next get to move, and the objects speed changes, then the results might not be really good. - If an object is killed (removed/freed) while its firebreath (or other objects owned by it) are still moving, the game used to generate warnings. I'll try to make a system that uses refcounts in objects when freeing them. When an object is killed, it's speed is set to 0, and free_object() will decrease the refcount. The refcount is increased for each pointer pointing at the object, ie each time set_owner() is called. When the refcount reaches 0, the object will be freed for good. This seems to be working now. Has anyone seen any problems with this lately? - Use map->difficulty for more things than bonuses in treasure.c One question would be is what else to use it for? Right now, it is only used in treasure generation. - Use X-resources more extensively (colors, etc) This will eventually be a client issue. From crossfire-request Sun Jun 11 20:44:32 1995 Return-Path: Received: from bach.seattleu.edu (krisb@bach.seattleu.edu [199.237.224.11]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sun, 11 Jun 1995 20:44:30 +0200 Received: by bach.seattleu.edu (4.1/SMI-4.1) id AA27523; Sun, 11 Jun 95 11:44:10 PDT Date: Sun, 11 Jun 1995 11:40:28 -0700 (PDT) From: "Kristofer M. Bosland" Subject: XPM Error -4 To: CrossFire Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I thought I saw some people talking about this, but I can't remember what the proposed solution was. I compiled for the first time with XPM with 0.91.8, and I got this -4 error. Does this look familiar? Thanks. obie:~/crossfire-0.91.8/bin$ crossfire -xpm Welcome to CrossFire, v0.91.8 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. Not enough colours. Trying a private colourmap. Error creating pixmap /home/krisb/crossfire-0.91.8/lib/crossfire.pix.1, error -4. Error code BadPixmap (invalid Pixmap parameter) Error code BadPixmap (invalid Pixmap parameter) Error creating pixmap /home/krisb/crossfire-0.91.8/lib/crossfire.pix.2, error -4. Error code BadPixmap (invalid Pixmap parameter) Error code BadPixmap (invalid Pixmap parameter) Error creating pixmap /home/krisb/crossfire-0.91.8/lib/crossfire.pix.3, error -4. Error code BadPixmap (invalid Pixmap parameter) Error code BadPixmap (invalid Pixmap parameter) Error creating pixmap /home/krisb/crossfire-0.91.8/lib/crossfire.pix.4, error -4. Error code BadPixmap (invalid Pixmap parameter) Error code BadPixmap (invalid Pixmap parameter) Error creating pixmap /home/krisb/crossfire-0.91.8/lib/crossfire.pix.5, error -4. Error code BadPixmap (invalid Pixmap parameter) Error code BadPixmap (invalid Pixmap parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) Error code BadDrawable (invalid Pixmap or Window parameter) ... (more Lines like this ^^^) -Kris Bosland krisb@seattleu.edu From crossfire-request Sat Jun 10 22:02:45 1995 Return-Path: Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 10 Jun 1995 22:02:44 +0200 Received: from aachen.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id WAA25078; Sat, 10 Jun 1995 22:02:42 +0200 Received: from chapelle.aachendom by aachen.ericsson.se (4.1/SMI-4.1/AACHEN1.2) id AA01363; Sat, 10 Jun 95 22:02:42 +0200 Received: by chapelle.aachendom (4.1/SMI-4.1) id AA20679; Sat, 10 Jun 95 22:02:40 +0200 Date: Sat, 10 Jun 95 22:02:40 +0200 Message-Id: <9506102002.AA20679@chapelle.aachendom> To: tdoan@bnr.ca Subject: re:Starting at levels greater than 1 Cc: crossfire@ifi.uio.no From: Raphael.Quinet@aachen.eed.ericsson.se Reply-To: Raphael.Quinet@aachen.eed.ericsson.se Status: RO On Fri, 9 Jun 1995 13:29:00 -0500, "tuan (t.) doan" wrote: > If done correctly, the key could be simple word that can easily be memorized. > For example, let the key be a quasi-unique 8 bit number generated in the same > manner as CRC checksum. Then use that number as an index to a file to return > a meaningful word. The file can be unique populated by the admin. and is very > flexible. Nice idea. As you wrote, this adds more flexibility: the default file (distributed with the game) would contain short English words, but the maintainer of one server could replace them with horribly long names if he wants to be sure that people won't guess them (this reminds me of some place in the game). I hope that most servers will use the default file if they use the standard maps. Actually, the player would have to remember two things: the level number and the key, but that shouldn't be a problem. When creating a new character, the client would ask: "which level do you want to start at? [1]", and if the player enters a number greater than one: "please enter your key:". If the index of the word matches the 8-bit CRC based on the player name and level, then the player will start at that level (with the minimum amount of experience corresponding to that level). Unless there is a limit for the highest level at which a player may start; if this is the case, a notification will be displayed and the player will start at the maximum available. -Raphael +---------------------------------------------------------------------------+ | WWW: http://www.montefiore.ulg.ac.be/~quinet (with updated DOOM page) | | E-mail: Raphael.Quinet@eed.ericsson.se or quinet@montefiore.ulg.ac.be | | S-mail: Raphael Quinet, 9 rue des Martyrs, 4550 Nandrin (Belgium) | +---------------------------------------------------------------------------+ From crossfire-request Sat Jun 10 21:40:06 1995 Return-Path: Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 10 Jun 1995 21:40:05 +0200 Received: from aachen.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id VAA24777 for ; Sat, 10 Jun 1995 21:40:03 +0200 Received: from chapelle.aachendom by aachen.ericsson.se (4.1/SMI-4.1/AACHEN1.2) id AA01336; Sat, 10 Jun 95 21:40:03 +0200 Received: by chapelle.aachendom (4.1/SMI-4.1) id AA20551; Sat, 10 Jun 95 21:40:02 +0200 Date: Sat, 10 Jun 95 21:40:02 +0200 Message-Id: <9506101940.AA20551@chapelle.aachendom> To: crossfire@ifi.uio.no Subject: Re: Starting at levels greater than 1 From: Raphael.Quinet@aachen.eed.ericsson.se Reply-To: Raphael.Quinet@aachen.eed.ericsson.se Status: RO [First, a little note: when I replied to Tuan's message, I forgot to add a CC to this list. I realized that when I saw his reply and I didn't see my message. Ahem. I was inattentive. Fortunately, he quoted a large part of my message in his reply, so you already got a part of it. Here is the other part, which comes after my "See below." quoted in Tuan's reply.] On Sat, 3 Jun 1995, Petri Heinila wrote: > If starting level feature is made, please make it as a runtime > option in archetypes, like expanding the object map into world: > > Object world [...] > level 10 # starting level from 0 to 10 > attacktype # 1 for random encounters, 2 for notpermadeath, etc > ... > end Yes. The maintainer of one server should be responsible for setting the maximum level at which players can start, because some set of maps are very different from the standard maps, and it may be harder to gain experience on these maps. If a player has the key for a level higher than the limit allowed on the server, then the key would be accepted, but a warning would be displayed. For example: "Although you have the key for level 20, you are starting at level 10 because this limit is enforced by the server". OR, if you prefer shorter messages: "Starting at level 10 (maximum allowed)". On Mon, 5 Jun 95, woodruff@cadence.com (Ken Woodruff) wrote: > I'm not sure if archetypes are the solution but I definitely agree > that it's much better to make the various options currently controlled > by config.h at compile time run time options controlled by a config > file read at start up. [...] > The only advantage I can see for the compile time control is some slight > execution speed optimizations, but these are slight at best. I agree. Having more options controlled by a config file read at start up (not compiled in) will help a lot when you are testing new options or customizing a server. It will also help the "true" client-server version: if some options that could affect the behaviour of the client are also read by the server at start up, they can be sent to the client when it connects to the server. And maybe this would prevent some problems that could arise if an "old" client connects to a server running a newer version of Crossfire. -Raphael +---------------------------------------------------------------------------+ | WWW: http://www.montefiore.ulg.ac.be/~quinet (with preview of DEU 5.3) | | E-mail: Raphael.Quinet@eed.ericsson.se or quinet@montefiore.ulg.ac.be | | S-mail: Raphael Quinet, 9 rue des Martyrs, 4550 Nandrin (Belgium) | +---------------------------------------------------------------------------+ From crossfire-request Fri Jun 9 21:18:39 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 9 Jun 1995 21:18:28 +0200 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 9 Jun 1995 15:13:21 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 9 Jun 1995 14:31:22 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 9 Jun 1995 14:29:00 -0400 Date: Fri, 9 Jun 1995 13:29:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.138:09.05.95.18.31.22] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Starting a... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"21149 Fri Jun 9 14:31:31 1995"@bnr.ca> To: Raphael.Quinet@aachen.eed.ericsson.se Cc: crossfire@ifi.uio.no Subject: re:Starting at levels greater than 1 Status: RO In message "re:Starting at levels greater than 1", you write: >On Fri, 2 Jun 1995, tuan (t.) doan wrote: >> How about a special key gets generated for a particular player (probably >> based upon the checksum of the player file) when each level is achieved. That >> way, if the player chooses to play the same character again (s)he can zip to >> the appropriate level if (s)he has the correct key. Giving your friend the >> key doesn't work because the key is unique per player's name. > >I like this idea. Allowing a beginner to start at level 10 is not interesting >(for the player) because (s)he would not learn the basics of the game in the >same way, and that would probably spoil some of the fun. Besides, the level >is intended to be an image of the player's experience. Using a "key" that >would be different for each player is a better solution, IMHO. > >The key should be short (5-6 digits) so that it is easy to type and to >remember (well, 10 digits are OK if you write them on a piece of paper). >It should be a simple hash code based on the player's name, archetype and >experience. The other data in the player's file vary too much to be useful. > >The key could also be based on a seed provided by the server (either in >config.h or in some config file read at start up). By changing the seed, >it would be possible for the maintainers of one server to make sure that >people who are at level 20 on their server have acquired their experience >there, and not on another server. But I expect that most servers would keep >the default seed, so that experienced players would not be pissed off if >they can't start at their usual level. Note: there would still be a limit >for the highest level at which players could start. See below. If done correctly, the key could be simple word that can easily be memorized. For example, let the key be a quasi-unique 8 bit number generated in the same manner as CRC checksum. Then use that number as an index to a file to return a meaningful word. The file can be unique populated by the admin. and is very flexible. Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Fri Jun 9 04:43:40 1995 Return-Path: Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 9 Jun 1995 04:43:39 +0200 Received: from aachen.ericsson.se (aachen.eed.ericsson.se [164.48.130.2]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id EAA29283 for ; Fri, 9 Jun 1995 04:43:37 +0200 Received: from chapelle.aachendom by aachen.ericsson.se (4.1/SMI-4.1/AACHEN1.2) id AA14709; Fri, 9 Jun 95 04:43:36 +0200 Received: by chapelle.aachendom (4.1/SMI-4.1) id AA13267; Fri, 9 Jun 95 04:43:35 +0200 Date: Fri, 9 Jun 95 04:43:35 +0200 Message-Id: <9506090243.AA13267@chapelle.aachendom> To: crossfire@ifi.uio.no Subject: Crossfire WWW pages with XPM images? From: Raphael.Quinet@aachen.eed.ericsson.se Reply-To: Raphael.Quinet@aachen.eed.ericsson.se Status: RO How many people are using XPM images while playing Crossfire? In October last year, I created a few WWW pages with some colorful views of Crossfire. Today, I checked the other pages that have some images of Crossfire and all the images I found were using the old two-colors graphics. I think those pages would look much better if XPM graphics were used instead. You will find my Crossfire pages at the following URL: http://www.montefiore.ulg.ac.be/~quinet/games/crossfire-en.html There isn't much information there, only a few images and some pointers to other pages, but IMHO these images are good examples of what could (should?) be shown about Crossfire. Note: I haven't updated these pages since last year (except for typos), and some images (like the inventory, for example) would be a bit different now, with 0.91.8. -Raphael From crossfire-request Thu Jun 8 04:43:34 1995 Return-Path: Received: from krusty.eecs.umich.edu (pkenny@krusty.eecs.umich.edu [141.212.36.18]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 8 Jun 1995 04:43:32 +0200 Received: (from pkenny@localhost) by krusty.eecs.umich.edu (8.6.12/8.6.12) id WAA27662; Wed, 7 Jun 1995 22:43:19 -0400 Date: Wed, 7 Jun 1995 22:43:18 -0400 (EDT) From: Patrick Kenny To: Anyone cc: crossfire@ifi.uio.no Subject: Re: Just can't get it to work In-Reply-To: <199506072325.TAA16387@condor.mcs.kent.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO First do a xhost + on your machine. Install the pixmaps. Then when you install the pixmaps do this: crossclient -server -xpm If you don't have the pixmaps installed then do: crossclient -server If you have the server compiled then you can just type: crossfire -xpm or just crossfire. Also there is some documentation with the release that is helpful. -pk ! Patrick Kenny (pkenny@eecs.umich.edu) ! ! (University of Michigan AI and Robotics Lab) ! ! http://ai.eecs.umich.edu/people/kennyp/pkenny.html ! ! Have you Hugged your Artificial Intelligence Today? ! On Wed, 7 Jun 1995, Anyone wrote: > I have been trying to play crossfire for a couple of weeks now, but am > running into many problems. First off, telnetting to a server doesn't > work, the game gives me a message like "cant add display chinook.mcs.kent.edu:0 > so I got hold of xroute and still no dice. Finally, I compiled the client, but > when I run it, I get a message saying it cant find some pixmap. > > Any help would be appreciated. > -EH > > From crossfire-request Thu Jun 8 01:25:26 1995 Return-Path: Received: from condor.mcs.kent.edu (ehughes@condor.mcs.kent.edu [131.123.2.137]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Thu, 8 Jun 1995 01:25:24 +0200 Received: by condor.mcs.kent.edu (8.6.12/mcs.94.07.13a) id TAA16387; Wed, 7 Jun 1995 19:25:02 -0400 From: Anyone Message-Id: <199506072325.TAA16387@condor.mcs.kent.edu> Subject: Just can't get it to work To: crossfire@ifi.uio.no Date: Wed, 7 Jun 1995 19:25:02 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23beta2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 402 Status: RO I have been trying to play crossfire for a couple of weeks now, but am running into many problems. First off, telnetting to a server doesn't work, the game gives me a message like "cant add display chinook.mcs.kent.edu:0 so I got hold of xroute and still no dice. Finally, I compiled the client, but when I run it, I get a message saying it cant find some pixmap. Any help would be appreciated. -EH From crossfire-request Tue Jun 6 14:31:13 1995 Return-Path: Received: from gjalp.ifi.uio.no (1232@gjalp.ifi.uio.no [129.240.84.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 6 Jun 1995 14:31:13 +0200 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by gjalp.ifi.uio.no ; Tue, 6 Jun 1995 14:31:12 +0200 Date: Tue, 6 Jun 1995 14:31:12 +0200 Message-Id: <199506061231.22292.gjalp.ifi.uio.no@ifi.uio.no> To: crossfire@ifi.uio.no Subject: How to unsubscribe Status: RO Send any administrative messages to "crossfire-request@ifi.uio.no". Since I maintain the list by hand, you may not get immediate response. If you find the volume on the discussion list too high, you might want to subscribe to the announcements list only. If so, mention this in the unsubscribe message. Messages sent to crossfire@ifi.uio.no will go to the full list of subscribers (~200 people), but _I_, the maintainer may miss a few of those messages. So don't send requests there, it will not help you at all! Kjetil T. From crossfire-request Mon Jun 5 21:05:01 1995 Return-Path: Received: from mail06.mail.aol.com (mail06.mail.aol.com [152.163.172.108]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 5 Jun 1995 21:04:53 +0200 From: DAHarrell@aol.com Received: by mail06.mail.aol.com (1.37.109.11/16.2) id AA060699055; Mon, 5 Jun 1995 15:04:15 -0400 Date: Mon, 5 Jun 1995 15:04:15 -0400 Message-Id: <950605150414_87140797@aol.com> To: crossfire@ifi.uio.no Subject: Re: Entity Formula Status: RO Re: Entity Formula (ENTITY.ZIP) (interpreted by D. Albert Harrell, origin AUG 1948) "Intelligent Computer Hosted Entities: The Creation and (Expansion or Evolution?) of Self Shaping Circuits" - copyright 1994;1995 Released in MAY 1995 (authorized 060295-ICHE&SSM_B4U_04191995 Copyright 1995 PUBL.IN USA) under tribute to The Freedom of Information Act of 1966. Deposited in the archives of The National Academy of Sciences on May 24 1995. "We are looking for persons who can understand this new science, and suggest research directions." The document (20.000+ "words" and graphics) explains in detail all processing aspects of intelligent reactionary behavior of an "entity" in cyberspace, from the isolation and "atomic" definition formatting of sensor particle clusters, to the default resection of reactionary-order: based on the incongruent particles of the "simile compare" by which said "parallel order" was originally accessed." (This new technology also includes) "the multi-dimensional self-expansion of any installed unit, which automatically achieves an effective task diffusion toward the entity's given objectives." I. A UNIT OF COGNITIVE FORCE - The Self Shaping Circuit (SSC) A. Instruction Sequence (12 subroutines). B. Assigned Target Environment. II. DEFAULT METHOD OF SENSOR/SHAPER PARTICLE FORMATTING A. Atomic Relativity Formatting B. Value Polarization. III. DEFAULT METHOD OF SIMILE SELECTION AND REACTIONARY ORDER RESECTION. IV. INHERENT ENVIRONMENTAL ORDER. (IEO) V. THE THREE DIRECTIONS OF SSC UNIT SELF EXPANSION A. EXPLOSION EXPANSION B. IMPLOSION EXPANSION. C. PARALLEL EXPANSION. VI. EVOLUTION THROUGH PARALLEL MUTATED EXPANSION A. Perfect Parallel Clones B. Imperfect (mutated) Parallel Clones. C. Minimal Notch Mutation. (from the introduction) "Each of the three directions of expansion leads to a unique dimension of such potentially useful fixed perspectives, offering almost endless opportunities to install stationary observer/shapers (new SSCs) among the processing machinery in cognitive space. Each new observer's perspective yields a unique universe that is commonly ABUNDANT WITH PATTERNS AND PROFILES DEPICTING AND REFLECTING USEFUL ORDER WITHIN THE ORIGINAL TARGET ENVIRONMENT of module xyz 0,0,0, the rudimentary epicenter of the isolated task group." The following quotes concern special areas of interest (from sections III. and V.C. of the overview) of the document. "C. PARALLEL EXPANSION. One SSC(1) may be created as an "imperfect clone" of another SSC(2) or portion thereof, intended as a trial replacement for the original machine SSC(1) or portion thereof. Such mutations may be applied to the cloning event by historically known effective design, or by employing a random element, or both. The reason for establishing all of these methodically expanding units of order reflecting force at these various fixed perspectives among given machinery in cognitive space: Each of the three directions of expansion leads to a unique dimension of such potentially useful fixed perspectives, almost endless opportunities to install stationary observer/shapers (new SSCs) among the processing machinery in cognitive space. Each new observer's perspective yields a unique universe that is commonly ABUNDANT WITH PATTERNS AND PROFILES DEPICTING AND REFLECTING USEFUL ORDER WITHIN THE ORIGINAL TARGET ENVIRONMENT of module xyz 0,0,0, the rudimentary epicenter of the isolated task group." - copyright 1995 by D.Albert Harrell * All rights reserved. - * For further information you may send us your email address, and we will email you a 5000 word overview of the new "cognitive physics and Self Shaping Circuits". Also, you may download "RAMbrain.zip" and "Brains4U.zip" from "digcir.cts.com". If you can't access "digcir.cts.com", RAMbrain.zip is also available on AOL (America OnLine); or we can email you a ".uue" file of RAMbrain.zip (you must include the words "send RAMbrain.zip" in your email reply). RAMBRAIN is a visual demonstration of a Universal Decision Circuit (UDC), a "unit of cog force". High speed testing of this "entity" within its "decision universe" offers graphic proof of the premise of the document. This program is a working model of an intelligent computer hosted entity in cyberspace. You may test this creature, and see a graphic lights display of "the machine's brain", showing the actual "thought paths" of the entity. Direct all (non-origin related) questions about this new "cognitive physics and Self Shaping Circuits" to the address below. This is FREE. You will incur no charges or obligations by responding to this communication. D. Albert Harrell P O Box 28261 San Diego, CA 92198-0261 DAHarrell@aol.com From crossfire-request Mon Jun 5 17:33:14 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Mon, 5 Jun 1995 17:33:10 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id IAA08589 for ; Mon, 5 Jun 1995 08:33:02 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma008222; Mon Jun 5 08:31:57 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA10950; Mon, 5 Jun 95 08:31:52 -0700 Received: by pluto (5.65+/1.5) id AA03758; Mon, 5 Jun 95 11:31:54 -0400 Date: Mon, 5 Jun 95 11:31:54 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506051531.AA03758@pluto> To: crossfire@ifi.uio.no Subject: re:Starting at levels greater than 1 Status: RO Petri Heinila writes: > If starting level feature is made, please make it as a runtime > option in archetypes, like expanding the object map into world: I'm not sure if archetypes are the solution but I definitely agree that it's much better to make the various options currently controlled by config.h at compile time run time options controlled by a config file read at start up. In addition to the reasons Petri outlines (mostly that it's a pain to recompile to test an option) this practice leads to a lot of problems in the code as various pieces get out of sync because of missing conditional directives. For example the current build doesn't work if you turn off skills, since there are arrays which are unconditionally initialized to include entries for skills, but the global carrier for the array size is controlled by a config macro. The only advantage I can see for the compile time control is some slight execution speed optimizations, but these are slight at best. --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Sun Jun 4 11:42:38 1995 Return-Path: Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sun, 4 Jun 1995 11:42:36 +0200 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA15225 (5.67b8/IDA-1.5 for ); Sun, 4 Jun 1995 02:42:33 -0700 Received: from foxtrot.rahul.net by bolero.rahul.net with SMTP id AA24940 (5.67b8/IDA-1.5); Sun, 4 Jun 1995 02:42:32 -0700 From: Mark Wedel Received: by foxtrot.rahul.net (5.67b8/jive-a2i-1.0) id AA03389; Sun, 4 Jun 1995 02:42:31 -0700 Date: Sun, 4 Jun 1995 02:42:31 -0700 Message-Id: <199506040942.AA03389@foxtrot.rahul.net> To: crossfire@ifi.uio.no, neotron@infovav.se Subject: re:Starting at levels greater than 1 Status: RO Error code -4 (for xpm creation) means that XpmColorFailed (From the xpm.h header file). This probably means that you have added additional colors (beyond those listed in the the xpm.template file.). The program I wrote to make the xpm montage files can only handle about 96 (or something like that) different color id's. (if people keep to the 30 or so listed, there should never be a problem keeping within this limit.) This is probalby why it sometimes work and sometimes does not - if you are adding enough new colors, it goes beyond this limit, and the xpm file start using non standard symbols for various colors, and fails. IT could also be that you colormap is running out of space. If you are on an 8 bit display (or pretty much any pseudo color display), there are a limited number of colors that can be used at any time. VArious root window backgrounds, other programs, and so on, can all start to chew into the number available, and at some point, it just cant get the 30 or so that crossfire wants. --Mark From crossfire-request Sat Jun 3 14:41:17 1995 Return-Path: Received: from mn3.swip.net (mn3.swip.net [192.71.180.33]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 3 Jun 1995 14:41:17 +0200 Received: by mn3.swip.net with UUCP (8.6.8/2.01) id OAA01984; Sat, 3 Jun 1995 14:39:42 +0200 Date: Sat, 3 Jun 1995 14:34:18 +0200 (MET DST) From: David Hedbor To: crossfire@ifi.uio.no Subject: re:Starting at levels greater than 1 In-Reply-To: <199506030233.AA15412@foxtrot.rahul.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Status: RO > If it is desirable the let people start at a higher level, why not just > put in a starting question 'What level do you want to start at (1-10)?' I think this is a good thing, actually. It would be extremely hard making fair questions, etc, etc. If someone starts at the tenth level, that is not such a big problem, in my opinion. Now to something completetly different! =) I have problems with the making a new archetypes / pixmaps. Everything seems to go along as is should. Pixmaps, font etc is done correctly. However when I try to run the game, it complains that it can't create the pixmap (Error creating pixmap /usr/local/games/crossfire/lib/crossfire.pix.4, error -4.). After saying 'Error code BadRequest' a bunch of times, it exits. I tried to look at the images with xv, and sometimes they work, sometimes they doesn't. I have converted them to ppm and then back to xpm, and this made it work before. It doesn't work anymore, however. So, my question is, does anyone know how to solve this? /David Hedbor (Fireborn fanatic ;) __________________________________________________________________________ Informationsvävarna AB Telefon Telefax Postgiro Bankgiro Skolgatan 10 013-147610 013-147616 838 85 17-8 5931-9459 582 34 Linköping david@infovav.se http://www.infovav.se/ From crossfire-request Sat Jun 3 14:05:25 1995 Return-Path: Received: from dior.it.lut.fi (hevi@dior.it.lut.fi [157.24.23.48]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 3 Jun 1995 14:05:24 +0200 Received: (from hevi@localhost) by dior.it.lut.fi (8.6.8/8.6.6/1.17.kim) id PAA01342; Sat, 3 Jun 1995 15:05:17 +0300 Date: Sat, 3 Jun 1995 15:05:16 +0300 (EET DST) From: Petri Heinila X-Sender: hevi@dior.it.lut.fi To: crossfire@ifi.uio.no Subject: re:Starting at levels greater than 1 In-Reply-To: <199506030233.AA15412@foxtrot.rahul.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 2 Jun 1995, Mark Wedel wrote: >... > If it is desirable the let people start at a higher level, why not just > put in a starting question 'What level do you want to start at (1-10)?' > Sure, it makes it easy. But if people find that level 1 is really boring, > let them start at a higher level. The point of the game is to have fun. If > someone can have more fun starting at level 5, and not spoil the fun for > others, let them. And of course, if this is a compilable option, it could > be turned on on some remote servers. If starting level feature is made, please make it as a runtime option in archetypes, like expanding the object map into world: Object world type 999 # type of world configfuration name CrossWorld # name of the world in server slaying /city/city # starting map x 16 # positions y 16 # hp 2 # sp 2 # level 10 # starting level from 0 to 10 attacktype # 1 for random encounters, 2 for notpermadeath, etc ... end I have faced that it's quite tiresome to find out what the different options really do; set macro, compile, try out how it works. There is excellent descriptions for each macro, but seeing how it's works gives real feel. And in binary distributions, expecially in linux world there is no possibility for that. The aim is anyway to have fun and play, not to compile software. Petri.Heinila@lut.fi From crossfire-request Sat Jun 3 04:34:03 1995 Return-Path: Received: from tango.rahul.net (tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 3 Jun 1995 04:34:02 +0200 Received: from bolero.rahul.net by tango.rahul.net with SMTP id AA18078 (5.67b8/IDA-1.5 for ); Fri, 2 Jun 1995 19:33:59 -0700 Received: from foxtrot.rahul.net by bolero.rahul.net with SMTP id AA17012 (5.67b8/IDA-1.5); Fri, 2 Jun 1995 19:33:58 -0700 From: Mark Wedel Received: by foxtrot.rahul.net (5.67b8/jive-a2i-1.0) id AA15412; Fri, 2 Jun 1995 19:33:53 -0700 Date: Fri, 2 Jun 1995 19:33:53 -0700 Message-Id: <199506030233.AA15412@foxtrot.rahul.net> To: tdoan@bnr.ca, woodruff@cadence.com Subject: re:Starting at levels greater than 1 Cc: crossfire@ifi.uio.no Status: RO In any situation, there is several problems. If you ask questions about how to kill certain things, those answers can easily be found at by looking at the code. Yes, this may be cheating, and if you are the server adminster, you could just as easy edit the playing file. However, for remote servers, that is not an option, but finding the answers is pretty easy. If you ask questions about the maps (which people could not cheat to find out, because the remote server might change the passwords or even add new maps), the problem is then that the characters may not have gone through that particular map. And it still does not prevent one player from telling the others the answer. If it is desirable the let people start at a higher level, why not just put in a starting question 'What level do you want to start at (1-10)?' Sure, it makes it easy. But if people find that level 1 is really boring, let them start at a higher level. The point of the game is to have fun. If someone can have more fun starting at level 5, and not spoil the fun for others, let them. And of course, if this is a compilable option, it could be turned on on some remote servers. --Mark From crossfire-request Sat Jun 3 02:35:19 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 3 Jun 1995 02:35:15 +0200 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 2 Jun 1995 20:34:11 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 2 Jun 1995 20:34:04 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 31 May 1995 20:34:00 -0400 Date: Fri, 2 Jun 1995 19:34:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.038:03.05.95.00.34.04] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Starting ... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"20039 Fri Jun 2 20:34:06 1995"@bnr.ca> To: thomas@chaupher.gsfc.nasa.gov Cc: peterm@csua.berkeley.edu, crossfire@ifi.uio.no Subject: Re: Starting at levels greater than 1 Status: RO In message "Re: Starting at levels greater than 1", 'thomas@chaupher.gsfc.nasa.gov' writes: >> >> (P.S., anyone have feedback on any of the peterm/* maps? >> They've been out for a while, do they need tuning?) >> > > Well, I visit the Dragoncaves quite often, and they remain for me one > of the most enjoyable "challenging" map set of the game. The Demonology > school remains my favorite however. I admire how difficulty, plot and > reward have been synthesised here. My only feelings about these maps > is that there should be more of them! > > b.t. The tower of Demonology has a problem that it crashes the game when one of the elemental name is called. This problem existed since .5 version and still exist in the latest .8 version. Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Sat Jun 3 00:48:06 1995 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Sat, 3 Jun 1995 00:48:02 +0200 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 2 Jun 1995 18:46:17 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 2 Jun 1995 18:45:52 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 2 Jun 1995 18:46:00 -0400 Date: Fri, 2 Jun 1995 22:45:52 +0000 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.818:02.05.95.22.45.52] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Starting a... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"11837 Fri Jun 2 18:46:06 1995"@bnr.ca> To: woodruff@cadence.com Cc: crossfire@ifi.uio.no Subject: re:Starting at levels greater than 1 Status: RO In message "Starting at levels greater than 1", 'woodruff@cadence.com' writes: > >I've been thinking about some mechanism for allowing players to start at >a level higher than one since for experienced users the early levels become >just a mad dash to gain experience as quickly and easily as possible without >providing much fun. However, I don't want to let new users wade through the >low levels with overpowered characters. > >I propose that after a character has been rolled that the user should be prompted >for a desired starting level. The user would then be asked several questions to >ensure that they have sufficient knowledge of the game to deserve that starting >level. Only if the user successfully passes the quiz will they be allowed to >start at that level. The questions would get harder for each level, we could >top out at around level 10. The questions could be contained in a file in >the library directory (say "levelquiz"), so could be site customizable. > >Some example questions: >- What is the password needed to open the gates to Scorn? >- What is the name of Gork's best friend? >- What is the name of the spell that Yqreth guards in his tower? > etc. > >Comments? > >--Ken > >+------------------------+---------------------------------------------+ >| Ken Woodruff | Most Latin words in -us have plural in -i, | >| woodruff@cadence.com | but not all, & so zeal not according to | >+------------------------+ knowledge issues in such oddities as hiati, | >| Disclaimer: What tote | octopi, omnibi, & ignorami; ... | >| bag full of $20 bills? | Fowler, "Modern English Usage" | >+------------------------+---------------------------------------------+ Er, whats preventing people from memorizing the answers from another person? Beside most of the questions asked will be from quest of some sort and does not really test the skill of the player (ie: how to kill a dragon, how to prevent from getting zapped by the reaper, etc...) How about a special key gets generated for a particular player (probably based upon the checksum of the player file) when each level is achieved. That way, if the player chooses to play the same character again (s)he can zip to the appropriate level if (s)he has the correct key. Giving your friend the key doesn't work because the key is unique per player's name. Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 214-684-4575 Fax: 214-684-3716 Internet: tdoan@bnr.ca WWW: http://47.53.64.96/tdoan/tdoan.html From crossfire-request Sat Jun 3 00:33:16 1995 Return-Path: Received: from krusty.eecs.umich.edu (pkenny@krusty.eecs.umich.edu [141.212.36.18]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 3 Jun 1995 00:33:03 +0200 Received: (from pkenny@localhost) by krusty.eecs.umich.edu (8.6.12/8.6.12) id SAA17569; Fri, 2 Jun 1995 18:32:44 -0400 Date: Fri, 2 Jun 1995 18:32:43 -0400 (EDT) From: Patrick Kenny To: crossfire@ifi.uio.no Subject: Re: Starting at levels greater than 1 In-Reply-To: <9506021854.AA03150@pluto> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I agree that it would be nice to start at a high level, but just make sure that the starting character has a nice set of spells or armor that works with a character of that level, otherwise you would be wasting your time. I start at level 20, but I don't know any spells? What you mean I have to learn them all again? I have to find all of the books? Ouch. Even with lots of money at the start, it would take quite a while to find the right spells and stuff in the stores. I don't know if asking questions will work, maybe people who start at high levels should have to solve certain quests within a certain time limit. "Bring me the Head of a Jessy!" and then you will be able to stay Level 20. :) -pk ! Patrick Kenny (pkenny@eecs.umich.edu) ! ! (University of Michigan AI and Robotics Lab) ! ! http://ai.eecs.umich.edu/people/kennyp/pkenny.html ! ! Have you Hugged your Artificial Intelligence Today? ! From crossfire-request Fri Jun 2 23:19:47 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 2 Jun 1995 23:19:41 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id RAA13920; Fri, 2 Jun 1995 17:19:36 -0400 Date: Fri, 2 Jun 1995 17:19:36 -0400 From: Brian Thomas Message-Id: <199506022119.RAA13920@chaupher.gsfc.nasa.gov> To: peterm@CSUA.Berkeley.EDU Subject: Re: Starting at levels greater than 1 Cc: crossfire@ifi.uio.no Status: RO > > (P.S., anyone have feedback on any of the peterm/* maps? > They've been out for a while, do they need tuning?) > Well, I visit the Dragoncaves quite often, and they remain for me one of the most enjoyable "challenging" map set of the game. The Demonology school remains my favorite however. I admire how difficulty, plot and reward have been synthesised here. My only feelings about these maps is that there should be more of them! b.t. From crossfire-request Fri Jun 2 23:15:20 1995 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 2 Jun 1995 23:15:17 +0200 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) with SMTP id OAA12397; Fri, 2 Jun 1995 14:15:03 -0700 Message-Id: <199506022115.OAA12397@soda.CSUA.Berkeley.EDU> To: Brian Thomas cc: crossfire@ifi.uio.no, woodruff@cadence.com Subject: Re: Starting at levels greater than 1 In-reply-to: Your message of "Fri, 02 Jun 1995 16:29:31 EDT." <199506022029.QAA13839@chaupher.gsfc.nasa.gov> Date: Fri, 02 Jun 1995 14:15:01 -0700 From: Peter Mardahl Status: RO In message <199506022029.QAA13839@chaupher.gsfc.nasa.gov>, Brian Thomas writes: > > I believe the 'castle' map (actually in the church???) was a map > fixed by either Mark or PeterM in version 0.91.6 or 0.91.7. You need > an update! But I definitely agree with you about the other maps. > > b.t. If the castle map is as I left it you can probably still kill a bunch of dragons in a big room relatively easily with fireball. I made it a bit harder, but I don't know if it is hard enough, yet. Regards, PeterM (P.S., anyone have feedback on any of the peterm/* maps? They've been out for a while, do they need tuning?) From crossfire-request Fri Jun 2 22:29:43 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 2 Jun 1995 22:29:40 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id QAA13839; Fri, 2 Jun 1995 16:29:31 -0400 Date: Fri, 2 Jun 1995 16:29:31 -0400 From: Brian Thomas Message-Id: <199506022029.QAA13839@chaupher.gsfc.nasa.gov> To: crossfire@ifi.uio.no, woodruff@cadence.com Subject: Re: Starting at levels greater than 1 Status: RO > Ken writes > security measures). Hell, I can hack a save file to get experience a lot faster > than the method you suggest. > Indeed! You are quite right. > > P.S. There are several maps in Brest that need serious work. The 10 armies area > just one of these. The castle where you can kill 50 electric dragons with just > fireballs and no risk to yourself is probably worse. > I believe the 'castle' map (actually in the church???) was a map fixed by either Mark or PeterM in version 0.91.6 or 0.91.7. You need an update! But I definitely agree with you about the other maps. b.t. From crossfire-request Fri Jun 2 22:27:45 1995 Return-Path: Received: from mail04.mail.aol.com (mail04.mail.aol.com [152.163.172.53]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 2 Jun 1995 22:27:33 +0200 From: DAHarrell@aol.com Received: by mail04.mail.aol.com (1.37.109.11/16.2) id AA256464799; Fri, 2 Jun 1995 16:26:39 -0400 Date: Fri, 2 Jun 1995 16:26:39 -0400 Message-Id: <950602162638_84731881@aol.com> To: crossfire@ifi.uio.no Subject: Re: Entity Formula (ENTITY.ZIP) Status: RO Re: Entity Formula (ENTITY.ZIP) (interpreted by D. Albert Harrell, origin AUG 1948) "Intelligent Computer Hosted Entities: The Creation and (Expansion or Evolution?) of Self Shaping Circuits" - copyright 1994;1995 Released in MAY 1995 (authorized 060295-ICHE&SSM/B4U/04191995 copyright 1995 PUBL.IN USA) under tribute to The Freedom of Information Act of 1966. Deposited in the archives of The National Academy of Sciences on May 24 1995. "We are looking for persons who can understand (III.par.3; V.C.par.3) this new science and suggest research directions." The document (20.000+ "words" and graphics) explains in detail all processing aspects of intelligent reactionary behavior of an "entity" in cyberspace, from the isolation and "atomic" definition formatting of sensor particle clusters, to the default resection of reactionary-order: based on the incongruent particles of the "simile compare" by which said "parallel order" was originally accessed. This new technology also includes the multi-dimensional self-expansion of any installed unit, which automatically achieves an effective task diffusion toward the entity's given objectives. The following is an overview of the completed interpretation of the document "Intelligent Computer Hosted Entities: The Creation and (Expansion or Evolution?) of Self Shaping Circuits" There are six main concepts which must be addressed toward understanding this new science, dubbed "cognitive physics". I. A UNIT OF COGNITIVE FORCE - The Self Shaping Circuit (SSC) A. Instruction Sequence (12 subroutines). B. Assigned Target Environment. II. DEFAULT METHOD OF SENSOR/SHAPER PARTICLE FORMATTING A. Atomic Relativity Formatting B. Value Polarization. III. DEFAULT METHOD OF SIMILE SELECTION AND REACTIONARY ORDER RESECTION. IV. INHERENT ENVIRONMENTAL ORDER. (IEO) V. THE THREE DIRECTIONS OF SSC UNIT SELF EXPANSION A. EXPLOSION EXPANSION B. IMPLOSION EXPANSION. C. PARALLEL EXPANSION. VI. EVOLUTION THROUGH PARALLEL MUTATED EXPANSION A. Perfect Parallel Clones B. Imperfect (mutated) Parallel Clones. C. Minimal Notch Mutation. I will give a brief portrait of the knowledge that each of these levels represents. I. A UNIT OF COGNITIVE FORCE A primitive SSC is a 2-dimensional machine in cognitive or cyber space. The macro flow chart of ZIMON (the Simile Flux Reactor) represents a single primitive one-celled unit of cognitive force. A. Instruction Sequence (12 subroutines) of THE PRIMITIVE SIMILE FLUX REACTOR SHAPER CIRCUIT 1 > 2 > 12 3 11 < 5 < 4 8 < 7 < 6 10 < 9 < 1. Sensors - Scan For Flux ***Input Terminal*** 2. Decision - FLUX Detected ? [IF NO GO TO 1.] 3. Process - Attempt To Define Flux 4. Decision - Is a survivable Reactionary Order to this flux known? [IF NO GO TO 6.] 5. Retrieve Record - Access successful Reactionary/Order of known flux event. [GO TO 11] 6. Decision - Similar historical fluctuation found? [IF NO GO TO 9.] 7. Retrieve Record - Access Reactionary Order of Known similar Flux event record. 8. Process - Resect the Reactionary Order (see default resection) [GO TO 10] 9. Process - Select a Random shaping Reaction to this Flux. 10. Decision - Has this Reaction Failed Before? [IF YES GO TO 6] 11. Shape - Implement the Reactionary Order (shape the target environment)***Output Terminal*** 12. Record - Define And Record Shaping Cycle Event [Return To 1.] An SSC is a decision circuit with an input and output terminal. It will accept a fluctuation (sensor particle cluster) and return a target (environment) shaping action. A new SSC may not yet have records of experience. Without such records, this unit is blank. Notice that an entity cannot generate cog force (intelligence) until it has records, and it will not create records until it begins interfacing with a target environment. B. Assigned Target Environment. The target environment is a portion of the entity's universe. Its boundaries are those of the sensory and shaping possibilities of the entity. This environment is defined and supplied (if not created) by the installer of the SSC. This "installer" may be a human entity, or another SSC. In addition to the Target Environment, a given entity's UNIVERSE also includes: his polarized records of event cycles; his value assignment (and a default or evolved method of measuring said value); the i/o interface between the physical target environment and the cognitive space of the entity; the physical laws that govern the target and cognitive space; and the entity itself. II. DEFAULT METHOD OF SENSOR/SHAPER PARTICLE FORMATTING OF DEFINITION CLUSTERS (HOW records are formatted, filed, and accessed by a given isolated SSC) The default method for the isolation and value polarized recording of the entity's "theoretical definitions" of the elements, actions, and concepts of a given target environment. An SSC creates and accesses records called "definition artifacts". A definition artifact is a cluster of i/o particles within an indicative atomic format. These i/o particles are of 2 main types: SENSOR and SHAPING. Such particles might be viewed as the "quarks" of entity's sensor/shaping capabilities within said entity's target universe. Early on in my exploration of cognitive space I had to solve this problem. Briefly, cog physics reduces all input and output action to sensor and shaping particles respectively. The format designates a default method for structuring these groups of incoming and outgoing i/o quarks into isolable definitive "value polarized" clusters which may be usefully stored, accessed, and compared by an SSC. A. Atomic Relativity Formatting (ARF) ARF is a very simple and useful method of defining concepts within an entity-universe that views all "non-space" as groups of i/o particles. Particles of matter in cognitive space are arranged in a somewhat natural "atomic" configuration. (ARF is not a format which I designed, but instead, one that I have observed and adapted to serve the needs of cognitive machinery.) B. Value Polarization. An event cycle is very special "value polarized" type on "definition artifact". The definition of an event cycle is comprised of a "fluctuation in", "reaction out", and "evaluation of" the given cycle that has occurred in said target environment. This value polarization within the formatting of history might be best described as a prevailing attitude or value prejudice in the interpretation and accounting of the actions and elements that comprise a given cycle event. As a Flux Cycle Event is recorded, a determination is made as to whether or not this event had a positive, negative, or neutral effect on the value status of the target universe (environment). In other words, all records are value polarized as a portion of formatting. For instance, the given fluctuation of a given event cycle might be recorded and subsequently view as a "problem"; followed by a reaction (or solution if you like) to that problem. Whether or not the solution/reaction was successful, would be entered in the the evaluation field of the record. With a few exceptions, all SSCs format each fluctuation event cycle in one (or more) of the following three value polarized configurations. 1. A problem with an attached solution. 2. An opportunity with an attached acquisition plan. 3. A cause with an attached effect (usually neutral in value). III. DEFAULT METHOD OF SIMILE SELECTION AND REACTIONARY ORDER RESECTION. Parallel Continuity Postulate: "Multiple value-polarized cycle event records that have some degree of atomic structural congruency and/or specific cell content equality (when comparing the particle clusters of their respective fluxes, SSC INPUT), have a greater (in proportion to said congruency) than random possibility of particle/structure congruency among the respective opposite polarity definition clusters (representing the reactionary orders, SSC OUTPUT) of the cycle events." Restating the above, a value polarized (see II. B.) record of an SSC cycle event contains two definition clusters comprised of cognitive particles (mostly i/o quarks) within specific and unique atomic formats, these clusters represent the flux (mostly sensor particles) and the reaction (mostly shaping particles) that occurred during a given cycle event. Any other (latter) cycle event record, including a given flux cluster currently being processed, which has a flux that is similar, to any degree to the former flux cluster, has a better than random chance of having particle cluster similarity with the former's respective opposite polarity cluster, or in this case the "effective" reactionary order of this historical definition artifact. An environment with IEO will reflect this ORDER as parallel pattern continuity THROUGHOUT THE ENTIRE MECHANISM of the cognitive task network. This is what makes it possible to respond to a unique (unknown) perhaps current fluctuation with some degree of effective reactionary order. Commonly, one can extrapolate a fairly useful response sequence to an unknown flux, by simply using the effective historical response of a former similar flux. This postulate is true even if the entity doesn't make any changes in this former responses to this former flux (which is similar to said unknown probably "current" flux). However, even a primitive one-celled unit of cog force, a single unexploded, unimploded, uncloned SSC will make changes in this reaction sequence in accordance to default resection methods. Such references to parallel order are main conduits to effective intelligent reflection of IEO. Notice that the flux and reaction particle clusters may be reversed in the above equation, that is to say, an entity may also extrapolate a probable similar flux to a known reaction. Cog physics is inundated with this kind of i/o symmetry, fundamentally, an SSC formats and processes sensor (INPUT) particles almost identically to the way it handles shaping (OUTPUT) particles. The i/o status of the particle simply denotes its given polarity within an SSC processing equation. This degree will usually be in direct proportion to the degree of congruency in the original simile compare, which has accessed this Parallel Order Continuity. In other words, the more similar the fluctuation is, the more effective the reaction of the parallel order will be when implemented in the target universe as a response to the (usually current) unknown flux. The Parallel Continuity Postulate is true because all environments that are compatible with entity inhabitation will have IEO. In order for an entity to be able to successfully reflect continuity of elements and motion within a given environment, such continuity must indeed be present. DEFAULT RESECTION OF REACTIONARY ORDER. Resection of opposite polarity clusters is based on the incongruent particles of the simile compare by which said parallel order was originally accessed. In default, all occurrences of the incongruent particle(s) of the historical flux, are replaced within the reactionary order cluster of the historical event record, with the respectively incongruent (unequal) particle(s) of the new (probably current) flux. This newly created (resected) reactionary order will be more effective than randomly created order, OR simile accessed parallel order that has not been so resected. IV. INHERENT ENVIRONMENTAL ORDER. An entity's environment must have IEO. IEO is theorized to be present when elemental and/or motion sequences (patterns) in the target environment occur with a consistent frequency beyond that of random expectation. Indeed, it is my contention that for an entity to be able reflect IEO, and thereby shape his environment with an effectivity beyond that of random expectation, there must exist within this target environment some degree of order, i.e., elemental and/or motion continuity to: observe, record, discover, "simile-access" (analogy conduits to parallel order), mutate, and reflect as effective implemented shaping action. V. THE THREE DIRECTIONS OF SSC UNIT SELF EXPANSION (Implosion, Expansion, Parallel) (Directions in which this first (originally installed) unit may expand the task network.) Task diffusion is automatic. It occurs as a by product of standard expansions policies. An SSC that is operating below its optimum effective performance (as measure by creator assigned value parameters) will expand. The configuration (design and direction) of this expansion, the selection of a specific area and mass of processing machinery in cog space as a target universe (to which will be applied a new observer/shaper entity) may be determined by historically known effective design and or random selection. This selection determines "where" and "what" the boundaries of the new entity perspective will be, within the universe of old processing machinery. For instance, the expansion manager of a given entity may elect to adopt an explosion expansion using the 3rd, 4th, and 7th processing instructions of another given SSC, as a target environment, assigning these three instructions (and their relative fluctuating specifics) as this newly created entity's entire task universe. The task being, in default, to make (shape) controlled changes in these three instructions (and/or their information artifacts) which increases value in the, perhaps quite remote, target universe. Beyond default, the value assessment of such an alien adoption would usually be designated as a measurement made outside of this new universe (instructions 3, 4, and 7). Specifically, such value would normally be derived from within a dominant (closer to the nucleus) SSC on the expansion path of the SSC task network, if not directly from within the nucleus SSC itself (SSC number x(0),y(0),z(0) - the original expanded SSC that initiated the entire given isolated task network). Any type of expansion creates a "connection" of relativity between the given SSCs involved in the expansion. A given isolated SSCs task network, for instance, a typical small entity manning an average cognitive perspective, might be composed of 100,000 units; each unit will be "connected" to the mass in at least one of the following three ways. (first, in very abstract language) They may : (A.) "LOOK at each other" (B.) "INHABIT each other" (C.) "CLONE each other." A. EXPLOSION EXPANSION. One SSC(1) may be created to "look at (select)" another SSC(2) or portion of this machine, adopting this "tangible" portion, or the entire machine(2), and its(2) "action" as the newly created SSC's(1) entire task universe. This new observer/shaper's default task is to make slight "changes" in this processing machinery and/or the definition artifacts that it handles, and begin trials and evaluation of this new (perhaps only minimally mutated) processing configuration. (see VI. C. Minimal Notch Mutation) B. IMPLOSION EXPANSION. One SSC(1)machine may be created to "inhabit a decision point" within another SSC(2)machine, adopting this decision point within SSC(2) as the newly created SSCs(1) entire task universe. This is very different than the above explosion expansion type. This new entity would be making an "in-line" decision located within one of the 12 SSC subroutines. Many of the 12 subroutines have a number of interrupt points to which a new decision entity may be optionally applied. C. PARALLEL EXPANSION. One SSC(1) may be created as an "imperfect clone" of another SSC(2) or portion thereof, intended as a trial replacement for the original machine SSC(1) or portion thereof. Such mutations may be applied to the cloning event by historically known effective design, or by employing a random element, or both. The point of establishing all of these methodically expanding units of order reflecting force at these various fixed perspectives among given machinery in cog space: Each of the three directions of expansion leads to a unique dimension of such potentially useful fixed perspectives, almost endless opportunities to install stationary observer/shapers (new SSCs) among the processing machinery in cognitive space. Each new observer's perspective yields a unique universe that is commonly ABUNDANT WITH PATTERNS AND PROFILES DEPICTING AND REFLECTING USEFUL ORDER WITHIN THE ORIGINAL TARGET ENVIRONMENT of module xyz 0,0,0, the rudimentary epicenter of the isolated task group. Obviously, only a minute fraction of these observer perspectives lead to the discovery of useful shaping (or pattern recognition of value influential cause/effect) of the given proposed target area. In deference to this, I would like to make two points. (1) The installation and trial testing (target shaping followed by evaluation) of a typical newly created entity perspective in cog space involves durations measured in nanoseconds. (2) Once a useful perspective has been discovered, it can be applied, not only to problems of the same type; but through the use of simile compare events (see SCE above), "similes" of this effective new "task (perspective) network" may be applied to all known task defusing problems of a "similar" type. Furthermore, once an effective task network has been discovered for a given perspective, it will be tuned to its optimum reactionary behavior by using an SSC evolutionary growth policy called MNM. (see below) VI. EVOLUTION THROUGH PARALLEL MUTATED EXPANSION Including The Hyper-Evolution Of Contained Reproductive Entities In Competition For The Same Elements. A. Perfect Parallel Clones Perfect cloning of an SSC unit or network would be used in cases where the decision or problem universe is well known and defined, along with a know historically effective task (solution) network. B. Imperfect (mutated) Parallel Clones. Any cloning other than the above perfect type. The genetic mixing that occurs when an egg is fertilized, is the combining of two different entities, to produce an unknown unique third entity which will be tested by reality. This biological method of natural creation and selection contains many useful parallel concepts for producing unique SSM task networks. A specific task oriented SSM module appears to have the essential equivalent of "genetic character." This "reproductive information package" correlates to the structure of the SSM network, and the individual policies (and Simile Compare Decision SCCatalysts) for handling data of the decision points within the given isolated SSM task structure. This genetic coding (of the SSMs) may be used in the "crossbreeding" and "genetic splicing" of two or more modules, to produce a unique "offspring." The parent modules of these "hybrids could be chosen by human, SSM, random or "natural" (effectivity) selection. SSM task networks, with their ADAs and SCCs, could be subjectively crossbred like dogs, to handle a wider spectrum of task types. An "on line" module within a cyberspace model environment has all the critical elements that are necessary for replication with evolution (i.e., unique "genetically coded entities," interactively participating in the shaping of their own environment, while reproducing according to the creator/installer assigned "laws of natural selection"). When confronted with an unfamiliar task, which is unlike any in experience; two or more SSM modules (perhaps deeply imploded task networks) composed of task elements similar to those of the problem, could be selected and crossbred. These offspring might be tested at high speed on RAM dwelling models, with qualifiers implemented on the SSM task reality. It would be optimum to have these entities follow an emulation of "propagation by natural selection," (based on effectivity toward modular objectives) with simultaneous development occurring at a multiple of points in the task network. C. Minimal Notch Mutations (MNM) [A type of Parallel Imperfect Expansion] A COMPASS TO EFFECTIVE REACTIONS MNM is the entity's directional guidance system for change. Historical records of MNM guide the entity in non random experimental expansion changes. Recorded patterns indicate specific cell points as having cause and effect relationships, associated with specific environment shaping results. Reliable repetitive historical order is used to deliberately and selectively effect the shape of the environment or self. MNM is the SSM practice of establishing reliable (repeatable) order, such as cause and effect sequences, and then augmenting this established order, at a single specific point by a minimal degree of change. Any change in the effect of the implemented order is then observed, and associated with said deliberate minimal mutation. Theories are adopted and tested through application, concerning the nature, direction and even the degree of environmental shaping force yielded by the application of a given shaping sequence. As a rule, a change at any given cell point in the sequence, is associated with a change in that sequence's recorded (sensed) shaping effect on an equal environment. * (a more detailed explanation of the primitive SSC.) Self Shaping Circuit Programming A brief description of the 12 subroutines sequence of THE PRIMITIVE SIMILE FLUX REACTOR SHAPER CIRCUIT (Cognitive physics views a processing instruction as a tangible two dimensional object, a machine existing in computer space.) 1 > 2 > 12 3 11 < 5 < 4 8 < 7 < 6 10 < 9 < 1. Sensors - Scan For Flux ***Input Terminal*** Handles input of All sensor data (particles) from the target-Universe. 2. Decision - FLUX Detected ? [IF NO GO TO 1.] FLUX ISOLATION The last known configuration of the self and environment is compared to the new configuration. The difference between these two configurations is theorized to be a definition of the current fluctuation in modular status. YES Flux has been detected. 3. Process - Attempt To Define Flux Any event, action, or change that occurs within an SSM's environment, will trigger an Flux Reactor Shaper cycle; in which, the first step will be to theorize a definition of this sensor fluctuation. There is no attempt to "understand" this fluctuation, merely to isolate and cluster the individual particles theorized to comprise the definition of the entire fluctuation. A SFRS records each flux event, beginning with the flux and ending with the reaction, including a post reaction evaluation as to whether or not this entire event, as it has occurred, had a positive, negative, or no effect on the defined value measurements within the target universe of the given entity. note: The value of a given universe must be defined by the creator of the entity, whether the creator of said entity is a human being, or another SSC. 4. Decision - Is a survivable Reactionary Order to this flux known? [IF NO GO TO 6.] Has this entity ever encountered this flux before and survived the known historical reactionary shaping response to this known flux? IF YES CONTINUE TO STEP 5 5. Retrieve Record - Access successful Reactionary/Order of known flux event. [GO TO 11] This is a known flux, with a known successful historical reactionary order. 6. Decision - Similar historical fluctuation found? [IF NO GO TO 9.] (A survivable R/O to this flux is not known) Can a similar historical fluctuation be found within the records of successful (survived) FRS cycles? IF YES CONTINUE TO STEP 7 7. Retrieve Record - Access Reactionary Order of known similar flux event record. A Similar FLUX is Known. This FLUX is similar to a known flux, with a known successful (perpetuating) historical Reactionary Order. 8. Process - Resect the Reactionary Order (see default resection) [GO TO 10] according to the incongruent portion of the simile compare event, and known historical resection problems of a similar type. (see default resection) 9. Process - Select a Random shaping Reaction to this Flux. Create random output particle cluster. 10. Decision - Has this Reaction Failed Before? [IF YES GO TO 6] Is this shaping reaction a known historically failed reaction to this current cycle flux? IF NO CONTINUE TO STEP 11 11. Shape - Implement the Reactionary Order (shape the target environment)***OutputTerminal*** 12. Record - Define And Record Shaping Cycle Event [Return To 1. - Sensor Scan For Flux] The Simile-FRS Circuit is designed to react successfully (over a period of time) to fluctuations in modular status. If the flux is in the nature of a problem (a deterrent to the survival or value assignment of the entity), then, the machine will inevitably create a survivable solution (as the reactionary order to this "problem" flux). The input terminal accepts flux (usually problems or opportunities); the output terminal emits reactions (usually solutions or acquisition plans). These polarized terminals act as connection-points for expanding the modular structure in two of the three directions of task network growth (Implosion and Expansion). - copyright 1995 All rights reserved. * For further information, you may download "RAMBRAIN.ZIP" from AOL. RAMBRAIN is a visual demonstration of a Universal Decision Circuit (UDC), a "unit of cog force". High speed testing of this "entity" within its "decision universe" offers graphic proof of the premise of the document. This program is a working model of an intelligent computer hosted entity in cyberspace. You may test this creature, and see a graphic lights display of "the machine's brain", showing the actual "thought paths" of the entity. You may direct all (non-origin related) questions about this new "cognitive physics and Self Shaping Circuits" to the address below. D. Albert Harrell P O Box 28261 San Diego, CA 92198-0261 DAHarrell@aol.com From crossfire-request Fri Jun 2 20:55:03 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 2 Jun 1995 20:54:55 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id LAA19750 for ; Fri, 2 Jun 1995 11:54:43 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma019734; Fri Jun 2 11:54:32 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA04668; Fri, 2 Jun 95 11:54:26 -0700 Received: by pluto (5.65+/1.5) id AA03150; Fri, 2 Jun 95 14:54:27 -0400 Date: Fri, 2 Jun 95 14:54:27 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506021854.AA03150@pluto> To: crossfire@ifi.uio.no Subject: Re: Starting at levels greater than 1 Status: RO I guess I'll repeat Brian's warning: > Warning! This mail contains spoilers!!! Brian writes: > a general strategy is possible for quick advancement. 1) gain enough > treasure to buy several wands of summon elemental. 2) goto admin building > in brest and use them in the 10 armies area. You will watch your experience > jump very high, very fast this way. > [...] > the winner was the one with the most experienced character after an hour of play It's exactly this that I want to avoid. Why spend an hour following a formula for experience that has nothing to do with learning the game, risking your character's life for greater return, going on quests, or exploring new maps, all of the things that make the game fun (IMHO). If you're experienced enough to know *how* to gain expeience fast, I don't see a need for you to actually do it. My suggestion is designed to steer the advanced user towards the tougher maps, and leave the "easy pickings" to the people just starting out rather than having advanced players rip through everything in a mad grab for easy treasure. > Its a thought. But all one has to do is take a look at the code to > get the answers! A lot of work for nothing if you ask me. Maybe *you* have endless hours to waste just killing Dread with elementals. I'd rather play. As for looking at the source, that's cheating of an entirely different sort and is something I leave up to the user's conscience (or the administrator's security measures). Hell, I can hack a save file to get experience a lot faster than the method you suggest. --Ken P.S. There are several maps in Brest that need serious work. The 10 armies area just one of these. The castle where you can kill 50 electric dragons with just fireballs and no risk to yourself is probably worse. +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+ From crossfire-request Fri Jun 2 21:03:36 1995 Return-Path: Received: from chaupher.gsfc.nasa.gov (chaupher.gsfc.nasa.gov [128.183.8.36]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 2 Jun 1995 21:03:31 +0200 Received: (from thomas@localhost) by chaupher.gsfc.nasa.gov (LHEA9404/940426.s1) id OAA13741; Fri, 2 Jun 1995 14:29:56 -0400 Date: Fri, 2 Jun 1995 14:29:56 -0400 From: Brian Thomas Message-Id: <199506021829.OAA13741@chaupher.gsfc.nasa.gov> To: woodruff@cadence.com Subject: Re: Starting at levels greater than 1 Cc: crossfire@ifi.uio.no Status: RO Warning! This mail contains spoilers!!! > woodruff@cadence.com (Ken Woodruff) writes: > > I've been thinking about some mechanism for allowing players to start at > a level higher than one since for experienced users the early levels become > just a mad dash to gain experience as quickly and easily as possible without > providing much fun. However, I don't want to let new users wade through the > low levels with overpowered characters. > Is it really that painfull and long? Once upon a time several of the people at PSU had a 'tournament' wherein the winner was the one with the most experienced character after an hour of play (without cheating of course :). Someone was able to rack up a 8th or 9th level character in that time. Of course, some character classes will rise faster than others, but a general strategy is possible for quick advancement. 1) gain enough treasure to buy several wands of summon elemental. 2) goto admin building in brest and use them in the 10 armies area. You will watch your experience jump very high, very fast this way. If you are seeking artifacts, go to the hole in the ground (mineshaft - I believe the map is called xyzz-mines) there are potentially 4 artifacts easily recoverable by a 8-10th level character. The 2 guarded by the titan are especially easy to get. (I would recogmend these maps be fixed BTW) > I propose that after a character has been rolled that the user should be prompted > for a desired starting level. The user would then be asked several questions to > ensure that they have sufficient knowledge of the game to deserve that starting > level. Only if the user successfully passes the quiz will they be allowed to > start at that level. Its a thought. But all one has to do is take a look at the code to get the answers! A lot of work for nothing if you ask me. -b.t. From crossfire-request Fri Jun 2 19:00:35 1995 Return-Path: Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Fri, 2 Jun 1995 19:00:23 +0200 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id KAA00798 for ; Fri, 2 Jun 1995 10:00:06 -0700 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma000670; Fri Jun 2 09:59:42 1995 Received: from pluto by cadence.Cadence.COM (5.61/3.14) id AA28779; Fri, 2 Jun 95 09:59:37 -0700 Received: by pluto (5.65+/1.5) id AA03022; Fri, 2 Jun 95 12:59:38 -0400 Date: Fri, 2 Jun 95 12:59:38 -0400 From: woodruff@cadence.com (Ken Woodruff) Message-Id: <9506021659.AA03022@pluto> To: crossfire@ifi.uio.no Subject: Starting at levels greater than 1 Status: RO I've been thinking about some mechanism for allowing players to start at a level higher than one since for experienced users the early levels become just a mad dash to gain experience as quickly and easily as possible without providing much fun. However, I don't want to let new users wade through the low levels with overpowered characters. I propose that after a character has been rolled that the user should be prompted for a desired starting level. The user would then be asked several questions to ensure that they have sufficient knowledge of the game to deserve that starting level. Only if the user successfully passes the quiz will they be allowed to start at that level. The questions would get harder for each level, we could top out at around level 10. The questions could be contained in a file in the library directory (say "levelquiz"), so could be site customizable. Some example questions: - What is the password needed to open the gates to Scorn? - What is the name of Gork's best friend? - What is the name of the spell that Yqreth guards in his tower? etc. Comments? --Ken +------------------------+---------------------------------------------+ | Ken Woodruff | Most Latin words in -us have plural in -i, | | woodruff@cadence.com | but not all, & so zeal not according to | +------------------------+ knowledge issues in such oddities as hiati, | | Disclaimer: What tote | octopi, omnibi, & ignorami; ... | | bag full of $20 bills? | Fowler, "Modern English Usage" | +------------------------+---------------------------------------------+