From leaf at real-time.com Sat Jun 1 00:02:40 2002 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] New Q In-Reply-To: <20020530003438.GA24692@hawthorn.csse.monash.edu.au> Message-ID: A first draft of the dragon guide is now online at: http://crossfire.real-time.com/dragons.html Let me know if there are suggestions or corrections. Thanks. - Rick From temitchell at sympatico.ca Sat Jun 1 12:32:37 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:27 2005 Subject: [CF-Devel] mithril armour Message-ID: <000f01c20992$527d1700$0a02a8c0@kameria> I was fixing the Sorig electric mithril in my arch and decided to make changes to the images, so I made a new anim for mithril armour, made a new anim for electric mithril armour, changed the arc for it, and changed the arc so that the Sorig mithril used this new animation. It works fine and looks pretty good, but I was wondering if there would be an issue with this on any maps or since the electric mithril and the regular mithril now have different faces (like for detection purposes?) I also have made a few new arcs (wolves anyone?)and touched up some images - where do I send them for perusal? I was also thinking that I would like to go through the archs and copy out all the cartoony images and make these into a new image set called toon so there would be base, clsc and toon. This image set wouldn't have the perspective tilt or light shading like the base set, but there are a lot of nice toony images there that would make a nice image set. What do you folks think of this - good idea - waste of time? From dnh at hawthorn.csse.monash.edu.au Sat Jun 1 20:36:00 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:27 2005 Subject: [CF-Devel] mithril armour In-Reply-To: <000f01c20992$527d1700$0a02a8c0@kameria> References: <000f01c20992$527d1700$0a02a8c0@kameria> Message-ID: <20020602013600.GA18471@hawthorn.csse.monash.edu.au> On Sat, Jun 01, 2002 at 01:32:37PM -0400, Todd Mitchell wrote: > I was fixing the Sorig electric mithril in my arch and decided to make > changes to the images, so I made a new anim for mithril armour, made a new > anim for electric mithril armour, changed the arc for it, and changed the > arc so that the Sorig mithril used this new animation. It works fine and > looks pretty good, COOL, this is what I like to hear. but I was wondering if there would be an issue with this > on any maps or since the electric mithril and the regular mithril now have > different faces (like for detection purposes?) I also have made a few new > arcs (wolves anyone?)and touched up some images - where do I send them for > perusal? send them to me, I currently have availible webspace and I will commit it to cvs for you if all is well. There wont be a an issue, the sorig armour is only given by sorig. An the elec armour is well, i'm not telling where it is.. but there isn't an issue =). > I was also thinking that I would like to go through the archs and copy out > all the cartoony images and make these into a new image set called toon so > there would be base, clsc and toon. This image set wouldn't have the > perspective tilt or light shading like the base set, but there are a lot of > nice toony images there that would make a nice image set. What do you folks > think of this - good idea - waste of time? The clsc set is meant to be a toon set, I just never got enough images (yes I created it with two other developers (BehTong and Peterm, may their souls not be forgotten ;)). I would love to start working on it again, if if you have interest I would be more than happy to show you the ropes and get you started. If you want to talk to me, the easiest way is to come onto #crossfire on the openprojects server and look for a nick containing 'bob' ;). I certainly hope any work you do decide to do is by no means a waste, as I have spent a goodly amount of work already on it =). dnh From dnh at hawthorn.csse.monash.edu.au Sat Jun 1 20:38:42 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:27 2005 Subject: [CF-Devel] Enchant Armour scrolls In-Reply-To: <20020601035115.GA10222@hawthorn.csse.monash.edu.au> References: <20020601035115.GA10222@hawthorn.csse.monash.edu.au> Message-ID: <20020602013842.GA26415@hawthorn.csse.monash.edu.au> As a side note, if no one responds I change it.. this is my policy so if you have an opinion on this somewhat key items, speak now or forever hold your peace. dnh > I propose to reduce the effects of these, curently I find a player can > easily get to 99.999.... % armour at which point there own bombs no > longer hurt and no monsters physical attack can do anything more then > sneeze a hp point off every few minutes. > > in apply.c there is this code: > apply.c: new_armour = armour->resist[ATNR_PHYSICAL] + > armour->resist[ATNR_PHY > SICAL]/25 + op->level/20 + 1; > apply.c: if (new_armour > 90) > apply.c: new_armour = 90; > apply.c: if (armour->magic >= (op->level / 10 + 1) > apply.c: || new_armour > op->level) > apply.c: new_draw_info(NDI_UNIQUE, 0,op,"to improve this > armour."); > apply.c: if (new_armour > armour->resist[ATNR_PHYSICAL]) { > apply.c: armour->resist[ATNR_PHYSICAL] = new_armour; > apply.c: armour->weight += armour->weight * 0.05; > apply.c: new_draw_info(NDI_UNIQUE, 0,op,"The armour value of this > equipme > nt"); > > If I simply change the 90's to 60's this should greatly reduce the > problem. I haven't tested how useful -40 AC is as I suspect most > monsters can still hit you, if this is a problem I will try and find a > way to reduce this too. > > If anyone has a better idea as to how to do this, ie, making the maximum > armour some sort of ratio to the initial armour I am all ears. Perhaps > even increasing the negative effects like increasing the armour weight > to make the benefits somewhat more offset. This is really only a problem > for higher level players though. > > dnh > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From yann.chachkoff at mailandnews.com Sun Jun 2 04:41:01 2002 From: yann.chachkoff at mailandnews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:27 2005 Subject: [CF-Devel] Enchant Armour scrolls Message-ID: <3CFBF2F9@mailandnews.com> >===== Original Message From David Hurst ===== >As a side note, if no one responds I change it.. this is my policy so if >you have an opinion on this somewhat key items, speak now or forever >hold your peace. > >dnh Please let us time to answer - not everyone has the opportunity to check mail every day ! > > >> I propose to reduce the effects of these, curently I find a player can >> easily get to 99.999.... % armour at which point there own bombs no >> longer hurt and no monsters physical attack can do anything more then >> sneeze a hp point off every few minutes. >> I agree with this... >> in apply.c there is this code: >> If I simply change the 90's to 60's this should greatly reduce the >> problem. ... but not really with your solution. IMO, changing the way the armour value for the wearer is calculated is the correct answer, not the way improve armour works. The Armour curve (the function giving the Arm coefficient based on the sum of the armour equipments) should be revised to make 99.99% more difficult to reach. ------------------------------------------------ Visit http://www.selentine.dyndns.org for a journey into a fantastic world ! (But don't expect too much...) ------------------------------------------------ From peterm at tonks.EECS.Berkeley.EDU Sun Jun 2 10:15:09 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:02:27 2005 Subject: [CF-Devel] mithril armour In-Reply-To: Your message of "Sun, 02 Jun 2002 11:36:00 +1000." <20020602013600.GA18471@hawthorn.csse.monash.edu.au> Message-ID: <200206021515.g52FF9q14548@tonks.EECS.Berkeley.EDU> > On Sat, Jun 01, 2002 at 01:32:37PM -0400, Todd Mitchell wrote: > > I was fixing the Sorig electric mithril in my arch and decided to make > > changes to the images, so I made a new anim for mithril armour, made a new > > anim for electric mithril armour, changed the arc for it, and changed the > > arc so that the Sorig mithril used this new animation. It works fine and > > looks pretty good, > > COOL, this is what I like to hear. New art is usually quite welcome. I can't see any catastrophes arising from this.... Thanks for the new art, I think it'll probably go in unless people disagree with you about it being nicer.... > The clsc set is meant to be a toon set, I just never got enough images > (yes I created it with two other developers (BehTong and Peterm, may > their souls not be forgotten ;)). I would love to start working on it I'm glad someone's still carrying the torch on the uh, "toony" set. I'd have been sad if all the work the original artists had done on it had gone to waste. PeterM From temitchell at sympatico.ca Sun Jun 2 11:58:59 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:27 2005 Subject: [CF-Devel] mithril armour References: <000f01c20992$527d1700$0a02a8c0@kameria> <20020602013600.GA18471@hawthorn.csse.monash.edu.au> Message-ID: <001101c20a56$ca97b3c0$0a02a8c0@kameria> ----- Original Message ----- From: "David Hurst" To: Sent: Saturday, June 01, 2002 9:36 PM Subject: Re: [CF-Devel] mithril armour > On Sat, Jun 01, 2002 at 01:32:37PM -0400, Todd Mitchell wrote: > > I was fixing the Sorig electric mithril in my arch and decided to make > > changes to the images, so I made a new anim for mithril armour, made a new > > anim for electric mithril armour, changed the arc for it, and changed the > > arc so that the Sorig mithril used this new animation. It works fine and > > looks pretty good, > > COOL, this is what I like to hear. > > but I was wondering if there would be an issue with this > > on any maps or since the electric mithril and the regular mithril now have > > different faces (like for detection purposes?) I also have made a few new > > arcs (wolves anyone?)and touched up some images - where do I send them for > > perusal? > > send them to me, I currently have availible webspace and I will commit > it to cvs for you if all is well. There wont be a an issue, the sorig > armour is only given by sorig. An the elec armour is well, i'm not > telling where it is.. but there isn't an issue =). > > > I was also thinking that I would like to go through the archs and copy out > > all the cartoony images and make these into a new image set called toon so > > there would be base, clsc and toon. This image set wouldn't have the > > perspective tilt or light shading like the base set, but there are a lot of > > nice toony images there that would make a nice image set. What do you folks > > think of this - good idea - waste of time? > > The clsc set is meant to be a toon set, I just never got enough images > (yes I created it with two other developers (BehTong and Peterm, may > their souls not be forgotten ;)). I would love to start working on it > again, if if you have interest I would be more than happy to show you > the ropes and get you started. If you want to talk to me, the easiest > way is to come onto #crossfire on the openprojects server and look for a > nick containing 'bob' ;). I certainly hope any work you do decide to do > is by no means a waste, as I have spent a goodly amount of work already > on it =). > > dnh > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at sonic.net Sun Jun 2 19:19:22 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Enchant Armour scrolls References: <3CFBF2F9@mailandnews.com> Message-ID: <3CFAB60A.7010405@sonic.net> Yann Chachkoff wrote: > ... but not really with your solution. IMO, changing the way the armour value > for the wearer is calculated is the correct answer, not the way improve armour > works. The Armour curve (the function giving the Arm coefficient based on the > sum of the armour equipments) should be revised to make 99.99% more difficult > to reach. The problem I think is that if it is possible to give 5 or 6 armors with 90% resistance, it is fairly difficult to come up with a formula that prevents that from getting 99.9% without special casing it (eg, ir armor > 90 then do something special if more armor is added). Although, as I think about it, I thought such a case was what was proposed adn then done with the partiail resistance code. You could get up to something like 90% resistance (any resistance, just not physical) - the only way you could get higher than that is if the item itself gave a high resistance (so the potion or spell that gives 95% works, but that isn't added on with the other resistances, and just becomes the total resistance.) Taking a look at the code, I notice that there is special logic for potion resistances, and it doesn't overall use that logic. I personally think that maxing the value at 60 for armor improvements is just fine. That is basically the same as the max for artifact armors - and certainly much higher than you can get for artifacts helms, shields, whatever else. Various maximums have been put on things like improving your weapon, so I don't see much a problem with doing the same thing for armor. It should make things tougher, which probably isn't a bad thing. Using the scheme of maxing resistance at 90 as above just means you have one really good piece of armor you put on, and your now maxed out, so your shield, hlem, whatever else can be ones that give you other good benefits and you don't care about the armor value on them. If armor is maxed at 60, it means your still going to want to wear a few of those good armor items to get your armor value up. Here is a comparison for 60 vs 90% max value # items 1 60 90 2 84 99 3 94 99 4 98 99 5 99 99 Since the resist field is an integer, the fractions should get dropped, which I did in the below table. So still not too hard to get really high resistance values - you now just need to wear more than 2 items to do so. But given that, then that may really not change too much - but I'm not too familiar with the really high level play. From mwedel at sonic.net Sun Jun 2 19:23:25 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] mithril armour References: <000f01c20992$527d1700$0a02a8c0@kameria> Message-ID: <3CFAB6FD.90009@sonic.net> Todd Mitchell wrote: > I was fixing the Sorig electric mithril in my arch and decided to make > changes to the images, so I made a new anim for mithril armour, made a new > anim for electric mithril armour, changed the arc for it, and changed the > arc so that the Sorig mithril used this new animation. It works fine and > looks pretty good, but I was wondering if there would be an issue with this > on any maps or since the electric mithril and the regular mithril now have > different faces (like for detection purposes?) I think DB answered most of the rest of the questiosn - I'll just answer this aspect. If you modify the archetype of the object, then all instances of that object should automatically get updated where ever they may be. When an object is saved in a map or player file, only the differences between it and the archetype it is based on is saved. When the object is then loaded at a future point, it first copies over the values from the archetype into the object, and then over loads any values that may be specified in the file it is loading from. So in almost all cases, the only change that needs to get done is to the archetype itself, and everything else automatically gets fixed up. From mwedel at sonic.net Sun Jun 2 19:47:57 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. Message-ID: <3CFABCBD.7070700@sonic.net> Dropping this to the list for some prior discussion and to perhaps get some addtional refinements. For the most part, this change will not be directly visible to the players (but such a change allows new features not currently possible). Currently, the type of object determines how man you can wear, and if you can wear it at all. It is hard coded that you can wear 2 rings, 1 helmet, 1 suit of armor, etc. some of the flag_can_use_armor refine this in a very primitive way. The change would basically modify equipable objects to specify whay body location (or equip location) they go on. For example, helmets would have a line added like 'equip_location head', armor would have 'equip_location torso', rings 'equip_location finger', etc. Objects could specify multiple locations - 'equip_location weapon_hand,shield_hand' could be used to allow 2 handed weapons. Internally, these verbal descriptions would get converted into a bitmask used in the object. This imposes some limitations (can't have something like equip_location weapon_hand,weapon_hand' so say it should use 2 weapon hands). The advantage of using a bitmask for this is that it is small enough it can efficiently been sent to the client to make use of. Now each monster would have a body type, like 'body_type humanoid' or 'body_type quadriped' or whatever else. Descriptions for them might be like: humanoid: head 1 torso 1 weapon_hand 1 shield_hand 1 finger 2 neck 1 feet 1 ... And the quadriped (horse or other 4 legged creature): feet 2 weapon_hand 0 shield_hand 0 ... This is where the semantic differnce of using body location vs equip_location comes in. Saying a humanoid has 2 fingers and 1 feet isn't really right. But it means that they are only allowed 2 fingers and 1 pair of boots. If instead these are described as 'ring' and 'boot', it makes more sense. As I type this, going with equipment type location may make more sense - you could add to the quadriped something like: barding 1 Which means it really needs special armor. Now the player/monsters will have a copy of the body_type information in the object structure in addition to the one in the archetype. Whenever an object is equipped/unequipped, this copy information is added. So for example, when you equip something, the equip logic sees what flags (equip location) are set. Then looks in the body_spaces information in the object to see if there are spaces available. IF so, it applies the object, and updates teh body_spaces information. If not, it unapplies the needed spaces if applicable. One thing this allows in addition to two handed weapons is further refinement for different races. Eq, the fireborn could be set up with 'rings 3 and amulets 2' to let them wear more of those protective devices since they can't wear anything else. The Q should certainly be allowed to wear a shield, even if it can wear armor. You could add ettin races, which let you were 2 helmets, etc. Now, for things like religions or classes which prevent use of certain items, the logic there could add appropriate force objects that use up the slots for the objects. Eg, a force for a god that doesn't allow weapon use would have something like 'equip_location weapon_hand'. Force objects would be special in the sense that they bypass the normal equip logic and just use up the slots, so even if the race doesn't have a weapon_hand, the force will still be equipped. Now the only really noticable aspect to this to players would be changing the range locations. They current range location is really a leftover from long ago. With this change, I would make it so there is only 1 range slot (which horns, bows, wands, skill tools, etc, would all vie for). This simplifies the code a great deal on the server, and probably makes more sense anyway. I'm not sure how noticable this really would be to most people - I pretty much never use teh ability to rotate through the range of row slots - much easier to bind the actions to certain keys. Thoughts/suggestions? From pstolarc at theperlguru.com Sun Jun 2 22:49:30 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <3CFABCBD.7070700@sonic.net> References: <3CFABCBD.7070700@sonic.net> Message-ID: On Sun, 02 Jun 2002 17:47:57 -0700, Mark Wedel wrote: > Now the only really noticable aspect to this to players would be changing the >range locations. They current range location is really a leftover from long >ago. With this change, I would make it so there is only 1 range slot (which >horns, bows, wands, skill tools, etc, would all vie for). This simplifies the >code a great deal on the server, and probably makes more sense anyway. > > I'm not sure how noticable this really would be to most people - I pretty much >never use teh ability to rotate through the range of row slots - much easier to >bind the actions to certain keys. > > Thoughts/suggestions? The rest of this looked good. One slight problem with multiple range items is that I like to use the enhanced bow for the strength bonus on my dragon chars. Also, some horn (Eorlingas?) has a charisma bonus. Changing this code would mean that you lose the strength bonus if you try using wizardry or somesuch, and equip a talisman (de-equipping the bow, if I'm understanding correctly.) But then again, that may be a good thing. It's a somewhat stupid way to get +1 strength. -Philip From dnh at hawthorn.csse.monash.edu.au Mon Jun 3 09:47:22 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <3CFABCBD.7070700@sonic.net> References: <3CFABCBD.7070700@sonic.net> Message-ID: <20020603144722.GA5956@hawthorn.csse.monash.edu.au> > Currently, the type of object determines how man you can wear, and if you > can wear it at all. It is hard coded that you can wear 2 rings, 1 helmet, > 1 suit of armor, etc. some of the flag_can_use_armor refine this in a very > primitive way. yeah it sucks.. > The change would basically modify equipable objects to specify whay body > location (or equip location) they go on. For example, helmets would have a > line added like 'equip_location head', armor would have 'equip_location > torso', rings 'equip_location finger', etc. Objects could specify multiple > locations - 'equip_location weapon_hand,shield_hand' could be used to allow > 2 handed weapons. Before I go any further, i would like to point out (and yes this is through experience) that a weapon arm and a shield arm are the same thing. For example, florentine is the style whereby a fighter uses two weapons. I know we have been over the problem of being able to equip two weapons, but I think it worth pointing out, that perhaps just 'arm' would be more useful in the long term =). I suppose it doesn't make a great deal of difference (a player special florentine (sword master) type character could be devised that maps shield arm to weapon arm but in the interests of logic.... ). > Internally, these verbal descriptions would get converted into a bitmask > used in the object. This imposes some limitations (can't have something > like equip_location weapon_hand,weapon_hand' so say it should use 2 weapon > hands). The advantage of using a bitmask for this is that it is small > enough it can efficiently been sent to the client to make use of. Why does this limit 2 handed weapons? I don't follow your logic, surely having that equip location would block the use of the shield thus behaving like a two hander? > Now each monster would have a body type, like 'body_type humanoid' or > 'body_type quadriped' or whatever else. Descriptions for them might be like: Would it be better to be able to use either format? or even just be able to modify anything you want? for example if you want an ettin, its just a humanoid with head: 2? > humanoid: > head 1 > torso 1 > weapon_hand 1 > shield_hand 1 > finger 2 > neck 1 > feet 1 > ... > > And the quadriped (horse or other 4 legged creature): > > feet 2 > weapon_hand 0 > shield_hand 0 > ... > > This is where the semantic differnce of using body location vs > equip_location comes in. Saying a humanoid has 2 fingers and 1 feet isn't > really right. But it means that they are only allowed 2 fingers and 1 pair > of boots. If instead these are described as 'ring' and 'boot', it makes > more sense. yes, but it causes more confusion when using something which isn't specifically called a 'boot'. You end up with items like sandles (boot) which is what we currently have of course. > As I type this, going with equipment type location may make more sense - > you could add to the quadriped something like: > > barding 1 > > Which means it really needs special armor. cool. dragon_body 1, means it can wear that specially crafted dragon suit made by the blacksmith in moria or something ;). > Now the player/monsters will have a copy of the body_type information in > the object structure in addition to the one in the archetype. Whenever an > object is equipped/unequipped, this copy information is added. > > So for example, when you equip something, the equip logic sees what flags > (equip location) are set. Then looks in the body_spaces information in the > object to see if there are spaces available. IF so, it applies the object, > and updates teh body_spaces information. If not, it unapplies the needed > spaces if applicable. coolness > One thing this allows in addition to two handed weapons is further > refinement for different races. Eq, the fireborn could be set up with > 'rings 3 and amulets 2' to let them wear more of those protective devices > since they can't wear anything else. The Q should certainly be allowed to > wear a shield, even if it can wear armor. You could add ettin races, which > let you were 2 helmets, etc. yuppo, coolness > Now, for things like religions or classes which prevent use of certain > items, the logic there could add appropriate force objects that use up the > slots for the objects. Eg, a force for a god that doesn't allow weapon use > would have something like 'equip_location weapon_hand'. Force objects > would be special in the sense that they bypass the normal equip logic and > just use up the slots, so even if the race doesn't have a weapon_hand, the > force will still be equipped. good work around. > Now the only really noticable aspect to this to players would be changing > the range locations. They current range location is really a leftover from > long ago. With this change, I would make it so there is only 1 range slot > (which horns, bows, wands, skill tools, etc, would all vie for). This > simplifies the code a great deal on the server, and probably makes more > sense anyway. I know I certainly very rarely use range weapons. The only one I ever use is the bow which gives str +1 and only for the bonus. > I'm not sure how noticable this really would be to most people - I pretty > much never use teh ability to rotate through the range of row slots - much > easier to bind the actions to certain keys. > > Thoughts/suggestions? Well summarised, I like my idea even more when you explain it ;). One other interesting side effect is the ability for a client to generate a 'body map' very easily. the DX/SDL clients already did this, by mapping every item to an area, this is a rather yucky way to do it (every new item breaks it, as in it does go in the right spot, or at least that was my experience). It may also be quite useful for the monster code, in that when you equip a monster it is is more logical, or something.. not sure about this point now ;). I feel this is a very positive base change which allows alot easier feature creation, a very important part of any game platform. I think it will make alot of ideas suddenly become very viable, the most obvious are special combo items that block other times, like a two handed sword.. but i'm sure through time those clever map makers will devise devious and creative uses for this code. *tick* (the Darth_bob tick of approval ;)) dnh From temitchell at sympatico.ca Tue Jun 4 01:06:30 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. References: <3CFABCBD.7070700@sonic.net> <20020603144722.GA5956@hawthorn.csse.monash.edu.au> Message-ID: <001001c20b8d$f8c74b60$0a02a8c0@kameria> following the comments by Mark and David; I had too much fun thinking about this...please shoot me >>Before I go any further, i would like to point out (and yes this is >>through experience) that a weapon arm and a shield arm are the same >>thing. For example, florentine is the style whereby a fighter uses two >>weapons. I know we have been over the problem of being able to equip two >>weapons, but I think it worth pointing out, that perhaps just 'arm' >>would be more useful in the long term =). I suppose it doesn't make a >>great deal of difference (a player special florentine (sword master) >>type character could be devised that maps shield arm to weapon arm but >>in the interests of logic.... ). I noticed you mentioned a two handed sword but didn't mention bows. I found it unusual that I could equip a bow and a shield in Crossfire. If you couldn't equip a bow or crossbow and a shield at the same time, mor people might like to use throwing weapons instead which would be good. It would also mean that less people would use bows or crossbows however since it would not be so easy to switch between ranged and close combat with a shield. >> humanoid: >> head 1 >> torso 1 >> weapon_hand 1 >> shield_hand 1 >> finger 2 > >neck 1 >> feet 1 >> ... > >> And the quadriped (horse or other 4 legged creature): > >. feet 2 >> weapon_hand 0 >> shield_hand 0 >> ... > >> This is where the semantic differnce of using body location vs >> equip_location comes in. Saying a humanoid has 2 fingers and 1 feet isn't >> really right. But it means that they are only allowed 2 fingers and 1 pair >> of boots. If instead these are described as 'ring' and 'boot', it makes >> more sense. >yes, but it causes more confusion when using something which isn't >specifically called a 'boot'. You end up with items like sandles (boot) >which is what we currently have of course. I'm all for greater differences between the races - makes things more interesting for sure. One thing, would a four armed creature be able to use 2 shields? For that matter if there is not a sword_arm, shield_arm kind of thing, but just arms, wouldnt you have to check if a shield was already equipped on one of the arms to avoid the ol' double shield trick with regular two armed fellas? If you had just arms you could have a five armed beastie with five swords (or 3 swords and a bow, or 2 bows and a shield...gets pretty grim from a writing it view, but sounds like fun for creature making). I think that you shouldn't use finger 2 and feet 1 though since this is just goofy (only two fingers and one foot? ) Since the majority of magic boots come in pairs you could just assume that 2 is the standard (or call it something else since seeing a quadreped with 2 feet is silly) and if feet is not 2 then they need a special item. (your centaur gets shoes+2 made at the blacksmiths...) octaped: head 1 torso 1 hands 5 (counts for weapons and rings) neck 1 feet 3 (no boots for you unless we assume a pair is 3 at your cobblers) Perhaps it would be best to stick to weapon_arm, shield_arm. You can use hand for the ring slots (the old 'one_ring_per_hand_since_their_mystic_energy_creates_interference' rule) octaped: head 1 torso 1 weapon_arm 1 (only one weapon allowed) shield_arm 1 (only one shield allowed (I assume, although you mentioned two helms on an ettin)) hands 5 (he can still make obcene gestures at you with the other 3) neck 1 > > Now the only really noticable aspect to this to players would be changing > > the range locations. They current range location is really a leftover from > > long ago. With this change, I would make it so there is only 1 range slot > > (which horns, bows, wands, skill tools, etc, would all vie for). This > > simplifies the code a great deal on the server, and probably makes more > > sense anyway. > > I know I certainly very rarely use range weapons. The only one I ever > use is the bow which gives str +1 and only for the bonus. > I think that ranged weapons are undervaluated in the game since there are not real terrain factors (no_fly_pass flag and an update to the monster attack target routine anyone?) to encourage their use. It should be fairly hard to get by without ranged weapons of some sort (either as a backup to spells or as an alternate attack method to avoid closing with monsters). Perhaps heavy fighter types could get away without them, but the majority of classes should find them indispensible. You can put monsters in little rooms to prevent them from all rushing at the players, but this isn't as good as having actual terrain (water, barrels, tables, low walls...) that would allow missile weapons through but block movement (except special movement like flying). It also might give players more time to equip a bow or whip out that horn or wand if the monsters didn't always rush at them but attacked and could be attacked from a distance, which might make up for having only one ranged slot and the loss of that shield. Ranged weapons really expand the possibilities for combat and a great ranged combat system should include some terrain factors. -tm From mwedel at sonic.net Tue Jun 4 02:26:55 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. References: <3CFABCBD.7070700@sonic.net> Message-ID: <3CFC6BBF.9070404@sonic.net> pstolarc@theperlguru.com wrote: > > The rest of this looked good. One slight problem with multiple range > items is that I like to use the enhanced bow for the strength bonus on > my dragon chars. Also, some horn (Eorlingas?) has a charisma bonus. > Changing this code would mean that you lose the strength bonus if you > try using wizardry or somesuch, and equip a talisman (de-equipping the > bow, if I'm understanding correctly.) > > But then again, that may be a good thing. It's a somewhat stupid way > to get +1 strength. Yeah. But as it is now, it doesn't make a lot of conceptual sense that you have a bow, wand, rod, horn, and talisman all in hand at one time. Fortunately, there are not too many range items that really give such benefits, so its not likely to change balance much. It is possible to create different body locations for these items, but this gets a little odd. It really doesn't make a lot of different - largely the idea is to get rid of the logic in the server that deals with rotation of ranges and so forth. From mwedel at sonic.net Tue Jun 4 02:54:13 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. References: <3CFABCBD.7070700@sonic.net> <20020603144722.GA5956@hawthorn.csse.monash.edu.au> Message-ID: <3CFC7225.8070907@sonic.net> David Hurst wrote: >>The change would basically modify equipable objects to specify whay body >>location (or equip location) they go on. For example, helmets would have a >>line added like 'equip_location head', armor would have 'equip_location >>torso', rings 'equip_location finger', etc. Objects could specify multiple >>locations - 'equip_location weapon_hand,shield_hand' could be used to allow >>2 handed weapons. >> > > Before I go any further, i would like to point out (and yes this is > through experience) that a weapon arm and a shield arm are the same > thing. For example, florentine is the style whereby a fighter uses two > weapons. I know we have been over the problem of being able to equip two > weapons, but I think it worth pointing out, that perhaps just 'arm' > would be more useful in the long term =). I suppose it doesn't make a > great deal of difference (a player special florentine (sword master) > type character could be devised that maps shield arm to weapon arm but > in the interests of logic.... ). Yes - this is true. But as said, the problem is really how you limit using two weapons at the same time. Using two custom improved weapons would really throw things out of balance. You could certainly just say that you have 2 arms, and a shield uses one arm and a weapon uses an arm, and that you could use 2 weapons or two shields. Using two shields probably isn't that much a problem, but 2 weapons certainly are. I'm not too concerned about the two weapon code - a lot of other work would need to be done for that to work in a sane function (as the code is now, basically the two weapons abilities would just get added together). Also, seperating into weapon arm and shield arm makes doing 2 handed weapons easier. > > >>Internally, these verbal descriptions would get converted into a bitmask >>used in the object. This imposes some limitations (can't have something >>like equip_location weapon_hand,weapon_hand' so say it should use 2 weapon >>hands). The advantage of using a bitmask for this is that it is small >>enough it can efficiently been sent to the client to make use of. >> > > Why does this limit 2 handed weapons? I don't follow your logic, surely > having that equip location would block the use of the shield thus > behaving like a two hander? If you do something like 'equip location weapon_hand,shield_hand', this would have the effect you talk about. However, if each option to the equip_location is just a 1/0 value, and stored such in the object structure, specifying the same location twice has no extra effect. That is one reason why doing weapon hand and shield hand seperately make that aspect easier - you just specify both locations. > Would it be better to be able to use either format? or even just be able > to modify anything you want? for example if you want an ettin, its just > a humanoid with head: 2? I've thought about it, and it probably makes a lot of sense that the body type information is stored within the object and not the archetype. I think I've learned from the past that having stuff in the archetype that is non modifyable on an object basis always causes problems. This actually makes things a little easier - it means more information in the object structure (1 byte * number of unique body locations), but it reduces the need of the loader to take the body_type and then link up the appropriate body type information. This also, interesting enough, means that it can be applied to weapons. If these location values are signed values, it means you could have something like: object skill_florentine_fighting msg Florentine style lets you fight with too weapons. However, with this training, you are know longer proficient in use of the shield. endmsg weapon_hand -1 shield_hand 1 end the shield_hand values causes that to get filled up - remember, for all equipped objects, the location information is just summed up to note how many of those slots are used up. The problem is that this then complicates communicating this information to the client. Much harder to communicate (in an efficient manner) that this weapon uses 2 hands and not just one (there are still ways, but it could be conceivable to have like a super powerful ring that uses both fingers - if you extend this with many objects, it gets trickier). >> This is where the semantic differnce of using body location vs >> equip_location comes in. Saying a humanoid has 2 fingers and 1 feet isn't >>really right. But it means that they are only allowed 2 fingers and 1 pair >>of boots. If instead these are described as 'ring' and 'boot', it makes >>more sense. >> > > yes, but it causes more confusion when using something which isn't > specifically called a 'boot'. You end up with items like sandles (boot) > which is what we currently have of course. Yeah. I guess going with the object saying what body part, but allowing them to use multiple body parts work out. Thus, you could actually give the human 10 fingers, but powerful rings use 5 fingers. You could get this really complicated (eg, minor rings only use 1 finger, moderate rings 3 fingers, etc). > > cool. dragon_body 1, means it can wear that specially crafted dragon > suit made by the blacksmith in moria or something ;). Yep. The problem is that these definitions need to get added in. But for something like the Q, you could have something like 'tail', and have special tail armor that gives some minor benefit. > > One other interesting side effect is the ability for a client to > generate a 'body map' very easily. the DX/SDL clients already did this, > by mapping every item to an area, this is a rather yucky way to do it > (every new item breaks it, as in it does go in the right spot, or at > least that was my experience). This shouldn't be much a problem with the client_type information that was added, since any new items should have a proper client_type information. As I think about this, using non bit mask values means you can't really communicate where an item goes efficiently (there are still ways to do this - I guess it wouldn't be too hard to do something like send a location byte followed by number of slots it uses up, and just do that for all the locations the item may use. Since most probably most all items would only go on 1 body part, this may in fact be more efficient (1 byte for location, 1 byte for slots used up is actually less than say a 32 bit bitmask). > It may also be quite useful for the monster code, in that when you equip > a monster it is is more logical, or something.. not sure about this > point now ;). Well, it would basically replace all the CAN_USE flags currently in use - if the mosnter has a location for it, it can use it. From mwedel at sonic.net Tue Jun 4 03:05:45 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. References: <3CFABCBD.7070700@sonic.net> <20020603144722.GA5956@hawthorn.csse.monash.edu.au> <001001c20b8d$f8c74b60$0a02a8c0@kameria> Message-ID: <3CFC74D9.205@sonic.net> Todd Mitchell wrote: > following the comments by Mark and David; > I had too much fun thinking about this...please shoot me > > >>>Before I go any further, i would like to point out (and yes this is >>>through experience) that a weapon arm and a shield arm are the same >>>thing. For example, florentine is the style whereby a fighter uses two >>>weapons. I know we have been over the problem of being able to equip two >>>weapons, but I think it worth pointing out, that perhaps just 'arm' >>>would be more useful in the long term =). I suppose it doesn't make a >>>great deal of difference (a player special florentine (sword master) >>>type character could be devised that maps shield arm to weapon arm but >>>in the interests of logic.... ). >>> > > I noticed you mentioned a two handed sword but didn't mention bows. I found > it unusual that I could equip a bow and a shield in Crossfire. If you > couldn't equip a bow or crossbow and a shield at the same time, mor people > might like to use throwing weapons instead which would be good. It would > also mean that less people would use bows or crossbows however since it > would not be so easy to switch between ranged and close combat with a > shield. If bows were overused, this may be something worth considering. But it seems that bows are generally underused, so I don't really think that making them even harder/less worthwhile to use would necessarily be a good thing. > I'm all for greater differences between the races - makes things more > interesting for sure. One thing, would a four armed creature be able to use > 2 shields? For that matter if there is not a sword_arm, shield_arm kind of > thing, but just arms, wouldnt you have to check if a shield was already > equipped on one of the arms to avoid the ol' double shield trick with > regular two armed fellas? If you had just arms you could have a five armed > beastie with five swords (or 3 swords and a bow, or 2 bows and a > shield...gets pretty grim from a writing it view, but sounds like fun for > creature making). > I think that you shouldn't use finger 2 and feet 1 though since this is just > goofy (only two fingers and one foot? ) Since the majority of magic boots > come in pairs you could just assume that 2 is the standard (or call it > something else since seeing a quadreped with 2 feet is silly) and if feet is > not 2 then they need a special item. (your centaur gets shoes+2 made at the > blacksmiths...) If you just had arms, there would be nothing preventing someone from using 2 shields. This is odd, but I don't consider it too much a problem. Much more a problem is using 2 weapons, because weapons have the most enchantments (And the fact that players can enchant them), and that would really mess up the balance. But yes, if you had a 4 armed creature, split between 2 weapon arms and 2 shield arms, it could then use two shields. As per the other method, yeah, I think allowing items to use multiple of the same locaiton probably makes more senses. Fix that odd behaviour of only 1 feet or 2 fingers. > > octaped: > head 1 > torso 1 > hands 5 (counts for weapons and rings) > neck 1 > feet 3 (no boots for you unless we assume a pair is 3 at your cobblers) > > Perhaps it would be best to stick to weapon_arm, shield_arm. You can use > hand for the ring slots (the old > 'one_ring_per_hand_since_their_mystic_energy_creates_interference' rule) Note that hands would be be a type - you would have fingers and weapon_hands and shield_hands. This, for example, means you could have a race with 6 fingers/hand, which may give a minor advantage (See previous messages). feet 3 wouldn't actually prevent anything. Stuff you put on does not have to be an exact match (eg, if you have 10 fingers, 2 rings that use 5 fingers each would be the norm). Thus, feet 3 would let you wear one pair of boots, and still have a foot left over. So if there was just a singular boot, he could but that on. Note that the real enforcement is having different types. For example, humans would have 'feet', but horses/centaurs should have 'hooves' - they obviously just can't put on human boots. > > I think that ranged weapons are undervaluated in the game since there are > not real terrain factors (no_fly_pass flag and an update to the monster > attack target routine anyone?) to encourage their use. It should be fairly > hard to get by without ranged weapons of some sort (either as a backup to > spells or as an alternate attack method to avoid closing with monsters). > Perhaps heavy fighter types could get away without them, but the majority of > classes should find them indispensible. You can put monsters in little > rooms to prevent them from all rushing at the players, but this isn't as > good as having actual terrain (water, barrels, tables, low walls...) that > would allow missile weapons through but block movement (except special > movement like flying). It also might give players more time to equip a > bow or whip out that horn or wand if the monsters didn't always rush at them > but attacked and could be attacked from a distance, which might make up for > having only one ranged slot and the loss of that shield. Ranged weapons > really expand the possibilities for combat and a great ranged combat system > should include some terrain factors. The problem on this goes back to cases where there were monsters constrained in ways that using range weapons made sense. The problem is that unless the monster has a range weapon to return fire with, it amounted to a safe kill for a player. And this causes various problems. There is also the problem that if you try to make the maps multi player accessible, the hallways sort of need to be more than 1 space wide. But this also makes the range weapons harder to deal with. I think some of the problem is that there is a tough balancing act. You pretty much always want that melee weapon to do more damage, with the advantage of the range weapon the fact you have some distance/safety. The problem is movement on many monsters is fast enough that your not going to get too many shots with that weapon before the monster closes anyways. The fact that most combats in crossfire last in the seconds greatly limits that amount of tactics that one can employ. From temitchell at sympatico.ca Tue Jun 4 21:32:46 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. Message-ID: <001301c20c39$475335e0$0a02a8c0@kameria> Mark Wendel said: > If bows were overused, this may be something worth considering. >But it seems that bows are generally underused, so I don't really think that making them even >harder/less worthwhile to use would necessarily be a good thing. I agree that bows are underused but I don't think that making them two handed would be too bad. There is a bigger problem with missile combat in general (see below). Also there could be bows that incorporate defensive or resistance bonuses to compensate for this. Same as making two handed swords more powerful for the same reason. It is just weird having a bow and a shield equiped is all. > If you just had arms, there would be nothing preventing someone from using 2 > shields. This is odd, but I don't consider it too much a problem. > > Much more a problem is using 2 weapons, because weapons have the most > enchantments (And the fact that players can enchant them), and that would really > mess up the balance. I would have thought the problem with multiple weapons would be multiple attacks (and all associated with that - seperate chance to hit, seperate damage) not so much balance since most really powerful swords could be designated two handed, or creatures would also have the advantage of multiple weapons as well or a similar method would address balance. The same issue you mention could be applied to all items, a fourlegged fellow could wear two sets of magic boots which would upset balance or otherwise mess something up. I think however that not allowing multiple weapons would be a good thing for the time being because it would have a large impact on combat. For monsters, game balance from weapon bonuses is not a problem presumably so if a 9 armed monster could use swords and had 'weapon_arm 7' the only issue would be multiple attacks presumably. > Note that the real enforcement is having different types. For example, humans > would have 'feet', but horses/centaurs should have 'hooves' - they obviously > just can't put on human boots. Yes, I think it would be better to make a distinction between locomotion method (noped, monoped, biped, quadraped, septaped...or maybe none, feet2, hoves2, claws2, hoves4, paws4, hoves6, paws6 or something) rather than count the number of feet, then create items for those other kinds of locomotion (horseshoes of levitation, spider shoes +2, dragon spats of havoc) If you don't have two feet you can't wear normal boots. This saves creating singular boots and counting feet- and mixing boot types which might be messy or unbalanced (a centaur player would have an advantage with two sets of boots, and what if those sets interfere with each other. Having types allows you to change the boot objects to special boots just by changing their location and the name, but otherwise they work the same. Then you can go in for 'feet', 'hooves', dragon feet, spider legs or whatever. You could of course eliminate this and say that all boots fit all types (magically or thorough an off-shore instant boot exchange program), but it might not be as much fun although it would simplify things greatly. > Note that hands would be be a type - you would have fingers and weapon_hands > and shield_hands. > This, for example, means you could have a race with 6 fingers/hand, which may > give a minor advantage (See previous messages). As for rings, it would be simpler to say one per 'hand' instead of worrying about counting fingers. This does not confuse with arm (as in weapn_arm, shield_arm, and can be applied liberally to mean any 'active' appendage or (fireborn have 4 'hands' or something.) By active appendage it implies that rings would not work if worn on toes or other protruding apendages... > > I think that ranged weapons are undervaluated in the game since there are > > not real terrain factors (no_fly_pass flag and an update to the monster > > attack target routine anyone?) to encourage their use. It should be fairly > > hard to get by without ranged weapons of some sort (either as a backup to > > spells or as an alternate attack method to avoid closing with monsters). > > Perhaps heavy fighter types could get away without them, but themajority of > > classes should find them indispensible. You can put monsters in little > > rooms to prevent them from all rushing at the players, but this isn't as > > good as having actual terrain (water, barrels, tables, low walls...) that > > would allow missile weapons through but block movement (except special > > movement like flying). It also might give players more time to equip a > > bow or whip out that horn or wand if the monsters didn't always rush at them > > but attacked and could be attacked from a distance, which might make upfor > > having only one ranged slot and the loss of that shield. Ranged weapons > > really expand the possibilities for combat and a great ranged combat system > > should include some terrain factors. > > > The problem on this goes back to cases where there were monsters constrained > in ways that using range weapons made sense. > > The problem is that unless the monster has a range weapon to return fire with, > it amounted to a safe kill for a player. And this causes various problems. I would say this would not increase this problem but could be a solution for many cases where this exists now. Maps are evaluated for this sort of problem and good maps would avoid this and this is already too common in the way monsters are constrained now (especially with monsters in rooms and seeking weapons). It would actually allow more ways to avoid this issue. > > There is also the problem that if you try to make the maps multi player > accessible, the hallways sort of need to be more than 1 space wide. But this > also makes the range weapons harder to deal with. Again this is reversed, since this change would allow maps with larger open spaces and less hallways and actually give more options and elbow room for multiplayer tactics. > > I think some of the problem is that there is a tough balancing act. You > pretty much always want that melee weapon to do more damage, with theadvantage > of the range weapon the fact you have some distance/safety. The problem is > movement on many monsters is fast enough that your not going to get too many > shots with that weapon before the monster closes anyways. The fact that most > combats in crossfire last in the seconds greatly limits that amount of tactics > that one can employ. That is the current problem, which makes ranged weapons less useful. Melee weapons should and will remain more powerful, but by building in a pass flag for some objects allowing flying but still blocking creature movement you can create scenarios where the monsters do not/cannot close on the player(s) but remain at a distance, or can attack with arrows oe spells while they file through a narrow opening (coming across a bridge or down a stair) to provide some pacing to the fight. You can have the bridge of death scenario where narrow walkways work to the players disadvantage rather than their advantage. You would have to modify the monster code to check if there is a path for flying so the monster that are able to can still attack or this wouldn't work. As you say this is the biggest part of the job. I have not gotten far enough in my learnin to really understand the code (but I have been looking). It ceratinly wouldn't replace melee weapons as the power items, but it would make missile weapons much more useful (also flying, and jumping). From mwedel at sonic.net Tue Jun 4 23:05:32 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Java Editor bug. Message-ID: <3CFD8E0C.8090207@sonic.net> Minor bug in the java editor - if a multipart object spans tiled maps, the editor is unable to load the map - it throws an exception. An example of this is the world_121_116 in the maps-bigworld directory. But it wouldn't be hard to immitate - just put the head of a multipart object at the far right or bottom of a map. I haven't looked at the java code. The right thing to do would probably just link in the parts that are on the map in question, and ignore the parts off the map. This might mess up some cut/paste operations, but this is probably a pretty rare occurance. Thought I should at least mention it. From mwedel at sonic.net Wed Jun 5 00:12:01 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] maps-bigworld input sought. Message-ID: <3CFD9DA1.6080904@sonic.net> So I've been doing some work on the maps-bigworld distribution. But seeking some thoughts/comments. Ideally, most maps should be located on the main continent to give a feeling of cohesiveness. Its a bit cooler to say 'ahh - that maps is northwest of here' than 'its in some place - just hop on a ship in scorn and your there'. But some maps I'm not really familiar with, so with those, I seek some input. Lake_County: The map itself (kundi_area) certainly has a look that it should be part of something larger (eg, rivers and roads that run off the edges). So my personal thought is that this should be be located someplace on the real map - it would fit in better. Maybe someplace south of brest? anyone see a reason that shouldn't happen? What level range are these maps? destiny maps: like lake_count above, the map itself (kandora) has a feeling of being something large. IT would need some work (the new world maps won't use the city icons anymore), but this could also be located someplace on the world map it would seem. What level range are these maps? dragonisland: I think that this should be located to some actual island on the content someplace - this should be pretty easy to do. This would be nice in that if down the road we allow boats that sail the oceans, this is someplace real on the world. dtabb: This was orignally the start of a new continent which really never went anyplace. I think this should be located somewhere on the main continent, and thats what I'll do unless there is reason not to. Might also more or less merge some of those towns together (darcap, cateham, and mountain village), as invidivdually there isn't a lot to each of them. ender pirateisland (and wolfsburg): I don't see any reason these can't be put somewhere on the world maps (off the coast of course). There are obviously some issues if you could sail to some of the small islands (might be able to bypass some quest aspects) - I'm not positive how big a deal that would be. In any case, that can be prevented with appropriate use of keys or inventory checkers or whatever. langley (port joseph): This is a fairly small and compact set of maps. However, for the most part it is fairly low level, so shouldn't be too far from scorn (currently, a ship ride away). I'm sort of inclined to keep it as is and put it on the world maps. Could be interesting to merge this in with the pirateisland and wolfsburge maps, as those maps are also gotten to by ship - my only concern is that wolfsburg is a bit higher than just a beginning map. thomas/sisters: The vally would seem to be something perfectly fine that can be buried in the middle of some large mountain range on the main continent, which is what I'll do. As a side note, soem additional outdoor graphics could be nice. Doing something like a frozen north with tundra, iced over rivers, glaciers, etc would be pretty cool if anyone wants to draw them. From leaf at real-time.com Wed Jun 5 01:44:10 2002 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:02:28 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <001301c20c39$475335e0$0a02a8c0@kameria> Message-ID: On Tue, 4 Jun 2002, Todd Mitchell wrote: > It is just weird having a bow and a shield equiped is all. Weird but convenient, which is why this feature in place now. ;) If anyone is interested in the past discussion, see the list archives at: http://archives2.real-time.com/pipermail/crossfire-devel/2000-December/000697.html Careful of line wrap.. From mwedel at sonic.net Wed Jun 5 01:56:33 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Change in equip method. References: <001301c20c39$475335e0$0a02a8c0@kameria> Message-ID: <3CFDB621.1050309@sonic.net> Todd Mitchell wrote: > Mark Wendel said: > > I agree that bows are underused but I don't think that making them two > handed would be too bad. There is a bigger problem with missile combat in > general (see below). > Also there could be bows that incorporate defensive or resistance bonuses to > compensate for this. Same as making two handed swords more powerful > for the same reason. It is just weird having a bow and a shield equiped is > all. I agree. but I'm sort of willing to let it slide as a convenience factor. But yeah, it then gets the problem that if the bow has benefits, the character gets them if they can hold onto it all the time. It would certainly be easy enough to make bows 2 weapons (weapon hand + shield hand). But I have a feeling in this case, no one would really use the item. However, this can be tweaked - you could make bows use the weapon hand and change it to some other location. > > I would have thought the problem with multiple weapons would be > multiple attacks (and all associated with that - seperate chance to hit, > seperate damage) not so much balance since most really powerful swords could > be > designated two handed, or creatures would also have the advantage of > multiple weapons The basic problem is that weapons are an item that the player can more or less make the weapon give whatever cool stat bonuses they want - they can basically make them better than what monsters will have. So a player that has a pair of really good improved weapons is nastier than really anything else out there. Now there are limits on how powerful weapon the character can used based on their level. (basically, number of improvements to weapon can not be greater than some total). You could change this so that the two weapons improvements are added up and can't exceed that total. But this brings up an even better idea IMO: EGO - give each item an ego value. Normal stuff (like plate mail, shields, swords) would have 0 ego value. A players equipments ego total could not exceed that total which is based on his level. this has many interesting play balancing effects. If you say each improvment (weapon or armor) counts as an ego point, players may now have to decide if it is better to improve that weapon or that armor. Various artifacts could have ego values also (dragon armor 2 or something). Great rings similar ego values. IMO, this has all sorts of good effects. It abstracts to too powerful weapon to now be all items. It gives an additional way to balance powerful artifacts (yes, this armor may be the best armor by far, but also has the highest ego. Maybe that other armor which isn't quite so good but has a lower ego is better so that I can use my extra powerful boots, etc). IT also means that high level players gifts of all sorts of artifacts to low level players isn't quite as useful. The lower level players may be able to use 1 or 2 of the items at a time, but not all of them. > Yes, I think it would be better to make a distinction between > locomotion method (noped, monoped, biped, quadraped, septaped...or maybe > none, feet2, > hoves2, claws2, hoves4, paws4, hoves6, paws6 or something) rather than count > the > number of feet, then create items for those other kinds of locomotion > (horseshoes of levitation, spider shoes +2, dragon spats of havoc) The way I envision the code is should be very very easy to add new body locations. So to start out with, we only need to worry about what we have now, and if horses are added, easy to add that they have hooves and whatnot. Now in terms of how to deal with this, doesn't make a huge difference. For example, if you say humans have 2 feet, but all boots require 2 feet, that is basically the same has saying has 1 pair of feet, and boots require 1 pair. Similar for horseshoes - you could say horses have 4 hooves, but if all horseshoes come in groups of 4, same effect, you only wear one at a time. I personally sort of like the idea of saying the number of feet or fingers or whatever in real terms. This allows for flexibility in the future - easy enough to just have all rings use 5 fingers and all boots use 2 feet. But you could add some cool future things - some quest where you get one boot someplace and another boot someplace else so that you can then were this mismatched pair together or something. Its certainly easier to set it up that way now than say you have 1 pair of feet or 2 hands and then decide later that, well, setting things to have 5 fingers would really have made more sense, that that may then mean updating quests, save files, whatever else. > As for rings, it would be simpler to say one per 'hand' instead of > worrying about counting fingers. This does not confuse with arm (as in > weapn_arm, shield_arm, and can be applied liberally to mean any 'active' > appendage or > (fireborn have 4 'hands' or something.) By active appendage it implies that > rings would not work if worn on toes or other protruding apendages... Note that the counting is left to the code, not the player, so that aspect is really transparent - player just notices that they can put on 2 rings and thats it. > > That is the current problem, which makes ranged weapons less useful. > Melee weapons should and will remain more powerful, but by building in a > pass flag > for some objects allowing flying but still blocking creature movement you > can create scenarios where the monsters do not/cannot close on the player(s) > but remain at a distance, or can attack with arrows oe spells while they > file through a narrow opening (coming across a bridge or down a stair) to > provide some pacing to the fight. You can have the bridge of death scenario > where narrow walkways work to the players disadvantage rather than their > advantage. You would have to modify the monster code to check if there > is a path for flying so the monster that are able to can still attack or > this > wouldn't work. As you say this is the biggest part of the job. I have not > gotten far enough in my learnin to really understand the code (but I have > been looking). > It ceratinly wouldn't replace melee weapons as the power items, > but it would make missile weapons much more useful (also flying, and > jumping). I agree - most of the movement stuff will have to get redone at some point. I'd like to even allow things like a swimming skill that lets you swim in shallow water, ships that can navigate deeper water, horses that give faster movement but can't necessarily pass over everything ,etc. But that isn't going to happen immediately. From dnh at hawthorn.csse.monash.edu.au Wed Jun 5 03:45:50 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <3CFDB621.1050309@sonic.net> References: <001301c20c39$475335e0$0a02a8c0@kameria> <3CFDB621.1050309@sonic.net> Message-ID: <20020605084550.GA12476@hawthorn.csse.monash.edu.au> > I agree. but I'm sort of willing to let it slide as a convenience factor. > But yeah, it then gets the problem that if the bow has benefits, the > character gets them if they can hold onto it all the time. > > It would certainly be easy enough to make bows 2 weapons (weapon hand + > shield hand). But I have a feeling in this case, no one would really use > the item. However, this can be tweaked - you could make bows use the weapon > hand and change it to some other location. I actually agree with Todd here, currently IMHO bows are down right useless, excepting a few very special cases (fireborn). If we could fix the problem at the root prevent people equiping weapons when using bows, we could start REALLY beefing up bows like they should be. Having unequiped, equiped and readied flags means you could switch between a weapon and a bow, while not actually gaining the special abilities of either the shields/melee weapons or the bow at the same time. The real problem right now is we can't just give bows +30 resist fire etc, because it is just another bonus... and fighters will use it with out any drawbacks. I have no problems with changing alot of the artifact bows + adding a few at the cost of changing stuff. > EGO - give each item an ego value. Normal stuff (like plate mail, > shields, swords) would have 0 ego value. A players equipments ego total > could not exceed that total which is based on his level. Woah this is actually a VERY neat idea. Basically adding a maximum total of cool items at the one stage. This idea was sort of explored with the current weapon enchancement codes level stuff. Basically unless you have enough points, you can't wield your weapon. If this were instituted firstly to the main nasty items, then in time to the lesser items it would another IMHO cool feature that would fix alot of these problems, even the florentine problem =). I also agree with the point that Mark makes about the symantics of the 'flags'. I think actually describing the body adds alot more usefulness in the long term. dnh From andi.vogl at gmx.net Wed Jun 5 04:30:12 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Java Editor bug. In-Reply-To: <3CFD8E0C.8090207@sonic.net> Message-ID: <000901c20c73$9b3ace90$c86ebb81@gizmo> > Minor bug in the java editor - if a multipart object spans > tiled maps, the editor is unable to load the map - > it throws an exception. The reason for this is that I explicitly designed the editor not to allow multis overlapping byond the map border. For non-tiled maps, such overlapping should not be allowed. I didn't know even that it is okay for tiled maps. The correct approach would be to allow multi-overlapping byond map border only on tiled maps and only adacent to another map-tile. I wonder what would happen when in such a case the adjacent map-tile would be missing or removed. However, I think it is more the job of the server to protect itself against such an incident. Andreas From pstolarc at theperlguru.com Wed Jun 5 05:22:06 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <3CFDB621.1050309@sonic.net> References: <001301c20c39$475335e0$0a02a8c0@kameria> <3CFDB621.1050309@sonic.net> Message-ID: On Tue, 04 Jun 2002 23:56:33 -0700, Mark Wedel wrote: > > The basic problem is that weapons are an item that the player can more or less >make the weapon give whatever cool stat bonuses they want - they can basically >make them better than what monsters will have. So a player that has a pair of >really good improved weapons is nastier than really anything else out there. > > Now there are limits on how powerful weapon the character can used based on >their level. (basically, number of improvements to weapon can not be greater >than some total). You could change this so that the two weapons improvements >are added up and can't exceed that total. But this brings up an even better >idea IMO: > > EGO - give each item an ego value. Normal stuff (like plate mail, shields, >swords) would have 0 ego value. A players equipments ego total could not exceed >that total which is based on his level. > > this has many interesting play balancing effects. If you say each improvment >(weapon or armor) counts as an ego point, players may now have to decide if it >is better to improve that weapon or that armor. Various artifacts could have >ego values also (dragon armor 2 or something). Great rings similar ego values. > > IMO, this has all sorts of good effects. It abstracts to too powerful weapon >to now be all items. It gives an additional way to balance powerful artifacts >(yes, this armor may be the best armor by far, but also has the highest ego. >Maybe that other armor which isn't quite so good but has a lower ego is better >so that I can use my extra powerful boots, etc). IT also means that high level >players gifts of all sorts of artifacts to low level players isn't quite as >useful. The lower level players may be able to use 1 or 2 of the items at a >time, but not all of them. Nice idea here. I would change it so that instead of being unable to wield/wear/whatever the ego item, it would follow the AD&D rules, which I'm assuming you got it from. The weapon tries to control you, which would translate in game terms as a confusion attack/reduced confusion resist and paralyze attack/reduced paralyzed resist if their is a large ego difference. Also fear/turn undead if that code works on players, though I've never seen it actually do anything. The lowered resists are constant, but make the attacks occur at the most inconvenient possible time. "You're low on HP, your bless just ran out, and now your sword turns on you." Basically if a level 1 character tries to wield a chaos sword, they will be able to hold it, but will have no control over their character, and will probably die quite quickly. Also, make personality levels factor into this somehow. "You convince the chaos sword to do your bidding. For now..." Maybe with some playbalance testing, we could add resists to player enchanted swords? -Philip From pstolarc at theperlguru.com Wed Jun 5 05:27:51 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] maps-bigworld input sought. In-Reply-To: <3CFD9DA1.6080904@sonic.net> References: <3CFD9DA1.6080904@sonic.net> Message-ID: <1pprfuoeomr72di9v87rhef1nki6d1nis1@flonk> As a side note, players can cross some bodies of water with dimensional door. This can be seen on the pupland world map. -Philip From dnh at hawthorn.csse.monash.edu.au Wed Jun 5 08:24:34 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] New images Message-ID: <20020605132434.GB20389@hawthorn.csse.monash.edu.au> This is in response to Todd Mitchells email about his new images, sadly his account seems to be bouncing.... > You can pick them up at http://abraxis.sytes.net/CF I had alook through these, you are drawing in the style of the base set.. Do you know there is another set? If you are using hte latest cvs gtk client, goto the configure section make it abit larger and change base to clsc. The biggest difference is the perspective change, the clsc set uses straight on monsters, here as the base set uses semi iso images. The reflects the classic drawing style used in crossfire before pngs were used (xpms and xbms shudder). I don't know if this is the kind of grfx style you want to use, but this is the more cartoony of the two for sure. Also I should note that there are a LARGE number of images as i'm sure you've noticed, starting a new set is ALOT of work.. I think at last count there were 4000 or so images. well.. happy drawing =) dnh ----- End forwarded message ----- From temitchell at sympatico.ca Wed Jun 5 13:35:57 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] New images References: <20020605132434.GB20389@hawthorn.csse.monash.edu.au> Message-ID: <000601c20cbf$d656e120$0802a8c0@ott.ca.dmr> My DSL runs fine for months at a time but of course drops just when someone actually wants to look at my site. I do check it every day though. I did do some stuff in the style of the base set, but was interested in the straight on cartoony set which I gather is the clsc set. I thought that the clsc set was the clasic set and should not be modified, which is why I wanted to take all the nice toony types (outlined, no perspective, bolder simpler colours) and copy them out into a new set then add more of the same style. If the clsc set is not closed, but was intended to be more this 'toony' style then I wouldn't bother making a new set. I will probably poke away at both types of style since I rely heavy on clipart, inspiration and accident when doing graphics. I am trying to strongarm a fellow into doing more toonish stuff though which is why I brought this up. Just to get this absolutly right however, if you are using an image set (picked from the client) and there is no graphics for that object in the set you are in it will use the base picture/anim riight? ----- Original Message ----- From: David Hurst To: Sent: Wednesday, June 05, 2002 9:24 AM Subject: [CF-Devel] New images > This is in response to Todd Mitchells email about his new images, sadly > his account seems to be bouncing.... > > > You can pick them up at http://abraxis.sytes.net/CF > > I had alook through these, you are drawing in the style of the base > set.. > > Do you know there is another set? > If you are using hte latest cvs gtk client, goto the configure section > make it abit larger and change base to clsc. The biggest difference is > the perspective change, the clsc set uses straight on monsters, here as > the base set uses semi iso images. The reflects the classic drawing > style used in crossfire before pngs were used (xpms and xbms shudder). > > I don't know if this is the kind of grfx style you want to use, but this > is the more cartoony of the two for sure. Also I should note that there > are a LARGE number of images as i'm sure you've noticed, starting a new > set is ALOT of work.. I think at last count there were 4000 or so > images. > > well.. happy drawing =) > > dnh > > ----- End forwarded message ----- > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From yann.chachkoff at mailandnews.com Wed Jun 5 14:45:55 2002 From: yann.chachkoff at mailandnews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Change in equip method. Message-ID: <3CFE8544@mailandnews.com> Some thoughts about all those ideas... The bow problem: ---------------- Bows are indeed not very useful, mostly because other, better ranged attacks are easily available to anyone (ranged spells). Bows should never be used in conjunction with another weapon (in game terms, both being applied at the same time). Seems rather difficult to hold a sword and use it efficiently when wielding a bow in your other hand... Either you have your bow, ready to band it for fire (then you can consider it 'applied', and thus also preventing the use of another weapon), or you have it in your bag/sac/back and you've something else in your hands (a shield and a sword for example - the bow is then 'unapplied'). You get only the bonus/malus of what you're currently using (in game terms, what is currently 'applied'). Note that simulating this with the 'body slot' system shouldn't be too difficult; you then just need to make bows two-handed weapons. I'm also not sure changing the way bows are handled could create big changes in their usefullness. I don't use bows simply because they're too weak compared to other means of doing ranged damage. Maybe the average attack strength of bows should be aligned with effectiveness of other common ranged attacks of comparable level (thrown items and common ranged spells)? The Ego idea: ------------- Interesting idea - as long as it isn't only another artificial rule. IMO, simply adding ego scores until reaching the maximum allowed and then telling the player: "It is too powerful for you to use" simply sounds too limited and artificial. I'd rather prefer allowing the player go higher than his/her maximum ego, but with increasing risks (like loosing control of a weapon). I also suggest the creation of 'personality templates' for ego-items, describing general item behaviour and possible backfire effects (I suppose that a Sword of Valriel hasn't the same ego as a Dagger of Devourers for example). Also note that some actions could temporarily make the ego of an item higher or lower than normal - for example, if you give elven blood to a Sword of Gnarg, it may appreciate it and thus be a little easier to control. Note that this is a system comparable to the one currently used with Grace Points. Now I admit this would be a little (hum) more coding than just adding an ego score. But it could also be somewhat more interesting on the long run. ------------------------------------------------ Visit http://www.selentine.dyndns.org for a journey into a fantastic world ! (But don't expect too much...) ------------------------------------------------ From dnh at hawthorn.csse.monash.edu.au Wed Jun 5 20:23:58 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] New images In-Reply-To: <000601c20cbf$d656e120$0802a8c0@ott.ca.dmr> References: <20020605132434.GB20389@hawthorn.csse.monash.edu.au> <000601c20cbf$d656e120$0802a8c0@ott.ca.dmr> Message-ID: <20020606012358.GA17953@hawthorn.csse.monash.edu.au> > My DSL runs fine for months at a time but of course drops just when someone > actually wants to look at my site. I do check it every day though. > I did do some stuff in the style of the base set, but was interested in the > straight on cartoony set which I gather is the clsc set. It is just the same perspective styles as the old one, as it happened those who were getting images and creating images were producing flat cartoony images. As the set matured, cartoony sets formed the majority of images =). I thought that the > clsc set was the clasic set and should not be modified, Hmmm, this is an unforseen problem =). No any set is modifiable, the clsc was simply refering to its style.. perhaps a better name 'could' be come up with, but after we spent a few days thinking about it we choose this, and since it is all coded..... =). which is why I > wanted to take all the nice toony types (outlined, no perspective, bolder > simpler colours) and copy them out into a new set then add more of the same > style. If the clsc set is not closed, but was intended to be more this > 'toony' style then I wouldn't bother making a new set. I will probably poke > away at both types of style since I rely heavy on clipart, inspiration and > accident when doing graphics. This is what most people do, there are very few artists out there who are willing to work on games (for free), who can just draw something =). I am trying to strongarm a fellow into doing > more toonish stuff though which is why I brought this up. > Just to get this absolutly right however, if you are using an image set > (picked from the client) and there is no graphics for that object in the set > you are in it will use the base picture/anim riight? Even if there are currently graphics for it, show them to me and I will add them if we agree it is better, otherwise we will usually just make another monster or find a better use for it. I can prtty much guarentee your artwork isn't going to go to waste. dnh From temitchell at sympatico.ca Wed Jun 5 20:57:42 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Change in equip method. References: <3CFE8544@mailandnews.com> Message-ID: <000601c20cfd$8ba37600$0a02a8c0@kameria> ----- Original Message ----- From: "Yann Chachkoff" > Some thoughts about all those ideas... > > The bow problem: > ---------------- > Bows are indeed not very useful, mostly because other, better ranged attacks > are easily available to anyone (ranged spells). > Bows should never be used in conjunction with another weapon (in game terms, > both being applied at the same time). Seems rather difficult to hold a sword > and use it efficiently when wielding a bow in your other hand... > Either you have your bow, ready to band it for fire (then you can consider it > 'applied', and thus also preventing the use of another weapon), or you have it > in your bag/sac/back and you've something else in your hands (a shield and a > sword for example - the bow is then 'unapplied'). You get only the bonus/malus > of what you're currently using (in game terms, what is currently 'applied'). > Note that simulating this with the 'body slot' system shouldn't be too > difficult; you then just need to make bows two-handed weapons. > > I'm also not sure changing the way bows are handled could create big changes > in their usefullness. I don't use bows simply because they're too weak > compared to other means of doing ranged damage. Maybe the average attack > strength of bows should be aligned with effectiveness of other common ranged > attacks of comparable level (thrown items and common ranged spells)? > I don't know if making bows more powerful is the best way to encourage their use, maybe magic is too powerful or it is too easy for players to get powerful magic. If you keep upping the ante things tend to inflate, although maybe some tweeking is necessary. Ranged combat should be less powerful than melee since the risk is lower and you should have more time to attack where with melee you need to hit hard and be able to take damage. Maybe making ranged weapon skills like bows and throwing agility skills rather than physical skills would help since they wouldn't dip from the same pot so to speak. This would also have the effect of greatly increasing the other agility skills for ranged weapon users (which may then need some adjustment). Magic should be like a cross between the two, a mix of powerful attacks and ranged attacks to give magic users an equal footing. If every one can get really powerful in melee and magic, there is not much use for ranged combat. Perhaps amulets should have caps on magic levels or a lower ratio of SP than the players with the magic skill to make it harder for non magicians to get powerful spells while still allowing lots of character customization. Maybe there should be more distinction between the classes for magic, ranged weapons and melee skills which would encourage different styles of play. From temitchell at sympatico.ca Thu Jun 6 00:34:16 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] maps-bigworld input sought. References: <3CFD9DA1.6080904@sonic.net> Message-ID: <001f01c20d1b$cc88f140$0a02a8c0@kameria> ----- Original Message ----- From: "Mark Wedel" ... > As a side note, soem additional outdoor graphics could be nice. Doing > something like a frozen north with tundra, iced over rivers, glaciers, etc would > be pretty cool if anyone wants to draw them. > Good idea, I was thinking about this which is why I was working on wolves and dire wolves. I did some winter terrain, ou can get it at http://abraxis.sytes.net/CF/winter/ -tm From mwedel at sonic.net Thu Jun 6 02:01:46 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Change in equip method. References: <001301c20c39$475335e0$0a02a8c0@kameria> <3CFDB621.1050309@sonic.net> Message-ID: <3CFF08DA.7090500@sonic.net> pstolarc@theperlguru.com wrote: > Nice idea here. I would change it so that instead of being unable to > wield/wear/whatever the ego item, it would follow the AD&D rules, > which I'm assuming you got it from. The weapon tries to control you, > which would translate in game terms as a confusion attack/reduced > confusion resist and paralyze attack/reduced paralyzed resist if their > is a large ego difference. Also fear/turn undead if that code works > on players, though I've never seen it actually do anything. The > lowered resists are constant, but make the attacks occur at the most > inconvenient possible time. "You're low on HP, your bless just ran > out, and now your sword turns on you." I beleive that Peterm had originally envisaged the spellcrystal doing various special things. As a first pass, I would just make it so you can't use it. Perhaps later it can be extended to have various strange effects. I have a feeling for the most part they would just be very unpopular (being too nasty, eg, your sword takes you over in combat and you die), or the opposite side, in wich they don't have enough bad effect, so that side effects they cause just end up being nuisances (oops - became confused wandering to the next town. Time to cast that cure confusion). But this could always become an option at some point. > > Basically if a level 1 character tries to wield a chaos sword, they > will be able to hold it, but will have no control over their > character, and will probably die quite quickly. Its a bit harder todo this in a computer based game than in real life, in which that first nasty combat (and the DM knows it is nasty), the sword does something bad. Its fairly difficult for a program like crossfire to really know how nasty that encounter will be (many factors - a combat could be easy or impossible for the same character, depending if he as the appropriate potions in effect for example). My personal thought is that ego should be public information anyways (if the item is identified, you know what its ego is). So it should be easy for players to figure out the totals and decide what to do. OTOH, the amount of ego that the equipped items exceed the characters ego could have some variance in occurence and how often the effects something. Thus, if a character had a nice set of items that worked together and just totalled their ego and died, they could still use that stuff, and being only a couple levels short, things wouldn't be too painful. But in any case, all this ego could would still need to be written. > > Also, make personality levels factor into this somehow. "You convince > the chaos sword to do your bidding. For now..." Yeah - I think physical level is used right now? That doesn't make a lot of sense if all items and not just weapons are included (even for weapons, you could say it doesn't make a lot of sense, but I think that was done so that the pure fighters could use their good weapons. with something like the scripting code, you could even have the potential for some items having higher ego values based on the characters class/race/whatever. > Maybe with some playbalance testing, we could add resists to player > enchanted swords? That doesn't change too much of it - right now there are maximums on what you can enchant based on your level - if resistances added part of those, that wouldn't be much of an issue (eg, do you want that stat bonus or resistance value). Probably the hardest part of this is figuring out what resistance value is good enough (eg, does 10% resistance equate to something like a stat increase?) From mwedel at sonic.net Thu Jun 6 02:09:33 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Change in equip method. References: <3CFE8544@mailandnews.com> <000601c20cfd$8ba37600$0a02a8c0@kameria> Message-ID: <3CFF0AAD.4080809@sonic.net> Todd Mitchell wrote: > I don't know if making bows more powerful is the best way to encourage their > use, maybe magic is too powerful or it is too easy for players to get > powerful magic. If you keep upping the ante things tend to inflate, > although maybe some tweeking is necessary. Ranged combat should be less > powerful than melee since the risk is lower and you should have more time to > attack where with melee you need to hit hard and be able to take damage. > Maybe making ranged weapon skills like bows and throwing agility skills > rather than physical skills would help since they wouldn't dip from the same > pot so to speak. This would also have the effect of greatly increasing the > other agility skills for ranged weapon users (which may then need some > adjustment). Magic should be like a cross between the two, a mix of > powerful attacks and ranged attacks to give magic users an equal footing. > If every one can get really powerful in melee and magic, there is not much > use for ranged combat. Perhaps amulets should have caps on magic levels or > a lower ratio of SP than the players with the magic skill to make it harder > for non magicians to get powerful spells while still allowing lots of > character customization. Maybe there should be more distinction between the > classes for magic, ranged weapons and melee skills which would encourage > different styles of play. It seems that people generally like the idea of bows using the weapon and armor hands, so I guess we'll do that. This does allow bows to be made powerful - you could now give that bow some attacktype or stat bonus or whatever else without it messing with the player too much. Note that there are other potential areas for merging. Arguably, the talisman should use the same slot as the amulet (sure looks similiar). This would certainly inspire people to actually learn the skill and not just use the amulet (same for holy symbols). Some of these adjustments can be pretty easily done at a later time. It seems the fundamental of the ideas are there and no one ha any big problems with them. From mwedel at sonic.net Thu Jun 6 02:28:02 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Java Editor bug. References: <000901c20c73$9b3ace90$c86ebb81@gizmo> Message-ID: <3CFF0F02.6070909@sonic.net> Andreas Vogl wrote: >>Minor bug in the java editor - if a multipart object spans >>tiled maps, the editor is unable to load the map - >>it throws an exception. >> > > The reason for this is that I explicitly designed the editor > not to allow multis overlapping byond the map border. > For non-tiled maps, such overlapping should not be allowed. > I didn't know even that it is okay for tiled maps. Yeah - it is correct that for non tiled maps, you should have portions of the object outside the map boundary. When the map is loaded/saved, only the head portion is saved. When the server loads the map, it will see that a portion of the object is on an adjacent map, load up that map, and link the objects in. this aspect isn't really well tested. there are some odd issues when you go to save the maps now. As I think about it, it may be better not to allow such behaviour. As it is, the server can't really handle a case in which the player is on a map in which the non head portion resides, but the the map where the head is located is not visible yet. OTOH, I sort of dislike the idea not allowing such objects near the seems of the maps, > > The correct approach would be to allow multi-overlapping > byond map border only on tiled maps and only adacent to > another map-tile. yep > > I wonder what would happen when in such a case the adjacent > map-tile would be missing or removed. However, I think it > is more the job of the server to protect itself against such > an incident. Yep. I think in that case, the normal out_of_map code will kick in, resulting in the object not being inserted. Or that is what should happen. From mwedel at sonic.net Thu Jun 6 02:34:13 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] New images References: <20020605132434.GB20389@hawthorn.csse.monash.edu.au> <000601c20cbf$d656e120$0802a8c0@ott.ca.dmr> Message-ID: <3CFF1075.8060701@sonic.net> Todd Mitchell wrote: > Just to get this absolutly right however, if you are using an image set > (picked from the client) and there is no graphics for that object in the set > you are in it will use the base picture/anim riight? Correct. It can actually be more complicated than that. When you create a set (by basically adding something to the lib/image_info directory), you can say what set it falls back to. As long as the chain leads back to the main set, this all works OK. From leaf at real-time.com Thu Jun 6 19:11:33 2002 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:02:29 2005 Subject: [CF-Devel] Re: [CF-maps] maps-bigworld input sought. In-Reply-To: <3CFD9DA1.6080904@sonic.net> Message-ID: A rough sketch on the city locations is available at sourceforge, careful though, the image is over 800Kb http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/crossfire/maps-bigworld/Info/ann_map.gif?rev=1.1&content-type=text/vnd.viewcvs-markup On Tue, 4 Jun 2002, Mark Wedel wrote: > Lake_County: The map itself (kundi_area) certainly has a look that it should be > part of something larger (eg, rivers and roads that run off the edges). So my > personal thought is that this should be be located someplace on the real map - > it would fit in better. Maybe someplace south of brest? anyone see a reason > that shouldn't happen? What level range are these maps? How about a little more south east of brest? There appears to be plenty of lakes there to make the map set live up to it's name. ;) A large majority of the maps in Lake Country are for characters level 30+. For instance, Chaos Lair, Wizard Tower, Burial Ground, Tower of Luck, etc. As far as I know, Lord Butakis Elite Training Tower (a pretty good tutorial map, BTW) is the only map that is for characters under level 10. > destiny maps: like lake_count above, the map itself (kandora) has a feeling of > being something large. IT would need some work (the new world maps won't use > the city icons anymore), but this could also be located someplace on the world > map it would seem. What level range are these maps? Heh, I don't how to get to these maps > dragonisland: I think that this should be located to some actual island on the > content someplace - this should be pretty easy to do. This would be nice in > that if down the road we allow boats that sail the oceans, this is someplace > real on the world. Sounds good to me. > dtabb: This was orignally the start of a new continent which really never went > anyplace. I think this should be located somewhere on the main continent, and > thats what I'll do unless there is reason not to. Might also more or less merge > some of those towns together (darcap, cateham, and mountain village), as > invidivdually there isn't a lot to each of them. Keep in mind there's a number of maps located in the wilderness of this continent, like High Valcano, Lord Lyn's Castle, Undead Ruins, and so on. Would these maps get distributed in the general area surrounding Darcap? I ask because there's a specific quest in Darcapp that relates to two of the Dtabb maps. > ender pirateisland (and wolfsburg): I don't see any reason these can't be put > somewhere on the world maps (off the coast of course). There are obviously some > issues if you could sail to some of the small islands (might be able to bypass > some quest aspects) - I'm not positive how big a deal that would be. In any > case, that can be prevented with appropriate use of keys or inventory checkers > or whatever. Sounds good to me. > langley (port joseph): This is a fairly small and compact set of maps. However, > for the most part it is fairly low level, so shouldn't be too far from scorn > (currently, a ship ride away). I'm sort of inclined to keep it as is and put it > on the world maps. Could be interesting to merge this in with the pirateisland > and wolfsburge maps, as those maps are also gotten to by ship - my only concern > is that wolfsburg is a bit higher than just a beginning map. I second your concern. A number of the Wolfsburg maps don't give much of a warning on how dangerous they are. Many times, very nasty monsters are just waiting on the top of a set of stairs or behind doors. (Examples: Castle Magara and High Tower) Not fun for new people. =( > thomas/sisters: The vally would seem to be something perfectly fine that can be > buried in the middle of some large mountain range on the main continent, which > is what I'll do. Currently it's rather hard to find the entrance to this map (and sometimes the exit..) I stumbled upon this area by accident myself, years ago. Does anyone have any ideas on how to make knowledge of this area more prevelant in the game without giving away too much? Or am I missing something here? - Rick Tanner From mwedel at sonic.net Fri Jun 7 01:36:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Re: [CF-maps] maps-bigworld input sought. References: Message-ID: <3D00547B.8000709@sonic.net> Rick Tanner wrote: > On Tue, 4 Jun 2002, Mark Wedel wrote: >>Lake_County: The map itself (kundi_area) certainly has a look that it should be >>part of something larger (eg, rivers and roads that run off the edges). So my >>personal thought is that this should be be located someplace on the real map - >>it would fit in better. Maybe someplace south of brest? anyone see a reason >>that shouldn't happen? What level range are these maps? >> > > How about a little more south east of brest? There appears to be plenty > of lakes there to make the map set live up to it's name. ;) > > A large majority of the maps in Lake Country are for characters level 30+. > For instance, Chaos Lair, Wizard Tower, Burial Ground, Tower of Luck, etc. > As far as I know, Lord Butakis Elite Training Tower (a pretty good > tutorial map, BTW) is the only map that is for characters under level 10. That would probably work being south east of Brest, since brest is a high level area, sort of keeps things in line. >>dtabb: This was orignally the start of a new continent which really never went >>anyplace. I think this should be located somewhere on the main continent, and >>thats what I'll do unless there is reason not to. Might also more or less merge >>some of those towns together (darcap, cateham, and mountain village), as >>invidivdually there isn't a lot to each of them. >> > > Keep in mind there's a number of maps located in the wilderness of this > continent, like High Valcano, Lord Lyn's Castle, Undead Ruins, and so on. > Would these maps get distributed in the general area surrounding Darcap? Probably. Note that on the main continent, there are a bunch of maps spread across it (the old one). My plan is to put those on the new maps, but try to keep somewhat relative positions so that all the npc's that say xyz is north/east/west/south of abc don't need to get updated. Some will probably need to get changed, simply because the distances may make some things not so kind (I immediately think of the mushroom random map/quest - putting it literally on the southern most point increases the difficult. My thought is make a mushroom patch somewhere south of scorn, maybe as far as brest, but probably not the southern extreme. > > I ask because there's a specific quest in Darcapp that relates to > two of the Dtabb maps. Note that IMO it is more important what the messages may say. Having quest maps that may be a bit far apart I think adds a little more depth to it than 'its 5 spaces from here'. >>langley (port joseph): This is a fairly small and compact set of maps. However, >>for the most part it is fairly low level, so shouldn't be too far from scorn >>(currently, a ship ride away). I'm sort of inclined to keep it as is and put it >>on the world maps. Could be interesting to merge this in with the pirateisland >>and wolfsburge maps, as those maps are also gotten to by ship - my only concern >>is that wolfsburg is a bit higher than just a beginning map. >> > > I second your concern. > > A number of the Wolfsburg maps don't give much of a warning on how > dangerous they are. Many times, very nasty monsters are just waiting on > the top of a set of stairs or behind doors. (Examples: Castle Magara and > High Tower) Not fun for new people. =( This should probably get fixed up - if nothing else, put in doors that can be seen through. The other thought is to take what is in port joseph and put it into scorn, but it seems like there is fair amount of stuff there. I just sort of like the idea of having a bunch of towns. OTOH, if it is put someplace relatively central, having small things like ports that don't have many shops makes some sense. Similarly, I could certainly see some taverns and perhaps general stores where some of the major roads join up - small villages that have some services - this is probably a good idea simply so people exploring in the wilderness don't have to go all the way back to town to get supplies. >>thomas/sisters: The vally would seem to be something perfectly fine that can be >>buried in the middle of some large mountain range on the main continent, which >>is what I'll do. >> > > Currently it's rather hard to find the entrance to this map (and sometimes > the exit..) I stumbled upon this area by accident myself, years ago. > > Does anyone have any ideas on how to make knowledge of this area more > prevelant in the game without giving away too much? Or am I missing > something here? well, the valley itself is of reasonable size. So if it is buried in a mountain range somplace, it means you only need to have a rough idea where it really is (you'll wander into it as long as your close - you don't need to find the exact spot like it is currently that dumps you onto the map. From mwedel at sonic.net Fri Jun 7 01:56:00 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] maps-bigworld input sought. References: <3CFD9DA1.6080904@sonic.net> <001f01c20d1b$cc88f140$0a02a8c0@kameria> Message-ID: <3D005900.7060901@sonic.net> Todd Mitchell wrote: > ----- Original Message ----- > Good idea, I was thinking about this which is why I was working on wolves > and dire wolves. I did some winter terrain, ou can get it at > http://abraxis.sytes.net/CF/winter/ Cool - I'll add those in. If you want to add some more, what I see that is missing is trees covered in snow/ice. Certainly not every tree combination needs to be done, but one or two varieties as such would be cool. It'd also be cool to actually have buidings so covered, but that is a lot of work, given the number of buildings. And things would look really odd in that case if you have some buildings so covered and others that are not. Now for some, you may be able to do generic overlays, but I'm not concerned about that - as long as the countryside can look good, that would be really cool. From pstolarc at theperlguru.com Fri Jun 7 17:44:13 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] monster dropped food bug Message-ID: There seems to be a bug in dropped food. "Dauntless Dragonman's steak" gets shortened to "steak", but keeps it's other properties. Seems to occur when it's dropped, maybe. It occurred about three times on mids' server. (Monsters were named dragonmen.) Occurred once when the food was originally dropped from the monster, and twice when the food was dropped in an old pile of similar food, and got nroffed together. -Philip From root at garbled.net Sat Jun 8 09:40:59 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <3CFC7225.8070907@sonic.net> Message-ID: On 04-Jun-02 Mark Wedel wrote: > You could certainly just say that you have 2 arms, and a shield uses one > arm > and a weapon uses an arm, and that you could use 2 weapons or two shields. > Using two shields probably isn't that much a problem, but 2 weapons certainly > are. I think that can be solved by cheating on our part. Only make the magic for the weapon in the right arm count, or average the two together. > object skill_florentine_fighting > msg > Florentine style lets you fight with too weapons. However, with this > training, you are know longer proficient in use of the shield. > endmsg > weapon_hand -1 > shield_hand 1 > end That seems borked to me. How is it that I can learn a skill, and by doing so completely forget how to use a shield? Also.. it seems to me that it would be a different skill set to learn to fight with two different weapons, vs a pair of identical weapons. The motions and strategies would be wholly different. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From root at garbled.net Sat Jun 8 09:49:25 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <20020605084550.GA12476@hawthorn.csse.monash.edu.au> Message-ID: On 05-Jun-02 David Hurst wrote: > If we could fix > the problem at the root prevent people equiping weapons when using bows, > we could start REALLY beefing up bows like they should be. I can see not having the bow and weapon on at the same time, and the idea of switching the bonuses in and out as you switch weapons is good, though I think having a bow and shield is justifiable. For example: 1) Many smaller crossbows were kept inside the shield arm to fire as a surprise attack. 2) Lets say you saw a horde of orcs ahead, and decided to pick them off. Many archers would drive the point of thier shield into the ground and fire from behind it, essentially giving them the armor bonus, at least to incoming fire. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From temitchell at sympatico.ca Sat Jun 8 13:26:58 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Change in equip method. References: Message-ID: <000e01c20f1a$136ef3c0$0a02a8c0@kameria> Tim Rightnour said: > I can see not having the bow and weapon on at the same time, and the idea of > switching the bonuses in and out as you switch weapons is good, though I think > having a bow and shield is justifiable. For example: > > 1) Many smaller crossbows were kept inside the shield arm to fire as a surprise > attack. Then you make a small crossbow that is one handed, limited range and damage. You don't hide a longbow or full crossbow behind a shield. A heavy crossbow you would have your hands full just loading it. > 2) Lets say you saw a horde of orcs ahead, and decided to pick them off. Many > archers would drive the point of thier shield into the ground and fire from > behind it, essentially giving them the armor bonus, at least to incoming fire. There may be examples in history where a shield was used this way, but then you would also say that anyone who had the foolishness to go into battles alone against 20 or 30 opponents like we do in the game wouldn't last 5 minutes. Thangor the archer would be Thangor the dead porcupine even with a shield. A magic shield might not work unless it was worn anyway... from Mark: >The change would basically modify equipable objects to specify whay body >location (or equip location) they go on. For example, helmets would have a line >added like 'equip_location head', armor would have 'equip_location torso', rings >'equip_location finger', etc. Objects could specify multiple locations - >'equip_location weapon_hand,shield_hand' could be used to allow 2 handed weapons. You can have it both ways, Changing the equip method like Mark suggests would allow you to have smaller missile weapons like you mention, but it also allows you to have larger two handed missile weapons. You would have to balance out the weapons of course. From temitchell at sympatico.ca Sat Jun 8 13:48:44 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Change in equip method. References: Message-ID: <001101c20f1d$1de96b20$0a02a8c0@kameria> Hoo hoo, lots of messages from the equip weapon thread...I guess this is a popular idea Mark. > On 04-Jun-02 Mark Wedel wrote: > > You could certainly just say that you have 2 arms, and a shield uses one > > arm > > and a weapon uses an arm, and that you could use 2 weapons or two shields. > > Using two shields probably isn't that much a problem, but 2 weapons certainly > > are. > Tim: > I think that can be solved by cheating on our part. Only make the magic for > the weapon in the right arm count, or average the two together. This would be a kettle of fish to open I think and I believe it has been hashed out before (before my time anyway). I don't think you want to fudge this into existance however, it would have to be well executed. Following the idea of extensibility of Mark's original proposal, you would want to be able to handle combat the same way for any number of weapons. I would suggest that player races shouldn't ever have more than two possible weapon slots however. I'm not pushing for x handed fighting, but if it were to be done I think that you would would want to calculate seperate attacks for each weapon and assign some penalties for the secondary weapon(s). You could put a loop in the attack routine, check for number of attacks and assign a penalty after the first. You would do seperate attacks instead of averaging the attack since the weapons could be have very different attack effects like elemental or slaying, and you could also have weapons that added to defense ability. Also all the really powerful weapons would have to be made two handed to avoid unbalancing the game too much - meaning you would loose your shield bonuses too when you used them, which would be good I believe. I would not really go in for allowing x handed fighting unless the monsters were able to do this as well (especially a six armed deamon with flaming swords). This would indirectly encourage ranged attacks too since some things you would not want to get close to anymore since they would really beat on you. > Also.. it seems to me that it would be a different skill set to learn to fight > with two different weapons, vs a pair of identical weapons. The motions and > strategies would be wholly different. I agree that it should be a seperate skill to use two weapons, but this should be the same case even when the two weapons are identical (even with identical weapons the stratagies would be different - but you couldn't make a skill for every combination). If you have multiweapon fighting, and monsters have multiple attacks, you might also want to give the heavy fighter classes the ability to attack twice with a two handed weapon as well which would be a skill as well. On a tangent note, some of these more powerful skills (two handed attacks, use magic, praying...) you might want to make impossible to get by buying them (with money anyway). Maybe set up nasty quests to get them or deny them altogether unless you are a certain class.) Anyway, back to the main topic, you certainly would want to change the equip method first since it would make all these other ideas more managable. From dnh at hawthorn.csse.monash.edu.au Sat Jun 8 17:39:25 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: References: <3CFC7225.8070907@sonic.net> Message-ID: <20020608223925.GA11953@hawthorn.csse.monash.edu.au> > > object skill_florentine_fighting > > msg > > Florentine style lets you fight with too weapons. However, with this > > training, you are know longer proficient in use of the shield. > > endmsg > > weapon_hand -1 > > shield_hand 1 > > end > > That seems borked to me. How is it that I can learn a skill, and by doing so > completely forget how to use a shield? Agreed. > Also.. it seems to me that it would be a different skill set to learn to fight > with two different weapons, vs a pair of identical weapons. The motions and > strategies would be wholly different. Speaking from experience, it is different, but not that different.. what I mean to say is that it is certainly a seperate skill, but it just involves extra practise (unless you are completely unco ;). dnh From pstolarc at theperlguru.com Sat Jun 8 18:12:32 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Item sorting Message-ID: <6335gu4dtnl7gjptgt7hjijnuh4hc00b9n@flonk> I've been working on trying to get the SDL client to use the common client files. It's rather a bit of work, as stuff has been renamed and moved around to different files. And I'm not going to mention the added functionality. Anyway,... Looking at common/item.c right now, and noticed something in update_item_sort(): #if 0 /* This could be a nice idea, but doesn't work very well if you * have a few unidentified wands, as the position of a wand * which you know the effect will move around as you equip others. */ /* applied items go first */ if (itmp->applied) continue; /* put locked items before others */ if (itmp->locked && !it->locked) continue; #endif If you sort by itmp->tag first, then everything will appear in a very consistent order. But if you equip the "unIDed wand that you know what it does", then unequip it, you may still lose track of it. But though it will move back to exactly the same place it was before you applied it. It would even sort stuff consistently if you drop stuff, then pick it back up, as the tag stays the same. Just an idea. Not sure if it's worthwhile or not. -Philip From dnh at hawthorn.csse.monash.edu.au Sat Jun 8 20:58:09 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <001101c20f1d$1de96b20$0a02a8c0@kameria> References: <001101c20f1d$1de96b20$0a02a8c0@kameria> Message-ID: <20020609015809.GB11953@hawthorn.csse.monash.edu.au> > > On 04-Jun-02 Mark Wedel wrote: > > > You could certainly just say that you have 2 arms, and a shield uses > one > > > arm > > > and a weapon uses an arm, and that you could use 2 weapons or two > shields. > > > Using two shields probably isn't that much a problem, but 2 weapons > certainly > > > are. > > > Tim: > > I think that can be solved by cheating on our part. Only make the magic > for > > the weapon in the right arm count, or average the two together. > > This would be a kettle of fish to open I think and I believe it has been > hashed out before (before my time anyway). I don't think you want to fudge > this into existance however, it would have to be well executed. Following > the idea of extensibility of Mark's original proposal, you would want to be > able to handle combat the same way for any number of weapons. I would > suggest that player races shouldn't ever have more than two possible weapon > slots however. I don't think this is something to prevent, rather just don't implement it completely. Alot of things we may not think are now useful or good, but a year down the line we may really need it, and it will be harder to implement then than now, I suppose on the same hand, it is far better to implement what you need as you need it in software design. My personal feelings are that we shouldn't specifically deny something unless we absolutely have to. > I'm not pushing for x handed fighting, but if it were to be done I think > that you would would want to calculate seperate attacks for each weapon and > assign some penalties for the secondary weapon(s). You could put a loop in > the attack routine, check for number of attacks and assign a penalty after > the first. You would do seperate attacks instead of averaging the attack > since the weapons could be have very different attack effects like elemental > or slaying, and you could also have weapons that added to defense ability. > Also all the really powerful weapons would have to be made two handed to > avoid unbalancing the game too much - meaning you would loose your shield > bonuses too when you used them, which would be good I believe. > I would not really go in for allowing x handed fighting unless the monsters > were able to do this as well (especially a six armed deamon with flaming > swords). This would indirectly encourage ranged attacks too since some > things you would not want to get close to anymore since they would really > beat on you. I know from fighting florentine, that which hand a sword goes in (size etc) can make a big difference to how you fight because most fighers are not ambidexterous, I would say though, that we can assume our beloved hero in the game is =). More over, any very poerful weapon can be limited by number of hands, magic interactions (ie like rings) or ego. > should be the same case even when the two weapons are identical (even with > identical weapons the stratagies would be different - but you couldn't make > a skill for every combination). Nor would you want to no. > If you have multiweapon fighting, and monsters have multiple attacks, you > might also want to give the heavy fighter classes the ability to attack > twice with a two handed weapon as well which would be a skill as well. > On a tangent note, some of these more powerful skills (two handed attacks, > use magic, praying...) you might want to make impossible to get by buying > them (with money anyway). Maybe set up nasty quests to get them or deny > them altogether unless you are a certain class.) Hmm as Peterm once so rightly explained to me, alot of the time it is the fun that is most important, but you should keep in mind things like learning. Unlike alot of RPG/MUDS, our heros can learn any skill and become proficient in it as long as he/she practises. I would like to make a clear reason as to why various combos can't be used, I think this ego idea does that very nicely. Of course, no one has said they actually want to code this ;) and in the end it comes down to that person as to how it is implemented =), I of course am just stating my opinion. dnh From mwedel at sonic.net Sun Jun 9 01:10:01 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Change in equip method. References: <000e01c20f1a$136ef3c0$0a02a8c0@kameria> Message-ID: <3D02F139.40608@sonic.net> I'm going to catch up several points all in one. IT should be noted that crossfire does not currently have fine grained weapon proficiences. Eg, learn melee weapons, and you know all melee weapons (club, axe, sword, spear, etC). Given that, if a two weapon skill is added, it probabably makes just as much sense that it covers all weapon combos. I agree with the point that if we want to let players use a crossbow with a shield, making one handed versions it probably more appropriate. There are certainly combinations which did work historically (eg, using only a buckler shield with a bow). However, I can't think of a very good way to handle that. You could do something like have buckler shields be 0 handed items, but you can't wear them with other shields. But I'd prefer not to have too much special code like that, because it then breaks other things (suppose you have that 4 armed creature. It should in theory be able to use a high shield, long sword, buckler shield, long bow. But if you say only 1 shield...) Now I suppose things can be coded in now to allow one behaviour, and then if we add things like 2 weapon fighting or 4 armed creatures, worry at that time about making it work properly. RE using multiple weapons at one time: I agree the correct way to do it would be for each weapon to have its own weapon speed, and each attach only has the benefits of that weapon. However, that would require some fairly extensive changes to the attack code. Perhaps if we want to seriously look into using 2 weapons, we should look at such a change. But it certainly makes things more complicated. Issue I hadn't brought up before: Items that compete for the same body location (like rings, but could also be things like 2 handed weapons + shields). The current code for rings basically unapplies one of them - which one is sort of random (probably related to order in the players inventory, which of course does not match the order that the client displays it in). My personal thought is to change this so that you are equipping something but there is a choice of more than 1 item to unequip, the server then informs the player that 'you either need to enequip a or b' type of things, instead of making that choice for the player. Thoughts? From temitchell at sympatico.ca Sun Jun 9 04:10:04 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Equip method, multiple weapons and two handed bows Message-ID: <000901c20f95$71a0c2e0$0a02a8c0@kameria> There is a lot of postings going into the 'change in equip' thread. A lot of different items are being brought into this one thread and it might be good to rehash and clarify. Since I am partly responsible for forking the discussion I though I should try to untangle it a bit. I also did some limited research on the topics being discussed, I went back to in the archives of this forum and found all these issues were discussed in December 2000. Some of the discussion was very similar to what has come up this month (David Hurst discussed coding multiple weapon check and attacks, Peter Mardahl dismissed the bow- shield issue as unimportant, Andreas Vogl spoke about how missile weapons sucked) Well imagine my embarassment coming in to a reprise conversation as a newbie. anyway here goes: 1. Mark Wendel brought up the idea of changing the way that items are equiped. >Currently, the type of object determines how man you can wear, and if you can >wear it at all. It is hard coded that you can wear 2 rings, 1 helmet, 1 suit of >armor, etc. some of the flag_can_use_armor refine this in a very primitive way. >The change would basically modify equipable objects to specify whay body >location (or equip location) they go on. For example, helmets would have a line >added like 'equip_location head', armor would have 'equip_location torso', rings >'equip_location finger', etc. Objects could specify multiple locations - >'equip_location weapon_hand,shield_hand' could be used to allow 2 handed weapons. Thats it. This did not bring up allowing multiple weapons or multiple weapon combat, although it would work nicely towards equiping multiple weapons. 2. Multiple weapons I believe David Hurst brought up the two weapon thing, which no longer a suprise to me after reading his messages from december 2000. I know that Mark mentioned the problem with using two weapons and Tim Rightnore replied that the bonuses could be fudged to make thing more balanced. I though I was thinking clearly and jumped in on how two weapon attacks should work but I thought that it should be designed to work with any number of weapons since this went along with the kind of open ended equip method that Mark was suggesting and since this is a fantasy game where 3, 6, and 12 armed monsters are possibly right around the next hallway. I just thought that if the code was to be updated for two, then it could be updated for x instead to make things easier in the future. (I also thought it would be cool to make some monsters with multiple attacks...) Making a skill for multiple weapon use is also a good idea to control it a bit, although if you can buy it for 1000pl, it isn't really going to slow anyone down. If you have monsters that can do multiple melee attacks you might want to have a skill for doing multiple attacks with a two handed weapon as well (namely two handed weapons like swords or battle axes), since otherwise these weapons will be at a disadvantage. God, it never ends...It's obvious there is a lot of balance issues for melee combat with multiple weapons. Just for the record, I don't necessarily advocate multiple weapon combat being introduced, at least not for players. I just thought to point out how it could be built off of Mark's proposal. I found it amusing after the fact that David had responded to my mail saying some one would have to write the code, although at the time I didn't see the irony in this comment. 3. Bows for two hands Mark: >Now the only really noticable aspect to this to players would be changing the >range locations. They current range location is really a leftover from long >ago. With this change, I would make it so there is only 1 range slot (which >horns, bows, wands, skill tools, etc, would all vie for). This simplifies the >code a great deal on the server, and probably makes more sense anyway. One problem with bows currenlty is that you can equip them as a sort of amulet to get bonuses. Also if you have two handed swords you cannot benefit from a shield, but when you use a bow you can benefit from a shield. Changing bows to two handed weapons seems to be something that others agreed with as well, but I hope that it comes about as a result of the changes that Mark proposed in the equip method and not just by itself, since that would be the best way to handle it I believe. There are three ways to do combat in the game, melee, ranged weapon and magic, but it is a lopsided triangle and ranged combat is the runt of the litter here (mainly the monsters run at you too fast and/or the areas are too confining). That's another discussion. I still think it would be a good idea to make bows and crossbows two handed weapons and to clean up the range locations as Mark suggests, although I do know that this will make bows even less attractive, from what I am hearing, they are not being used much anyway. It would be nice if there was still a ranged weapon 'slot' and a melee weapon 'slot' and selecting the ranged weapon disabled the bonuses of the melee weapon and vice versa, and if the ranged weapon was two handed , disabled the shield bonus, but I'm not gonna go there. So that's it. Three items that are related but not dependent. As David said, "Of course, no one has said they actually want to code this ;) and in the end it comes down to that person as to how it is implemented =)". I am just making suggestions. (I also went out and got an ansi C primer). From andi.vogl at gmx.net Sun Jun 9 08:25:44 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] multiple weapons In-Reply-To: <000901c20f95$71a0c2e0$0a02a8c0@kameria> Message-ID: <000001c20fb9$2beaf4e0$c86ebb81@gizmo> The changes in equip method mark prosposed is very nice and I see no problem with it. However, I have to say something about indtroducing multiple weapons for players: When I see people promote ideas like "3-5 weapon arms" I really wonder how that comes, assuming that everyone on this list has played Crossfire for a good while. In my opinion, allowing players to wield multiple weapons is exactly that kind of feature that causes a lot of work and trouble while gaining, well - nothing. Maybe it is possible to spend a lot of time with creating a complex method to merge bonuses, adjust all the maps, introduce an ego-system and all that... Now assumed you succeed to balance it perfectly (which I think is impossible), what is the big gain? - You then have two weapons equipped and still do exactly the same things you've done before. Tell me if I'm wrong, but I really see no increase in gameplay value. I believe the argument "we should do it for future extendability" is not justified either, because it causes a big lot of *extra* work that would otherwise not be required. (I do hope everyone agrees that it is not an option to code multiple weapons *without* resolving the balance-screwup.) So instead of "future extendability" we might get "a patch in the remote future". ;-) But certainly the person who wants to code it can decide. Andreas From dnh at hawthorn.csse.monash.edu.au Sun Jun 9 20:42:00 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] Change in equip method. In-Reply-To: <3D02F139.40608@sonic.net> References: <000e01c20f1a$136ef3c0$0a02a8c0@kameria> <3D02F139.40608@sonic.net> Message-ID: <20020610014200.GA9950@hawthorn.csse.monash.edu.au> > Now I suppose things can be coded in now to allow one behaviour, and then > if we add things like 2 weapon fighting or 4 armed creatures, worry at that > time about making it work properly. mmm > RE using multiple weapons at one time: I agree the correct way to do it > would be for each weapon to have its own weapon speed, and each attach only > has the benefits of that weapon. However, that would require some fairly > extensive changes to the attack code. Perhaps if we want to seriously look > into using 2 weapons, we should look at such a change. But it certainly > makes things more complicated. I would think it is worth serious contemplation. > My personal thought is to change this so that you are equipping something > but there is a choice of more than 1 item to unequip, the server then > informs the player that 'you either need to enequip a or b' type of things, > instead of making that choice for the player. Thoughts? ok, except that this will add time to equiping, I would rather see some sort of clever binding ability 'apply ,;apply . This would basically switch between a sword and shiled (or just sword/shield) to a bow and back. The apply code looks to apply the object, if it is already applied it unapplies and the reverse. Which items it applies would be based on the easiest way to do it, but a predictable one. Ie, highest in inv. (If this was used I would like to see the ability to rearrange your inv) or possibly the highest locked item. =), food for thought huh =) dnh From temitchell at sympatico.ca Mon Jun 10 00:18:32 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] maps-bigworld input sought. References: <3CFD9DA1.6080904@sonic.net> <001f01c20d1b$cc88f140$0a02a8c0@kameria> <3D005900.7060901@sonic.net> Message-ID: <000801c2103e$43743060$0a02a8c0@kameria> I did up three sizes of conifir forest. Same folder. ----- Original Message ----- From: "Mark Wedel" To: Sent: Friday, June 07, 2002 2:56 AM Subject: Re: [CF-Devel] maps-bigworld input sought. > Todd Mitchell wrote: > > > ----- Original Message ----- > > > Good idea, I was thinking about this which is why I was working on wolves > > and dire wolves. I did some winter terrain, ou can get it at > > http://abraxis.sytes.net/CF/winter/ > > > Cool - I'll add those in. > > If you want to add some more, what I see that is missing is trees covered in > snow/ice. Certainly not every tree combination needs to be done, but one or two > varieties as such would be cool. > > It'd also be cool to actually have buidings so covered, but that is a lot of > work, given the number of buildings. And things would look really odd in that > case if you have some buildings so covered and others that are not. Now for > some, you may be able to do generic overlays, but I'm not concerned about that - > as long as the countryside can look good, that would be really cool. > > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at sonic.net Mon Jun 10 00:21:54 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:30 2005 Subject: [CF-Devel] item_power (ego) changes. Message-ID: <3D043772.2010109@sonic.net> This idea was originally started by me in the change equip mode discussion. It is really unrelated, and could just as well be done with the current equip method. I thought I'd break it out of that thread to make it easier to follow it. In that thread, I had mentioned giving each item an ego value. I think saying it is item_power would be better. Ego suggests the item has some consciousness of its own - in really, many items will have some power rating by no consciousness. In short summary, this is an alteration of giving items a min_level. In a min_level system, the character needs to be some level before using that item. With the item_power idea, all the item_power for all items the player has equipped are summed up. They can not exceed some value - if equipping an item would exceed that value, the player is told somethign like 'that combination is too powerful with your other items'. Adding such an element to items gives additional ways to balance items. There are well known artifacts that are clearly the best. Giving them also the highest power rating balances them out - you can use them, but may not be able to use all your other best artifacts at the same time, so maybe you don't want to use it after all so you can use your other good artifacts. My personal thought is that the item_power that the player is allowed is determined largely by the characters overall level. Some stats may adjust this, and perhaps even some race or classes adjust this in some way. I say that using overall level is because if it is based on one of the skill categories, it then forces all characters to concentrate on that one category. In theory, you could have different item powers that correspond to the different exp categories (eg, this item is 2 physical and 2 agility power points). My thought is that just makes things really complicated for the player in terms of trying to find combinations of items to use (even if each item only goes against one category, it gets trick. Like for example, I equip this new helm, which counts against personel, and the old one counted 3 against physique, so now let me re-arrange my physique items, etc) For artifacts or special items made in maps, easy enough to set appropriate item_power values. For items generated automatically, I propose that the number of enchantments is used to determine the appropriate item tower. Perhaps using a table like: # enchantments power 0 0 1 0 2 1 3 2 4 3 5 5 6 8 7 11 Or whatever. As said, a table would be used to determine the enchantment -> power rating, so easily customizable. The table is not quite linear - this is intentional - items that put a lot of stuff into one item is obviously more useful than two seperate items combined have the same abilities, simply because the player has a limited number of slots to equip things (this adjustment is already done for price). Now what counts as an enchantment. My idea: Each plus an item has. Each point an item increases an ability. Each 20% protection an item gives (rounded normally, eg 0-9 counts as nothing, 10-29 counts as one, etc) Some abilities should perhaps cost more. eg, it may be considered that mana regen is more valuable than a stat gain, so each point of mana regen is 2 enchantments, etc. The random artifacts should probably be updated to include the number of enchantments they effectively have, so that when the program generates such an item, it can properly calculate the appropriate total # of enchantments. Now the number of enchantments allowed to the player is probably easier to determine after the values for the items are set up - the number shouldn't be too constrictive, but if a player has all the best artifacts and still doesn't approach it, something isn't right. At the same point, low level characters shouldn't run into it all that often if they are just using normal items - this is one reason that 1 enchantment items still don't count as anything, and 2 enchantment items only count as a point. Using the above table, a 10'th level chracter ths is fully equipped probably has a powr total of around 10 (3 for the sword, maybe 3 for armor, and several +2 items). From mwedel at sonic.net Mon Jun 10 00:33:07 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] monster dropped food bug References: Message-ID: <3D043A13.5010006@sonic.net> pstolarc@theperlguru.com wrote: > There seems to be a bug in dropped food. "Dauntless Dragonman's > steak" gets shortened to "steak", but keeps it's other properties. > Seems to occur when it's dropped, maybe. It occurred about three > times on mids' server. (Monsters were named dragonmen.) Occurred > once when the food was originally dropped from the monster, and twice > when the food was dropped in an old pile of similar food, and got > nroffed together. This should have been fixed in the latest CVS commit. From mwedel at sonic.net Mon Jun 10 01:07:06 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] Item sorting References: <6335gu4dtnl7gjptgt7hjijnuh4hc00b9n@flonk> Message-ID: <3D04420A.10900@sonic.net> pstolarc@theperlguru.com wrote: > I've been working on trying to get the SDL client to use the common > client files. It's rather a bit of work, as stuff has been renamed > and moved around to different files. And I'm not going to mention the > added functionality. Yes - it was a while since the SDL client was originally done. > > Anyway,... > > Looking at common/item.c right now, and noticed something in > update_item_sort(): > > #if 0 > /* This could be a nice idea, but doesn't work very well if > you > * have a few unidentified wands, as the position of a wand > * which you know the effect will move around as you equip > others. > */ > > /* applied items go first */ > if (itmp->applied) continue; > /* put locked items before others */ > if (itmp->locked && !it->locked) continue; > #endif > > If you sort by itmp->tag first, then everything will appear in a very > consistent order. But if you equip the "unIDed wand that you know > what it does", then unequip it, you may still lose track of it. But > though it will move back to exactly the same place it was before you > applied it. It would even sort stuff consistently if you drop stuff, > then pick it back up, as the tag stays the same. Good point. This point may be more worthwhile depending on the client interface - the gtk client already has convenient ways to show the equipped vs non equipped items. It would probably be best that any such 'equip items at start of group' be a configurable option. Even for items identified, it can be a little odd/annoying that when you equip/unequip item, it disappears from the immediate inventory view as it is put someplace else. The ideal solution which is a bit more work to do is to let the player rename their items (so if you fire that wand, and see a fireball explode, you rename it to be 'wand of fireball' I had sent some e-mail on that quite a while ago on doing something like that. My idea is that this would largely be handled by the client. Probably the easiest way would be to make the tags truly persisent (so for example, the client sees that player wants to rename item with tag 45678 to something, and makes a note of it. Player logs out, and then sometime later (maybe days), log back in. The item has the same tag, so the client knows it can use the custom name for it. My original idea had the idea that the client could send a 32 bit value that it wanted the server to store with that object, and that would persist. The client could use that 32 bit value as a pointer to the name, but could also use it for things like favorite lists and whatnot. However, this is obiously a more complex approach (client has to tell server to store tag with object, protocol needs to get updated, need to deal with cases if one player drops it and another picks it up, it may have a bogus id respective to that new players client, so when something is dropped, that id needs to get cleared, etc). Making the tags persistent would actually be quite easy to do. Fairly trivial to save them to disk and set to the same value when loaded. Also fairly easy to make a checkpoint file that stores the last tag used (so if the server exits/crashes, it looks at that as the starting point, increasing it a bit just to cover any items that may have been created since the last update). The advantage is that this doesn't require any extension to the protocol, and don't need to worry about a different player picking up some item (eg, player a drops what he calls 'my awesome sword'. Player 2 picks it up, and the client recognizes that tag and sees that it should display it as 'doofus' sword'. The only problem with this approach is that eventuall the tags would wrap (this eventually could end up being very large, like months or years, but since the tag count would persist across runs, we're not talking about the server continually being up that long - just running on the same system). I'll need to look at metalforge after its been running for a while and see what its tag count is to extrapolate how long it would take for it to wrap). > > Just an idea. Not sure if it's worthwhile or not. > > -Philip > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at sonic.net Mon Jun 10 01:21:13 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] Change in equip method. References: <000e01c20f1a$136ef3c0$0a02a8c0@kameria> <3D02F139.40608@sonic.net> <20020610014200.GA9950@hawthorn.csse.monash.edu.au> Message-ID: <3D044559.3060100@sonic.net> David Hurst wrote: >> RE using multiple weapons at one time: I agree the correct way to do it >> would be for each weapon to have its own weapon speed, and each attach only >>has the benefits of that weapon. However, that would require some fairly >>extensive changes to the attack code. Perhaps if we want to seriously look >>into using 2 weapons, we should look at such a change. But it certainly >>makes things more complicated. >> > > I would think it is worth serious contemplation. Put it on the TODO list :). I'd have to look at how the current attack code works - depending on its current state, it may not be quite so hard. Hmm. Maybe if I ever fix the weapon speed/real speed problem, I could fix it also. However, you also get what may be some odd situations, eg, I 4 armed creature that wants to use a sword as one attach and karate (or claws) as another. I just envision that trying to do this opens up a huge can of worms. I'll be happy to just allow 2 handed weapons. > > >> My personal thought is to change this so that you are equipping something >> but there is a choice of more than 1 item to unequip, the server then >>informs the player that 'you either need to enequip a or b' type of things, >>instead of making that choice for the player. Thoughts? >> > > ok, except that this will add time to equiping, I would rather see some > sort of clever binding ability 'apply ,;apply . This > would basically switch between a sword and shiled (or just sword/shield) > to a bow and back. The apply code looks to apply the object, if it is > already applied it unapplies and the reverse. Which items it applies > would be based on the easiest way to do it, but a predictable one. Ie, > highest in inv. (If this was used I would like to see the ability to > rearrange your inv) or possibly the highest locked item. Some people have commented that the fact that you can current switch which suit of plate armor in the middle of battle isnn't all that realistic, and it should take some time to switch. I'm not quite so sure on that - this probably boils down to the realism vs fun factor. This is one reason I play without the longer spell casting times - it isn't very fun to cast a spell add have to literally wait a couple seconds before you can do something again, same for switching items. Note that there are command line ways to equip and unequip items (apply -u and apply -a I think, might also be unapply). So you could certainly do something like 'unapply bow; apply shield; apply sword' and bind it to a key. Note that this now takes 3 actions to perform that switch, instead of it all happening in one (you could also have the reverse, 'unapply sword; unapply shield; apply bow'). Note that the names are simplistic in the example. The code really looks for the item as named, so it might be something more like 'unapply elven longbow; apply holy shield; apply demonbane'. Note that may be inconvenient if you constant switch between preferred items. (eg, I want to be using that dragonbane right now, not the demonbane). However, if applying a bow automatically unequipped your shield/weapon, that would be no different - you either need to find your appropriate weapon, or have multiple bindings. If the extra time such a binding takes up (3 ticks instead of 1) was a really big concern, the time charged to the player could be reduced to be half an action or something like that (there is no requirement that all actions take one action - one action is really just the baseline to move one space - many of the administrative commands actually have no time associated with them (eg, who, maps, etc) From mwedel at sonic.net Mon Jun 10 02:49:38 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] Equiip change summary. Message-ID: <3D045A12.9010508@sonic.net> I thought it would be best to summarize the change of equip method for items and post a summary before I start doing it for final comments. Brief summary: Instead of a fixed number of items being allowed (eg, 2 rings, 1 sword, etc) and and fairly course use of some flags (can armor negates all armor types, just not torso), creatures will be given various number of body locations to equip items, and items will use some number of these locations. More in depth: An array of 8 bit values will be added to the object structure. This array will hold the number of slots that the specific location holds. For example, if the first element is heads, then for humands this would be one. The load/save could would automatically translate more readable naems and store them into the array. A secondary array will be needed to hold calculated values, so that the program doesn't have to look at all the players items to see if this one could be equipped. It should be noted that except for the load/save translation of this array, the rest of the code really will not care what is in each element. When a player tries to equip something, the code will add the slots used by the item to those the player already has used up, and if this total is greater than the character has allowed, the equip will not be allowed. The more sensible verbose names used in the save files and archetypes will be like: num_heads num_fingers num_arms num_feet num_wrists etc. Items will have negative values for these, showing that in fact they use them up. The monsters themselves will have positive values. I know the negative may be a little odd, but I think in the longer term, it may be more sensible in that if you see a weapon with num_arms 2 and also see the monster with num_arms two, it may be a bit more confusing for what is really happening. Note that these locations are used to determine potentially many different item types. While it may make sense to just say the number of hands should determine number of rings, weapons, and gloves, doing so makes it very difficult for the code to remain its modularity if letting players equip the same things desired (if the array is only 2 hands, and rings, weapons, and gloves all use these hands, you won't be able to equip much). That is why there are arms (weapons/shields), fingers (rings), wrists (braces), and hands (gloves). Creatures of different body types would just have different types (eg, num_dragon_feet for example). Thus, boots for them would need to also have the num_dragon_feet set instead of normal feet. It will be trivial to add such new body locations as needed - just a couple lines in the load/save code will be all it takes (and appropriate arch changes). For classes or gods that restrict what the player can use, it will just have the appropriate num_... with negative values, effectively using up slots. while humanoids would have 2 arms, and in theory could use 2 weapons simultaneously, this will not be allowed. Similarly, they will not be allowed to use two shields at the same time. This could get changed in the future - this is more a balance issue. This would be a special hardcoded case in the code. Two handed weapons would be allowed. Bows would also use two hands. If attempting to equip an item would require an item of a different type unequip, or there are multiple items needed to unequip to use such an item, or a choice of items, the server will not automatically unequip them. Monsters would use similarly look at this information to determine what items they can use - this would take the place of the can_use... flags (some may still be needed, like those that do not actually have a lot, like using spellbooks). From jbontje at suespammers.org Sun Jun 16 14:36:45 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] Crypt in FreeBSD (AGAIN) Message-ID: <20020616193645.GA21213@mids.student.utwente.nl> When reading the cvs mailinglist I noticed that mark disabled the encryption of passwords for crossfire on FreeBSD. I think this is an extremely bad thing for security and compatibility reasons. I don't understand why this is needed. 2 years ago this item showed up too and was addressed in the mailinglist see http://mailman.real-time.com/pipermail/crossfire-devel/2000-November/000597.html and be sure to check the followups. If the solution was to do SHA1 encryption (or MD5) for all platforms by default, I would have seen the use. But decreasing the security doesnt sound good. mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020616/c3b73132/attachment.pgp From mwedel at sonic.net Mon Jun 17 00:16:52 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] Crypt in FreeBSD (AGAIN) References: <20020616193645.GA21213@mids.student.utwente.nl> Message-ID: <3D0D70C4.10106@sonic.net> Joris Bontje wrote: > When reading the cvs mailinglist I noticed that mark disabled the encryption > of passwords for crossfire on FreeBSD. I think this is an extremely bad > thing for security and compatibility reasons. > > I don't understand why this is needed. 2 years ago this item showed up too > and was addressed in the mailinglist see http://mailman.real-time.com/pipermail/crossfire-devel/2000-November/000597.html > > and be sure to check the followups. > > If the solution was to do SHA1 encryption (or MD5) for all platforms by default, > I would have seen the use. But decreasing the security doesnt sound good. I don't consider this as a big deal as it might have been in the long ago past. Putting in some other protection mechanism could be done. But in most cases, the users don't have access to the player files (either because they can't actually log into the system, or the player files have permissions preventing random people from reading the files). Note that if players can read player files at will, this allows some other perhaps less direct means of cheating (hmm. Wonder what this item really does? Let me look at my player file). The reason the change was made was from a bug on sourceforge with the current method not working on freebsd systems without des_crypt. It seemed just as easy to remove that logic all together. Note that the security of crossfire is not that high - the password is sent from the client to server in plain text. For many systems, the password uses standard crypt, which is only 56 bits. Since the password is stored in the player file, it also means that if a user has access to that file, cracking a password probably won't be that difficult. Now it sounds like a better approach for freebsd might to be use des_crypt if available, and if not, use plaintext password. From the bug on sourceforge, that would probably fix the problem. From sikity at mac.com Mon Jun 17 23:38:27 2002 From: sikity at mac.com (Carroll Houk) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] bug in xcrossfire 1.2.0 server with MacOSX Message-ID: <3D0EB943.6090902@mac.com> It seems that on OSX w/ the latest DevKit and patches the materials global (defined in materials.h ) does not get allocated. (i think it was expected to be allocated in attack.c) This was causing a SIGBUS when ever I tried to look at an item. I worked around the problem by just dropping the static def into a .c file from the .h. All seems to work fine now. OS & tool info gcc --version 2.95.2 I am running this on a 500Mhz iBook w/ OSX10.1.5 w/ the April DevKit. I have downloaded and installed fink(Debian package mgr for OSX) (Which was how I found out about crossfire) Carroll. From mwedel at sonic.net Tue Jun 18 23:09:03 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] bug in xcrossfire 1.2.0 server with MacOSX References: <3D0EB943.6090902@mac.com> Message-ID: <3D1003DF.4000307@sonic.net> Carroll Houk wrote: > It seems that on OSX w/ the latest DevKit and patches the materials > global (defined in materials.h ) does not get allocated. (i think it was > expected to be allocated in attack.c) This was causing a SIGBUS when > ever I tried to look at an item. I worked around the problem by just > dropping the static def into a .c file from the .h. All seems to work > fine now. > > OS & tool info > gcc --version 2.95.2 > > I am running this on a 500Mhz iBook w/ OSX10.1.5 w/ the April DevKit. I > have downloaded and installed fink(Debian package mgr for OSX) (Which > was how I found out about crossfire) I'll fix this in CVS. The logic should work (on first include of material.h, define structure and some constants, on second, initialize the array). I personally think that is a bit confusing, and will likely cause other problems (if some other file were to add an include for material.h, it would cause duplicates when it goes to resolve the symbols.) I'm guessing the compiler may be doing some optimization if your case - figuring it already saw that file once, and no need to process it again. IMO, that sounds like a broken compiler to me, but its easy enough to move the actual declation of types to the common/item.c file, so that is what I will do. From mwedel at sonic.net Tue Jun 18 23:56:38 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] Re: Scrolls and prayers References: <200205131047.g4DAlAE16921@pcsinb.pcserve.de> Message-ID: <3D100F06.8000609@sonic.net> S. A. Heyn wrote: > The "problem of experience is not the main problem: > When being surrounded by e.g. Gnolls, Kobolds etc. and having peaced them by singing, I should > be able to inflict diseases within their parties. > If I do the correspnding prayers (cause flu, cause cold, cause red death...) it works. > If I've set traps before facing them (invoke magic rune of cuase red death e.g.) it works too. > Both types are working that good, that when hiding behind a wall I'm hit also > (in Lord Budo's castle and other dungeons this works across walls, in contrast to the > inflicting process!) > However, if I use scrolls, they won't inflict anything at all. So I#ve the impression > these scrolls are useless (but worth their value :-) ). I've looked into this. The cause of the cause... scrolls not working is that when a player casts a scroll, the direction it is cast in is himself. In this way, things like scrolls of protection, armor, etc, get cast on the appropriate person. The problem is that for disease, it looks in the direction the player is facing to determine what to effect - it is not like some things like alchemy which just examine all spaces around the player. So scrolls of cause disease basically just cause the scroll to try and infect the player. Now my thought here is that if the caster and owner do not match (eg, player is using a scroll and not casting it himeself), we could then look at the op->facing to determine where the character is 'pointed' when he cast the disease spell, and use that. This should then make that work, and I can't see any downside to doing that (this would only effect the cause disease stuff, and not the other cases I mentioned above). > > BTW: when using the skill inscription of scrolls I only get scroll of alchemy level 92, regardless > of the former type. Using the inscription skill is relatively cryptic. Basically, whatever spell you have ready is the one put on the scroll. IT always takes your level. But doing this basically means you need to adjust the ring, then use the skill. It would probably make more sense to change the syntax to something like 'inscribe scroll of identify', and it then doesn't need to look at the range field. Good clients could provide some shortcuts for this (eg, player clicks on 'inscribe' menu item, and it then pops up a listing of the spell the player knows, and the player then clicks on one of those, ... From mwedel at sonic.net Tue Jun 25 23:55:22 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] Re: Cause diseases References: <200206251407.g5PE7Mj18714@pcsinb.pcserve.de> Message-ID: <3D19493A.2050302@sonic.net> Copying to list, as some things may be of general interest: S. A. Heyn wrote: > Dear Mark, > > many Thanks for Your answer! > Just another disease hit me often: > > If I go in a dungeon with a lot of monsters (e.g. Administration in brittany) > and have peaced a Dread. I can't inflict any disease in it, neither by prayer nor by traps. > When summoned some pet monsters and inflicted almost any disease the dreads are also > diseased (if I do not go away qick enough I'm also diseased). > Shouldn't there equal behaviour of the diseases? Yep. I don't see any code in place that prevents the infection of friendly/non agressive creatures. I would think that since you can infect yourself, everyone should be infected, including party members. > Another problem: If monsters are inflicted by a trap (invoke magic rune of cause white death for > example) many monsters including other behind walls etc. are hit. I don't think the cause of the infection matters here. I know I've cast a disease spell that hit creatures not directly accessible. I think this may be intentional (eg, even the walls have cracks the disease would get through). The check_infection function which spreads the disease out just looks for creatures within whatever number of spaces that the disease can infect. If diseases should be made to not go through objects, probably wouldn't be too hard to change it - matter of efficiency may come in - to do it properly, a recursive type routine would be needed if the range is more than a couple spaces. I'm not sure what the longest range for any disease is. > But then the server crashes > with the comment "too many errors" and a huge list of "bad skill calcd by player". > I'm not sure, but is it intended to use the magic rune in traps also? > If so, most of the prayers are not working (however nice help for large monsters though :-) ). My guess is that the skill pointer is being set incorrectly - it is probably being set to the wizardry skill (from where the magic rune is cast) and not the wisdom rune. When the code goes to give exp credit, it knows it should go to wisdom yet it doesn't see a wisdom pointer. PRobably not too hard to fix that up. Of course, the server also should not exit - the MAX_ERRORS I guess was there so that when things were really screwed up, the logging of all those errors would cause it to crash and then restart. But for some things, like a spell, the current value of 25 is pretty low - low enough that it could happen in normal circumstances. From mwedel at sonic.net Tue Jun 25 23:57:39 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] [Fwd: Re: DM command: freeze] Message-ID: <3D1949C3.2000002@sonic.net> Forwarding to list as it may be of some general interest. Bob Tanner wrote: > Need a DM command called freeze. > > freeze [character] > > Type freeze as DM with no character name will free everyone and everything in > its place. Both players and monsters. > > freeze Basic would freeze just Basic. > > This is a quick and any way to stop mad pkers so you can -get- to the prison to > summon them. > > The easiest way to freeze everyone would be to just set the objects speed_left to some large negative value (which is basically how paralyze works). Easiest would be to freeze for some number of ticks by default (eg, op->speed_left = -ABS(op->speed) * 100) for 100 ticks for example. What may be easier to do is make a wiz command like 'sendto '. Now mapname ... would be a pain to type, but easy enough to bind keys - could have F1 bound to the right thing to put them in short term jail, F2 medium term jail, etc.. From joel at mamia.prninfo.com Wed Jun 26 13:57:24 2002 From: joel at mamia.prninfo.com (Joel South) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] marking rune,inscription bug Message-ID: <200206261857.OAA07632@mamia.prninfo.com> Another player and I have found a really bad bug. This bug allows you to create items,monsters,just about anything. You can even make keys to apartments or guilds,if you know what the lockcode is. Recently,two pkers were running around metalforge,killing even highlevels. Somehow they broke into a guild and killed the players who were hiding in there,including me. Perhaps they knew of this bug? This bug is done with marking runes or the skill inscription. Here is an example. endmsg face rune_mark.111 type 98 end arch key2 name Key for Apartment 1 race keys slaying apartment1 face key2.111 x 10 y 11 type 21 end arch rune_mark name Rune of Marking end The floor that this rune is made on must be unique. Once the map resets,the item will be created where the x and y is located. The marking rune is pushed to a different part of the map,perhaps the only the upper left corner,or maybe it is the starting place. I haven't bothered to investigate that. Many things can be made with this bug,items of incredible power with resistance to every attack(I think the pkers had such an item,my level 107 in every skill character was unable to even touch one of them),weapons that give you dam+500 or such a number,weapons with god power attack,an item that lifts your speed to some insane number like 5000000.0. With such an item you can even push players off the server! Anyway,this bug must be fixed. Most of the experimentation was done by Markus Kettunen (a.k.a MakeGho, Jibby or Abanji). He has documentation on this bug at "http://koti.mbnet.fi/makegho/misc/cfcheat.1". For more information,talk to MakeGho on ircnet or openprojects. Joel Southall (a.k.a Zar) From mwedel at sonic.net Thu Jun 27 01:42:10 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] marking rune,inscription bug References: <200206261857.OAA07632@mamia.prninfo.com> Message-ID: <3D1AB3C2.40209@sonic.net> Fixed in CVS. Joel South wrote: > Another player and I have found a really bad bug. This bug allows > you to create items,monsters,just about anything. You can even make keys > to apartments or guilds,if you know what the lockcode is. Recently,two > pkers were running around metalforge,killing even highlevels. Somehow they > broke into a guild and killed the players who were hiding in > there,including me. Perhaps they knew of this bug? > This bug is done with marking runes or the skill > inscription. Here is an example. > From temitchell at sympatico.ca Thu Jun 27 12:52:52 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] marking rune,inscription bug References: <200206261857.OAA07632@mamia.prninfo.com> Message-ID: <000801c21e03$759f3b20$0a02a8c0@kameria> On a rel;ated note...I was wondering if there was a way to make marking runes expire since if you cast them on an unique floor, they are there for good. It was just something you could do in an apartment, but now with guilds it is more of an issue. From root at garbled.net Thu Jun 27 12:32:19 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] [Fwd: Re: DM command: freeze] In-Reply-To: <3D1949C3.2000002@sonic.net> Message-ID: On 26-Jun-02 Mark Wedel wrote: > What may be easier to do is make a wiz command like 'sendto > > '. Now mapname ... would be a pain to type, but easy enough to > bind keys - could have F1 bound to the right thing to put them in short term > jail, F2 medium term jail, etc.. On the mud, we just had a wiz command called "hell" which, basically froze the player, and sent them to our prison. So you could just type "hell Bob" and The Right Thing (tm) would happen. (Our "prison" was actually more of a hell than a prison) We also had a god zone where we all hung out. This area was no-move/no-magic, so if we saw something suspicious, we could just bring them up, and talk to them before acting on it. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Thu Jun 27 22:37:53 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:31 2005 Subject: [CF-Devel] marking rune,inscription bug References: <200206261857.OAA07632@mamia.prninfo.com> <000801c21e03$759f3b20$0a02a8c0@kameria> Message-ID: <3D1BDA11.4040604@sonic.net> Todd Mitchell wrote: > On a rel;ated note...I was wondering if there was a way to make marking > runes expire since if you cast them on an unique floor, they are there for > good. It was just something you could do in an apartment, but now with > guilds it is more of an issue. there is no way within the game to current do that I believe. I'm trying to think if there are any cases where being able to erase rooms on permanent floors would cause a problem (eg, they are used for messages). I would think not - I would expect magic mouths for that. If that is the case, it probably would be hard to add some ability to remove the runes. From mwedel at sonic.net Thu Jun 27 22:41:26 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] [Fwd: Re: DM command: freeze] References: Message-ID: <3D1BDAE6.3040806@sonic.net> Tim Rightnour wrote: > > On the mud, we just had a wiz command called "hell" which, basically froze the > player, and sent them to our prison. So you could just type "hell Bob" and The > Right Thing (tm) would happen. (Our "prison" was actually more of a hell than > a prison) I was thinking of that - the command issued would dump them right to some spot on the map. But the fact that there are different locations for different penalties made that a little more difficult. And the fact that I would prefer that such information is dynamically generated - perhaps by something like a .jails file in the map directory, vs having compiled in values. > > We also had a god zone where we all hung out. This area was no-move/no-magic, > so if we saw something suspicious, we could just bring them up, and talk to > them before acting on it. Wouldn't be too hard to do that in crossfire - it really just amounts to making the appropriate map. Best way for no move might be to use player movers to just push players back to the same space. But you could also use something like blocked spaces to prevent movement. From mwedel at sonic.net Thu Jun 27 23:45:04 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] Re: Cause diseases References: <200206251407.g5PE7Mj18714@pcsinb.pcserve.de> Message-ID: <3D1BE9D0.8030207@sonic.net> S. A. Heyn wrote: > Another problem: If monsters are inflicted by a trap (invoke magic rune of > cause white death for example) many monsters including other behind walls > etc. are hit. But then the server crashes with the comment "too many > errors" and a huge list of "bad skill calcd by player". I'm not sure, but > is it intended to use the magic rune in traps also? I looked at the rune code. It seems there may be several problems as it is now: 1) Best I can tell, it does not check to make sure the caster is of sufficient level to cast the spell he is putting in a rune. Now that check is done when you learn the spell. However, suppose you learn a level 15 spell, then lose exp through whatever level so are now level 14. IT appears you can still embed such a spell in the rune. Similarly, it appears that checks for path_denied are not done. So if you learned a spell before it was denied to you (say religion change), it seems you could embed that in a rune also. I have not tried out either of those 2 points. 2) The code takes all the spell point costs from mana. So embedding cleric spells results in the cost still coming from mana, not grace. 3) When the spell is cast by the rune, it seems that the skill pointer isn't set up properly. I'm not positive why this is the case - it may be that the casting logic sees that it is a cleric spell and that the current skill pointer is set for wizardry so just doesn't set anything (assumes it is scroll like or something). The easiest approach would to not allow cleric spells in the generic runes. Runes of healing would still exist as their own rune, but you could do a magic rune of healing for example. That is the easiest fix. Probably an easier approach than trying to make all the above work correctly would be to make a cleric version of 'magic rune', like 'glyph'. Thus, clerics could cast 'glyph of cause typhoid'. Glyphs could only be used with cleric spells, magic runes only with wizard spells. I think that would straighten out most of the skill pointer stuff. From root at garbled.net Sat Jun 29 10:51:59 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] [Fwd: Re: DM command: freeze] In-Reply-To: <3D1BDAE6.3040806@sonic.net> Message-ID: On 28-Jun-02 Mark Wedel wrote: > I was thinking of that - the command issued would dump them right to some > spot > on the map. But the fact that there are different locations for different > penalties made that a little more difficult. And the fact that I would > prefer > that such information is dynamically generated - perhaps by something like a > .jails file in the map directory, vs having compiled in values. Using a jails file.. and perhaps some creativity.. you could do something like this: prison bob 1 And send bob to prison cell one. cells would be defined in the jail file, with mapnames and coordinates of arrival. Perhaps you could even come up with a way to figure out which cells were occupied, so "prison" with no args gives you a list of the incarcerated. Perhaps the jails file would define the four interior corners of the cell and you could scan the area for players. I would suggest a global jails file, rather than one in the maps. That way you could theoretically have more than one jail, and define them centrally. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From temitchell at sympatico.ca Sat Jun 29 12:17:01 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] [Fwd: Re: DM command: freeze] References: Message-ID: <000401c21f90$c830fac0$0a02a8c0@kameria> > > prison bob 1 > > And send bob to prison cell one. cells would be defined in the jail file, with > mapnames and coordinates of arrival. Perhaps you could even come up with a way > to figure out which cells were occupied, so "prison" with no args gives you a > list of the incarcerated. Perhaps the jails file would define the four > interior corners of the cell and you could scan the area for players. > > I would suggest a global jails file, rather than one in the maps. That way you > could theoretically have more than one jail, and define them centrally. > You wouldn't need to check for occupancy, you could make the prisons unique maps, or jam em into a real crummy pit together, or even do both. prision bob 1 (solitary) prision bob 2 (the pit) prision bob 3 (high tower of wrong, just overlooking the pit) From jbontje at suespammers.org Sat Jun 29 12:00:24 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] [Fwd: Re: DM command: freeze] In-Reply-To: References: <3D1BDAE6.3040806@sonic.net> Message-ID: <20020629170024.GA24909@mids.student.utwente.nl> On Sat, Jun 29, 2002 at 08:51:59AM -0700, Tim Rightnour wrote: > [something about the jail command] Additionally special 'silence' floortiles can be added, who disallow the command shout and tell. maybe say too, but then there is no way to torture and interrogate prisoners. mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020629/45540bc9/attachment.pgp From temitchell at sympatico.ca Sat Jun 29 16:39:08 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:32 2005 Subject: [CF-Devel] [Fwd: Re: DM command: freeze] References: <3D1BDAE6.3040806@sonic.net> <20020629170024.GA24909@mids.student.utwente.nl> Message-ID: <001901c21fb5$66b254e0$0a02a8c0@kameria> I seem to remember a wiz command called 'noshout' that would be used on muds to turn the shout flag off on unruly or abusive players. It was good since you abuse the shout command, you can't call for help anymore. Encouraged people to get together to talk as well. ----- Original Message ----- From: "Joris Bontje" To: Sent: Saturday, June 29, 2002 1:00 PM Subject: Re: [CF-Devel] [Fwd: Re: DM command: freeze]