From antonoussik at gmail.com Wed Jan 2 03:15:46 2008 From: antonoussik at gmail.com (Anton Oussik) Date: Wed, 2 Jan 2008 09:15:46 +0000 Subject: [crossfire] Balance changes In-Reply-To: <477882EC.1090704@sonic.net> References: <477882EC.1090704@sonic.net> Message-ID: On 31/12/2007, Mark Wedel wrote: > 2) Since the rebalance here includes scaling things up to level 100, it strikes > me we can not give out new spells every level. Maybe every 5 or so, so at level > 5 you get a small exploding ball and small bolt spell (maybe not at exactly same > level, who knows) Sure you can. Make old spells have old strength until player learns new level of the spell. i.e. to cast lelvel 2 bullet you need to find and learn a level 2 book, and until then you will cast a level 1 bullet. This also allows to fine-tune each spell for each level, however you would want higher level versions to replace lower level versions, to keep the spells list from getting too large. > Item creation classes - if someone wants to play a blacksmith and make weapons > all day, who am I to say no? But with other balance changes, we can know how > this works - that blacksmith needs raw ore, and the facilities and time. Maybe > there is a mine near by he can go to get the ore - but if it takes 5 minutes > realtime for him to get a load of stuff, that help factor out exp gain. > Likewise, if he gets 50 exp for making a sword, it means he has to make a lot of > swords to gain a level, and if an actual time delay is put in there (lets say it > takes 10 seconds realtime to make a sword), it probably means that such a > character will not gain levels any faster than any other class, so IMO would be > considered in balance. The only issue here is that I think such long time (10 > second) actions need to be interruptible - in a sense, it is almost like the run > on stuff - the character keeps making the sword unless he chooses to do > something else. And there is some chance at failure - a first level blacksmith > maybe only has a 50% chance to successfully make a sword for example. > > I think clerics/priests are basically OK. Any other thoughts out there? Do what is already done for mages - make alchemy-like things use mana. It means the blacksmith will need rest sooner or later. If using actual mana is too unrealistic to drain by alchemy (as not strictly magical), perhaps a new type of fatigue could be introduced... However using mana would be easier for the players IMO. From mwedel at sonic.net Wed Jan 2 23:08:13 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 02 Jan 2008 21:08:13 -0800 Subject: [crossfire] Balance changes In-Reply-To: References: <477882EC.1090704@sonic.net> Message-ID: <477C6DBD.10301@sonic.net> Anton Oussik wrote: > On 31/12/2007, Mark Wedel wrote: > >> 2) Since the rebalance here includes scaling things up to level 100, it strikes >> me we can not give out new spells every level. Maybe every 5 or so, so at level >> 5 you get a small exploding ball and small bolt spell (maybe not at exactly same >> level, who knows) > > Sure you can. Make old spells have old strength until player learns > new level of the spell. i.e. to cast lelvel 2 bullet you need to find > and learn a level 2 book, and until then you will cast a level 1 > bullet. This also allows to fine-tune each spell for each level, > however you would want higher level versions to replace lower level > versions, to keep the spells list from getting too large. But I'm not sure if there is much point to that. If there are sufficient different spells to cover all the levels, that is fine. But having a level 1 bullet, and level 2 bullet, etc, in which the spells are really the same except for a minor damage variation seems a bit excessive. The damage variation can be handled by increase in the caster level itself - a new spell at every level isn't needed. Sure, it puts more spells out there, but if they are really the same spell, they are not different spells. And as a player, I'm not sure if i would like that idea either - having to upgrade all the spells each time you gain a level would seem more annoying than fun if all the difference is something minor. In fact, it would likely create even more spell book hunting as your try to find spellbooks of not only appropriate spell, but also of appropriate level. You also get weird issues with death. Imagine my character has 'upgraded' all his spells to be his current casting level. He dies, and loses a level in that skill - now he has a bunch of spells he can't cast. >> Item creation classes - if someone wants to play a blacksmith and make weapons >> all day, who am I to say no? But with other balance changes, we can know how >> this works - that blacksmith needs raw ore, and the facilities and time. Maybe >> there is a mine near by he can go to get the ore - but if it takes 5 minutes >> realtime for him to get a load of stuff, that help factor out exp gain. >> Likewise, if he gets 50 exp for making a sword, it means he has to make a lot of >> swords to gain a level, and if an actual time delay is put in there (lets say it >> takes 10 seconds realtime to make a sword), it probably means that such a >> character will not gain levels any faster than any other class, so IMO would be >> considered in balance. The only issue here is that I think such long time (10 >> second) actions need to be interruptible - in a sense, it is almost like the run >> on stuff - the character keeps making the sword unless he chooses to do >> something else. And there is some chance at failure - a first level blacksmith >> maybe only has a 50% chance to successfully make a sword for example. >> >> I think clerics/priests are basically OK. Any other thoughts out there? > > Do what is already done for mages - make alchemy-like things use mana. > It means the blacksmith will need rest sooner or later. If using > actual mana is too unrealistic to drain by alchemy (as not strictly > magical), perhaps a new type of fatigue could be introduced... However > using mana would be easier for the players IMO. But using mana doesn't really work for non spell skills. A person doing smithery gets no increase from mana for smithery skill, which basically limits the ability to do smithery a great deal. and I'd bet a character that is serious about alchemy doesn't have much impact from the mana cost - if you max out mana regeneration items, you can get mana back really fast. In the dungeon, you may not do that for general adventuring (other rings better for that), but if all you are doing is alchemy and need to get back mana, can suck it back up pretty quickly. Doing something like fatigue works. But the real balance here IMO is the time it takes. Using mana for alchemy sort of does that - the actual act of alchemy takes no real time, the time it takes to regain the mana limits it to some extent. IMO, how exactly this is limited isn't as important - it could be each action takes quite a while, could be that you have something like fatigue you need to recover from, it could be that many actions are needed to make a sword (need to first refine the raw ore, then make a bar, than make rough sword object, then make finished (normal) sword, then make better weapon). It does mean that a player could short cut some of this, but if we presume each of those stages gives some amount of exp, the player doesn't gain much by skipping the refining the phase - he makes the sword faster, but may not get exp any faster. A character could then melt down his swords and make items again (to get exp), but that isn't the problem - the balance here is how long it takes him to make the items. Clearly, if other players bring him piles of weapons (or ore for that matter) to work with, saves the weapon maker some time from making those objects, but that is also true with most anything else - if players cooperate, some characters can gain exp faster than if they worked alone. From nicolas.weeger at laposte.net Thu Jan 3 02:01:24 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 3 Jan 2008 09:01:24 +0100 Subject: [crossfire] Plan to commit combat changes to trunk In-Reply-To: <47787CA6.9050405@sonic.net> References: <47787CA6.9050405@sonic.net> Message-ID: <200801030901.34242.nicolas.weeger@laposte.net> > I've been playing with the rebalance of melee combat for crossfire for a > while, and while not 100% done, I think it is complete enough to warrant > committing it to the trunk and hopefully getting more exposure. > > Now for folks running trunk servers, while the change will not cause > anything to actually break (or it shouldn't), it will cause a change in > game play, so folks may find combat tougher. Gonna be hard on permadeath servers :) > I have also limited the generators, via arch change, to only generate 5 > monsters before the generator dies. I'm sure some maps need updating - > that 5 monster limit is actually a pretty good compromise - it tends to > fill up those empty dungeons that rely on generators to fill them up, but > also keeps monsters at a reasonable level. That's a major change, though. Many maps, especially some training centers or Gorokh's final map, actually rely on illimited generators. So maybe that should not be committed for now, or made optional for map designers to decide. > I could do all this work in a branch - I'm just don't think that is > really worthwhile - the main point of the trunk is to work on the big > projects like this. I'd say that where things are now, it has moved beyond > expiremental code to code that will be used, but some more work is still > needed. I'll start another thread about future changes for balancing. But > I'm willing to discuss, and for folks to see this as a heads up if you are > running a trunk server. Agreed, trunk is for big changes... Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080103/461fa947/attachment.pgp From nicolas.weeger at laposte.net Thu Jan 3 02:12:31 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 3 Jan 2008 09:12:31 +0100 Subject: [crossfire] Balance changes In-Reply-To: <477882EC.1090704@sonic.net> References: <477882EC.1090704@sonic.net> Message-ID: <200801030912.35935.nicolas.weeger@laposte.net> > While I haven't adjusted bow combat, from the basic uses I've done so > far, it seems to be somewhat reasonable - the fire/kill rate is somewhat > close to to melee - big advantage is that you're not right next to > creature. Big disadvantage is you need to carry thousands of arrows about. > A thought here is to greatly reduce the odds of arrows (at least non > special ones) being destroyed, so you can at least get back most of the > arrows you fire (special ones, like the assassinating whatever should still > be one shot). Agreed on one shot assassination, but it does need to do real extra damage, else no need for them - I'd rather carry/make 3 regular arrows than take the time to find all ingredients for a special one! > Spells are the next thing to tackle. I think I'll go down the route of > elemental spells, as discussed. Some additional quick thoughts: Discussion seemed ok. > 3) In order to make these low level spells effectively, I think the damage > on them needs to ramp up pretty quickly (creatures hp goes up about > 10/creature level, so level 1 creatures have 20 hp, level 5 about 50 hp, > level 10 around 150 hp). To counter this, max damage/range/whatever type > things are added, so at level 15 (lets say) that firebullet you get a first > level doesn't get any better. *nods* > 4) Related to this, better version of low level spells can be put in the > game. At level 10, maybe give out 'medium bullet' type of thing, which > costs more than the small one, but does more damage and also scales up to > higher level. Please, no. No "small fireball", "medium fireball", "large fireball", "extra large fireball", "xxx fireball", "mega fireball", "guaranteed most powerful fireball". I'd rather have just damage/range gain for levels. > I've also had some thoughts on other classes: > Thief/Rogue - crossfire doesn't really have much like this. One thought to > make this a more viable class is to remove the search and disarm traps from > other classes - most game systems does not allow a mage to disarm traps. > This doesn't help as much in standalone, but helps in party play (having > that thief to find and disarm traps would be useful). I think the trap exp > needs to be adjusted for this to be more playable. We should probably also > allow thieves to make traps, and if they kill a monster with that trap, get > the appropriate exp for it. I also think traps should probably be made > deadlier. A trapped door or trapped chest isn't all that dangerous if a > character at full hit points will never die from it (an alternative is > maybe longer term affects - we have discussed the idea of some spells > lasting hours of real time. Imagine you get hit with a trap which depletes > a stat or slows the character that that lasts half an hour - you can't just > run out of the dungeon and wait it out, like you can with most cases of > poison or damage). The last is hiding and sneak attacks - if player is > hidden and attacks a creature, give them extra damage, and if they kill the > creature, maybe split exp between hiding and the weapon skill?) Likewise, > letting rogues steal from shops should perhaps be allowed, but if caught, > they are tossed in the town jail for some amount of time. Could be fun, but then you need to really tune traps. Until you have many hp, you can easily die to one trap on a door (not sure how much damage it does, maybe 50?). So that's a one kill shot for players... > Item creation classes - if someone wants to play a blacksmith and make > weapons all day, who am I to say no? But with other balance changes, we > can know how this works - that blacksmith needs raw ore, and the facilities > and time. Maybe there is a mine near by he can go to get the ore - but if > it takes 5 minutes realtime for him to get a load of stuff, that help > factor out exp gain. Likewise, if he gets 50 exp for making a sword, it > means he has to make a lot of swords to gain a level, and if an actual time > delay is put in there (lets say it takes 10 seconds realtime to make a > sword), it probably means that such a character will not gain levels any > faster than any other class, so IMO would be considered in balance. The > only issue here is that I think such long time (10 second) actions need to > be interruptible - in a sense, it is almost like the run on stuff - the > character keeps making the sword unless he chooses to do something else. > And there is some chance at failure - a first level blacksmith maybe only > has a 50% chance to successfully make a sword for example. Needs tuning, as well as alchemy. Ideally, almost all classes should be able to do that, though maybe at a lower level. > I think clerics/priests are basically OK. Any other thoughts out there? Probably ok, depending on balance we put. I'd also think party spells could be useful - mass protection, this kind of things. -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080103/147d53fe/attachment.pgp From antonoussik at gmail.com Thu Jan 3 02:48:19 2008 From: antonoussik at gmail.com (Anton Oussik) Date: Thu, 3 Jan 2008 08:48:19 +0000 Subject: [crossfire] Balance changes In-Reply-To: <477C6DBD.10301@sonic.net> References: <477882EC.1090704@sonic.net> <477C6DBD.10301@sonic.net> Message-ID: On 03/01/2008, Mark Wedel wrote: > Anton Oussik wrote: > > On 31/12/2007, Mark Wedel wrote: > > > >> 2) Since the rebalance here includes scaling things up to level 100, it strikes > >> me we can not give out new spells every level. Maybe every 5 or so, so at level > >> 5 you get a small exploding ball and small bolt spell (maybe not at exactly same > >> level, who knows) > > > > Sure you can. Make old spells have old strength until player learns > > new level of the spell. i.e. to cast lelvel 2 bullet you need to find > > and learn a level 2 book, and until then you will cast a level 1 > > bullet. This also allows to fine-tune each spell for each level, > > however you would want higher level versions to replace lower level > > versions, to keep the spells list from getting too large. > > But I'm not sure if there is much point to that. If there are sufficient > different spells to cover all the levels, that is fine. > > But having a level 1 bullet, and level 2 bullet, etc, in which the spells are > really the same except for a minor damage variation seems a bit excessive. The > damage variation can be handled by increase in the caster level itself - a new > spell at every level isn't needed. Sure, it puts more spells out there, but if > they are really the same spell, they are not different spells. > > And as a player, I'm not sure if i would like that idea either - having to > upgrade all the spells each time you gain a level would seem more annoying than > fun if all the difference is something minor. In fact, it would likely create > even more spell book hunting as your try to find spellbooks of not only > appropriate spell, but also of appropriate level. > > You also get weird issues with death. Imagine my character has 'upgraded' all > his spells to be his current casting level. He dies, and loses a level in that > skill - now he has a bunch of spells he can't cast. Yes, fair enough. Some spells today are already improvements of older versions though, e.g. the snowstorms, so you already have a bit of chasing "higher version" of a spell around. Perhaps it is a question of striking the right balance between having too many similar spells of different levels and too few spells to encourage progressing. > >> Item creation classes - if someone wants to play a blacksmith and make weapons > >> all day, who am I to say no? But with other balance changes, we can know how > >> this works - that blacksmith needs raw ore, and the facilities and time. Maybe > >> there is a mine near by he can go to get the ore - but if it takes 5 minutes > >> realtime for him to get a load of stuff, that help factor out exp gain. > >> Likewise, if he gets 50 exp for making a sword, it means he has to make a lot of > >> swords to gain a level, and if an actual time delay is put in there (lets say it > >> takes 10 seconds realtime to make a sword), it probably means that such a > >> character will not gain levels any faster than any other class, so IMO would be > >> considered in balance. The only issue here is that I think such long time (10 > >> second) actions need to be interruptible - in a sense, it is almost like the run > >> on stuff - the character keeps making the sword unless he chooses to do > >> something else. And there is some chance at failure - a first level blacksmith > >> maybe only has a 50% chance to successfully make a sword for example. > >> > >> I think clerics/priests are basically OK. Any other thoughts out there? > > > > Do what is already done for mages - make alchemy-like things use mana. > > It means the blacksmith will need rest sooner or later. If using > > actual mana is too unrealistic to drain by alchemy (as not strictly > > magical), perhaps a new type of fatigue could be introduced... However > > using mana would be easier for the players IMO. > > But using mana doesn't really work for non spell skills. A person doing > smithery gets no increase from mana for smithery skill, which basically limits > the ability to do smithery a great deal. Having the action take a long time would just be perceived as lag, and so should be avoided if at all possible. Multi-stage item creation could easily be scripted and may get tedious unless exp and possibly money award is sufficient. Adopting a similar system to the one used by rods now to prevent overuse may be most appropriate. From nicolas.weeger at laposte.net Thu Jan 3 10:25:43 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 3 Jan 2008 17:25:43 +0100 Subject: [crossfire] Next release In-Reply-To: <477877D7.3000201@sonic.net> References: <477877D7.3000201@sonic.net> Message-ID: <200801031725.46988.nicolas.weeger@laposte.net> Le lundi 31 d?cembre 2007, Mark Wedel a ?crit?: > Had mentioned several months back I was going to do a new stable release > in the near future. Between getting sidetracked and waiting for some > changes to get put back, I never got around to making a release. Hopefully there will be a Windows release, last tests show everything work as intented, just need to ensure all DLLs are packed as needed :) Client has metaserver2 support, and server should too when I get the time (unless someone else does it before, of course ^_-) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080103/0e8dc059/attachment.pgp From juhaj at iki.fi Thu Jan 3 10:42:52 2008 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Thu, 03 Jan 2008 18:42:52 +0200 Subject: [crossfire] Balance changes In-Reply-To: References: <477882EC.1090704@sonic.net> <477C6DBD.10301@sonic.net> Message-ID: <200801031843.00600.juhaj@iki.fi> > Having the action take a long time would just be perceived as lag, and > so should be avoided if at all possible. Brewing potions (or beer!) could easily have a time lag: it takes time for the stuff to brew. BUT it does not mean the player should stand immobile: the player should keep the forge hot while the steel is heating etc. Hammering the blade into shape DOES take some time, but if we make the preparations time consuming (without making the player immobile), the balance can be achieved without making the hammering last too long. This has two advantages: scripting does not make it any faster and it is realistic (except for the hammering-takes-no-time-part, which is game-technically required so that players don't think it's lagging or get bored): it takes some time to heat a forge, it takes some time for the metal to heat up etc. > Adopting a similar system to the one used by rods now to prevent > overuse may be most appropriate. I have never created a rod. How does this happen? -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080103/b7ccb4e8/attachment-0001.pgp From mwedel at sonic.net Fri Jan 4 00:32:26 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 03 Jan 2008 22:32:26 -0800 Subject: [crossfire] Plan to commit combat changes to trunk In-Reply-To: <200801030901.34242.nicolas.weeger@laposte.net> References: <47787CA6.9050405@sonic.net> <200801030901.34242.nicolas.weeger@laposte.net> Message-ID: <477DD2FA.1070606@sonic.net> Nicolas Weeger wrote: >> I've been playing with the rebalance of melee combat for crossfire for a >> while, and while not 100% done, I think it is complete enough to warrant >> committing it to the trunk and hopefully getting more exposure. >> >> Now for folks running trunk servers, while the change will not cause >> anything to actually break (or it shouldn't), it will cause a change in >> game play, so folks may find combat tougher. > > Gonna be hard on permadeath servers :) Hence the warning. May not be a bad idea for server admins to make a backup of the player files, just in case. > >> I have also limited the generators, via arch change, to only generate 5 >> monsters before the generator dies. I'm sure some maps need updating - >> that 5 monster limit is actually a pretty good compromise - it tends to >> fill up those empty dungeons that rely on generators to fill them up, but >> also keeps monsters at a reasonable level. > > That's a major change, though. Many maps, especially some training centers or > Gorokh's final map, actually rely on illimited generators. So maybe that > should not be committed for now, or made optional for map designers to > decide. So maps themselves can always override it. This is just the basic archetype property. Now folks could use the old archetypes, disable that section of code, etc. However, I think the better answer is to run with the new archetypes, see what is broken (or needs to be adjusted) and fix it. That needs to get done sooner or later, so may as well do it sooner. From mwedel at sonic.net Fri Jan 4 00:56:18 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 03 Jan 2008 22:56:18 -0800 Subject: [crossfire] Balance changes In-Reply-To: <200801030912.35935.nicolas.weeger@laposte.net> References: <477882EC.1090704@sonic.net> <200801030912.35935.nicolas.weeger@laposte.net> Message-ID: <477DD892.8050607@sonic.net> Nicolas Weeger wrote: >> While I haven't adjusted bow combat, from the basic uses I've done so >> far, it seems to be somewhat reasonable - the fire/kill rate is somewhat >> close to to melee - big advantage is that you're not right next to >> creature. Big disadvantage is you need to carry thousands of arrows about. >> A thought here is to greatly reduce the odds of arrows (at least non >> special ones) being destroyed, so you can at least get back most of the >> arrows you fire (special ones, like the assassinating whatever should still >> be one shot). > > Agreed on one shot assassination, but it does need to do real extra damage, > else no need for them - I'd rather carry/make 3 regular arrows than take the > time to find all ingredients for a special one! I think many recipes may be too hard (or do not generate enough of an item) for the ingredients required - that is certainly another balance issue there - alchemy has never been balanced, it should be done. But that isn't quite as main part of the game as say magic and fighting is, and is also balance in a different nature (difficulty of ingredients, difficulty of recipes, etc) >> 4) Related to this, better version of low level spells can be put in the >> game. At level 10, maybe give out 'medium bullet' type of thing, which >> costs more than the small one, but does more damage and also scales up to >> higher level. > > Please, no. > No "small fireball", "medium fireball", "large fireball", "extra large > fireball", "xxx fireball", "mega fireball", "guaranteed most powerful > fireball". > I'd rather have just damage/range gain for levels. Just doing damage/range gains per level may be workable with the revised monsters. In the past, that didn't work when a first level monster had 20 hp and the level 20 monster had 2000 - there just wasn't any good way to scale up the damage on the spell properly. But it is probably too early to really say if that is the case. But the other issue with different versions is a mix of area vs damage. The bolt vs cone is simplest example - for any given space, a bolt does more damage, but the cone hits many more spaces, and its total damage potential is probably higher. For things like bolts and cones, scaling up is pretty straight forward. For exploding balls, this is less clear cut. It is very possible that in some circumstances, I want a fireball that explodes in a relatively small radius but puts a good amount of damage in that radius (imagine targeting one creature). However, there are other cases where maybe I want it to hit a quite big radius, but am willing to have it do less damage for any given space. One can come up with some form of control language (cast fireball radius=3, dam=15, duration=8) type of thing, but at minimum, that would need some form of interface on the client. The harder part IMO is trying to sort that out on the server side. It is fairly straight forward to say 'a fireball of radius=3, base damage=20, duration=5 cost X sp' and 'a fireball of radius=6, base damage=10, duration=6 costs y SP' an balance out those SP or other values. It is much harder to do that formulaicly and have good values. The issue isn't as much players choosing values that are not effective (spell costs 100 mana and doesn't do a whole bunch), the greater potential problem is the reverse - player seeing that they can minimize (or maximize) certain of those variables and effectively get very effective (in terms of damage/mana) spells for certain situations. Now the morrowind/oblivion commercial game had a way to make custom spells, but from my experience there, the custom spells the player could make would cost a lot more mana than the pre define spells in the game (probably for that same reason - it is resorting to some simple formula to figure out cost). Crossfire could of course do the same thing, that basic low level fireball, when cast a high levels, results in a big fireball with lots of damage, but the player could limit its damage or affect, and get some savings in mana cost (but done in such a way that the cost savings are not really good). But I'm also not sure if a few different varieties of the spells are a bad thing. Sure, 10 varieties of fireball is bad, but I'm not sure if 3 (small, medium, large). I think some of the problem with number of spells is just spells get added, like 'wouldn't it be neat to have a lightning ball' type of thing. There are lots of attacktypes, so one could make a huge number of spells, and I think some serious pruning may be in order when spells are redone. > > >> I've also had some thoughts on other classes: >> Thief/Rogue - crossfire doesn't really have much like this. One thought to >> make this a more viable class is to remove the search and disarm traps from >> other classes - most game systems does not allow a mage to disarm traps. >> This doesn't help as much in standalone, but helps in party play (having >> that thief to find and disarm traps would be useful). I think the trap exp >> needs to be adjusted for this to be more playable. We should probably also >> allow thieves to make traps, and if they kill a monster with that trap, get >> the appropriate exp for it. I also think traps should probably be made >> deadlier. A trapped door or trapped chest isn't all that dangerous if a >> character at full hit points will never die from it (an alternative is >> maybe longer term affects - we have discussed the idea of some spells >> lasting hours of real time. Imagine you get hit with a trap which depletes >> a stat or slows the character that that lasts half an hour - you can't just >> run out of the dungeon and wait it out, like you can with most cases of >> poison or damage). The last is hiding and sneak attacks - if player is >> hidden and attacks a creature, give them extra damage, and if they kill the >> creature, maybe split exp between hiding and the weapon skill?) Likewise, >> letting rogues steal from shops should perhaps be allowed, but if caught, >> they are tossed in the town jail for some amount of time. > > Could be fun, but then you need to really tune traps. > Until you have many hp, you can easily die to one trap on a door (not sure how > much damage it does, maybe 50?). So that's a one kill shot for players... Traps need to be retuned for higher HP. What would probably be good to add to crossfire, especially for traps, is some idea of bleeding wounds. Something like you set off a trap. It does 25 damage. But in addition, it does 1 damage/tick for the next 40 ticks (or maybe every 5 ticks it does 5 points or something) So if you can heal, or you have a party member that can heal, you'll survive. Perhaps even the healing spells should stop the bleeding. But at the same time, if you set off a trap, you're not instantly dead wondering what happened - you see yourself in the process of dying, and thus have some clue to what happened, and also have some limited recourse. From mwedel at sonic.net Fri Jan 4 01:07:11 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 03 Jan 2008 23:07:11 -0800 Subject: [crossfire] Balance changes In-Reply-To: References: <477882EC.1090704@sonic.net> <477C6DBD.10301@sonic.net> Message-ID: <477DDB1F.9050500@sonic.net> Anton Oussik wrote: > Yes, fair enough. Some spells today are already improvements of older > versions though, e.g. the snowstorms, so you already have a bit of > chasing "higher version" of a spell around. Perhaps it is a question > of striking the right balance between having too many similar spells > of different levels and too few spells to encourage progressing. But current system, those are distinct spells, and not upgrades. When you learn medium snowstorm, you still have small snowstorm available. There are two real effects of this - if you lose a level, you may not be able to cast medium snowstorm, but you still have the small snowstorm you can cast, since they are distinct spells and not an upgrade. It also means that for any given spell, there is still just one spellbook. I personally don't think having too few spells would discourage progressing so long as the spells you have get better. Fighter classes have no spells, you people progress in them because they can do more damage, get exp, etc. I see the spellcasting skills the same way. If you learn those first level spells and never get any more exp in the spellcasting classes, you're likely to find out pretty quickly that those first level spells (or more relevent, first level casting level), just doesn't cut it. Casting a level 1 bullet spell at a level 10 monster won't ever kill it, etc. > > Having the action take a long time would just be perceived as lag, and > so should be avoided if at all possible. It depends on how it is done. If there is a graphic showing the the character working, gives some feedback. Likewise, if the player can hit a key and say move, and thus stop what they were working on, that also eliminates any perception of lag. > > Multi-stage item creation could easily be scripted and may get tedious > unless exp and possibly money award is sufficient. IMO, item creation is only of interest for players that find that type of thing interesting. Some folks find it interesting to play a game, going into the forest to chop the wood, bring it back, and spend time making arrows. If they do, crossfire should try to provide a way for that to work and for them to get exp, and perhaps take part in some way in the game (provide arrows for anyone that wants them, etc). However, if what you find fun is zapping monsters with spells or killing them with a sword, that won't appeal to you, and there probably isn't any way to change it that would make it appeal to you - or at least not change it in a way that preserves any sort of balance. Most anything in the game could get scripted, if someone has the incentive to do so. I don't think there is any real way to prevent that - even something like a fatigue system (where you need to refrain from creating an item for some time) doesn't prevent scripting, it just slows it down (it means the script keeps the character idle until the requisite time passes). But in the end, it also comes out to basically the same thing - trying to limit how fast a character can do these actions - it can be done by making the actions slow, requiring rest period, multiple stages, etc. I'm not sure what the best answer is. From juhaj at iki.fi Fri Jan 4 02:49:54 2008 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Fri, 4 Jan 2008 10:49:54 +0200 Subject: [crossfire] Balance changes In-Reply-To: <477DD892.8050607@sonic.net> References: <477882EC.1090704@sonic.net> <200801030912.35935.nicolas.weeger@laposte.net> <477DD892.8050607@sonic.net> Message-ID: <200801041049.54630.juhaj@iki.fi> > I think many recipes may be too hard (or do not generate enough of an > item) for the ingredients required - that is certainly another balance > issue there - alchemy has never been balanced, it should be done. But > that isn't quite as main part of the game as say magic and fighting is, > and is also balance in a different nature (difficulty of ingredients, > difficulty of recipes, etc) This certainly has been an issue - both with alchemy and other item creation skills as well. (I will use alchemy as a synonym to item creation skill.) Basically, an arrow of slaying X should be equally difficult to create as actually going to kill X. Of course, some characters will have easier time killing X than others (follower of gaea killing a dread is probably having a lot easier task than someone else), so the best situation would be where creating Y of slaying X is easy for a character who would have a hard time killing X and not so easy for others. That would be difficult to do, though. All in all, just try to keep creating things about as difficult as producing the same effect without the item. Arrows of slaying are easy: the kill a single monster, so the effect is quite clear. Obviously, rod of lightning bolt is a little more difficult to judge... > Just doing damage/range gains per level may be workable with the revised > monsters. In the past, that didn't work when a first level monster had 20 > hp and the level 20 monster had 2000 - there just wasn't any good way to > scale up the damage on the spell properly. But it is probably too early to > really say if that is the case. There is an infinite amount of functions to choose from. There *is* a suitable function to scale up the damage no matter how the monsters' HP scale. The question is how to figure out the correct function... > But the other issue with different versions is a mix of area vs damage. Is this really so hard? Can't we just say that a spell with maximum inflicted damage (on stationary targets) of X hit points costs f(X) mana points? That way, a bullet which hits a single target and has maximum damage X, costs f(X); a bolt which has maximum damage Y per square and envelops N squares, costs f(Y*N) etc. That would be quite fair and it would really discourage the use of area effect spells against individual targets (although that is the player's choice, not something we want to prevent). > The harder part IMO is trying to sort that out on the server side. It is > fairly straight forward to say 'a fireball of radius=3, base damage=20, > duration=5 cost X sp' and 'a fireball of radius=6, base damage=10, > duration=6 costs y SP' an balance out those SP or other values. Could we not use small/medium/large balls/bolts/cones for this? It would be less flexible, but easier for players. The damage could scale the same way, but damage/area would be less for the large versions than medium than small. Total (maximum) damage would be the same. Even if we let players specify the kind of spell they want (which is, btw, a nice touch, I think!) the above mentioned f(X) -method of figuring out the sp cost should work fine. I also think players should be able to create more powerful bullets as well, not just balls/cones/bolts. I might well imagine a situation where a player has enough mana to cast a bunch of bullets at a single target, but would prefer using a single, more powerful bullet to achieve the same result faster. Oh, this also means, that we need to discard the easiest method of handling player-adjustable area/damage: we cannot simply fix the maximum damage of a given spell (and let the player just alter the area). What we CAN do, however, is fix the function f to be the same for all spells (except perhaps the "fifth" element weaponmagic spells which almost no monster has protection against). (I really hope this "fifth element" we discussed in the summer is part of what Mark's doing now.) One further note: perhaps maximum damage in all of the above should really be "expectation value of damage" instead. It's more fair since for any large area of effect spell you expect never to actually achieve the maximum damage - too low probablility - whereas for bullets you expect to achieve it every now and then. > Traps need to be retuned for higher HP. Can't we just bind trap damage to dungeon level? If a 1st level player enters a 50th level dungeon, he is expected to die - it does not matter if it's a monster or a trap that kills him. This would solve the problem that traps are either harmless to higher level characters or immediate death to lower level ones. > What would probably be good to add to crossfire, especially for traps, is > some idea of bleeding wounds. Could this not be done with a new type of disease? -Juha From nicolas.weeger at laposte.net Sat Jan 5 16:15:23 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 5 Jan 2008 23:15:23 +0100 Subject: [crossfire] New manhole archetype WIP (accepting help) In-Reply-To: <200712291024.39359.kbulgrien@worldnet.att.net> References: <200712291024.39359.kbulgrien@worldnet.att.net> Message-ID: <200801052315.27551.nicolas.weeger@laposte.net> Hello. I just fixed the animation bug, from what I can see. The holes correctly open and close, both the archetypes. Part server bug, part archetype mistake, I think. All committed :) Note that, maybe, it could be possible to have both an animated hole and an opening animation - maybe by combining the facings and direction? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080105/02c3e643/attachment.pgp From kbulgrien at worldnet.att.net Sat Jan 5 21:44:16 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 5 Jan 2008 21:44:16 -0600 Subject: [crossfire] New manhole archetype WIP (accepting help) In-Reply-To: <200801052315.27551.nicolas.weeger@laposte.net> References: <200712291024.39359.kbulgrien@worldnet.att.net> <200801052315.27551.nicolas.weeger@laposte.net> Message-ID: <200801052144.17168.kbulgrien@worldnet.att.net> > Hello. > > I just fixed the animation bug, from what I can see. > > The holes correctly open and close, both the archetypes. > > Part server bug, part archetype mistake, I think. > > All committed :) > > Note that, maybe, it could be possible to have both an animated hole and an > opening animation - maybe by combining the facings and direction? > > > Nicolas Thanks... the animation was already "working" with the arch "tweaked" so the faces of the non-head parts were blank as noted in the README, but the hole didn't line up with the arch "head". I do not see a change in behavior. Yes, I did update. Maybe I should set up the test to show the various test cases I've tried and more explicitly note in the map what is wrong with each. I untweaked the arch by setting the faces back to the proper settings and the animation doesn't seem to work for me. I'm not sure what archetype mistake you might be referring to. AFAIK, I am testing the arch the same way that the pit is set up to work. I see in IRC that you mention HOLE uses HP/WC, but pit.arc does not have HP set, but does WC, which is the frame of the anim that is shown as the static image before the item is activated. maxsp is set too. I think it means whether the hole is open or shut by default. Kevin From kbulgrien at worldnet.att.net Sat Jan 5 23:35:14 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 5 Jan 2008 23:35:14 -0600 Subject: [crossfire] New manhole archetype WIP (accepting help) In-Reply-To: <200801052144.17168.kbulgrien@worldnet.att.net> References: <200712291024.39359.kbulgrien@worldnet.att.net> <200801052315.27551.nicolas.weeger@laposte.net> <200801052144.17168.kbulgrien@worldnet.att.net> Message-ID: <200801052335.15216.kbulgrien@worldnet.att.net> > Thanks... the animation was already "working" with the arch > "tweaked" so the faces of the non-head parts were blank as > noted in the README, but the hole didn't line up with the > arch "head". I do not see a change in behavior. Yes, I did > update. Maybe I should set up the test to show the various > test cases I've tried and more explicitly note in the map > what is wrong with each. > > I untweaked the arch by setting the faces back to the proper > settings and the animation doesn't seem to work for me. I'm > not sure what archetype mistake you might be referring to. > AFAIK, I am testing the arch the same way that the pit is set > up to work. > > I see in IRC that you mention HOLE uses HP/WC, but pit.arc > does not have HP set, but does WC, which is the frame of the > anim that is shown as the static image before the item is > activated. maxsp is set too. I think it means whether the > hole is open or shut by default. Nevermind, I see hp = x, sp = y now. By the way, is_animated is 0, as copied from pit.arc. I don't know what that Also note that now the console gives: [Error] Object lacks animation. [Error] arch manhole_closed_3a I'm not sure the change is made in svn is correct. is_animated is 0 because it is not continually animated but triggered (I think, and going by pit.arc). The error message goes away if I put is_animated 1 in the arch, even though pit arc doesn't use it that way, but the animation still doesn't work. I've committed an update to the world_105_115.patch and to the arch files to better explain the different cases. There are six examples now. None of them work correctly even though 4 of them have a functioning animation. Kevin From kbulgrien at worldnet.att.net Sat Jan 5 23:48:06 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 5 Jan 2008 23:48:06 -0600 Subject: [crossfire] New manhole archetype WIP (accepting help) In-Reply-To: <200801052335.15216.kbulgrien@worldnet.att.net> References: <200712291024.39359.kbulgrien@worldnet.att.net> <200801052144.17168.kbulgrien@worldnet.att.net> <200801052335.15216.kbulgrien@worldnet.att.net> Message-ID: <200801052348.06848.kbulgrien@worldnet.att.net> On Saturday 05 January 2008 23:35, Kevin R. Bulgrien wrote: > > Thanks... the animation was already "working" with the arch > > "tweaked" so the faces of the non-head parts were blank as > > noted in the README, but the hole didn't line up with the > > arch "head". I do not see a change in behavior. Yes, I did > > update. Maybe I should set up the test to show the various > > test cases I've tried and more explicitly note in the map > > what is wrong with each. > > > > I untweaked the arch by setting the faces back to the proper > > settings and the animation doesn't seem to work for me. I'm > > not sure what archetype mistake you might be referring to. > > AFAIK, I am testing the arch the same way that the pit is set > > up to work. > > > > I see in IRC that you mention HOLE uses HP/WC, but pit.arc > > does not have HP set, but does WC, which is the frame of the > > anim that is shown as the static image before the item is > > activated. maxsp is set too. I think it means whether the > > hole is open or shut by default. > > Nevermind, I see hp = x, sp = y now. By the way, is_animated is > 0, as copied from pit.arc. I don't know what that > > Also note that now the console gives: > > [Error] Object lacks animation. > [Error] arch manhole_closed_3a > > I'm not sure the change is made in svn is correct. is_animated > is 0 because it is not continually animated but triggered (I > think, and going by pit.arc). > > The error message goes away if I put is_animated 1 in the arch, > even though pit arc doesn't use it that way, but the animation > still doesn't work. > > I've committed an update to the world_105_115.patch and to the > arch files to better explain the different cases. There are > six examples now. None of them work correctly even though 4 > of them have a functioning animation. > > Kevin Actually, now I'm positive the change committed to svn is not correct. If you trigger the animation when is_animated is 1 to avoid the error message, and if you stand on the manhole, it is continually animated even though the view in the map window is not. Kevin From nicolas.weeger at laposte.net Sun Jan 6 03:14:27 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 6 Jan 2008 10:14:27 +0100 Subject: [crossfire] New manhole archetype WIP (accepting help) In-Reply-To: <200801052144.17168.kbulgrien@worldnet.att.net> References: <200712291024.39359.kbulgrien@worldnet.att.net> <200801052315.27551.nicolas.weeger@laposte.net> <200801052144.17168.kbulgrien@worldnet.att.net> Message-ID: <200801061014.35105.nicolas.weeger@laposte.net> > Thanks... the animation was already "working" with the arch > "tweaked" so the faces of the non-head parts were blank as > noted in the README, but the hole didn't line up with the > arch "head". I do not see a change in behavior. Yes, I did > update. Maybe I should set up the test to show the various > test cases I've tried and more explicitly note in the map > what is wrong with each. Err, unless I'm totally mistaken, with my changes to server and arch, the behaviour is/was exactly as I'd expect it for the "opened" arch O.o (the "closed" arch had a superfluous "is_animated 1", but removing it fixes the issue). Opening/closing animation happens correctly when applying the lever. Only the "head" spot is a hole and will teleport the player, though, which seems coherent with the graphics. No issue when player steps on trap, even while opening or closing. No error in SVN as far as I can see. The "More" parts must have the same pic, else the animation code doesn't work as expected. But it doesn't matter, at least on my setup, the pics are all correct. So what didn't work to make you want to change the arch again?? :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080106/e2530d4e/attachment.pgp From mwedel at sonic.net Sun Jan 6 20:48:16 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 06 Jan 2008 18:48:16 -0800 Subject: [crossfire] Balance changes In-Reply-To: <200801041049.54630.juhaj@iki.fi> References: <477882EC.1090704@sonic.net> <200801030912.35935.nicolas.weeger@laposte.net> <477DD892.8050607@sonic.net> <200801041049.54630.juhaj@iki.fi> Message-ID: <478192F0.4030701@sonic.net> Juha J?ykk? wrote: > > This certainly has been an issue - both with alchemy and other item creation > skills as well. (I will use alchemy as a synonym to item creation skill.) > Basically, an arrow of slaying X should be equally difficult to create as > actually going to kill X. Of course, some characters will have easier time > killing X than others (follower of gaea killing a dread is probably having a > lot easier task than someone else), so the best situation would be where > creating Y of slaying X is easy for a character who would have a hard time > killing X and not so easy for others. That would be difficult to do, though. I'm not sure if creating an arrow of killing X should be as difficult as actually killing X himself. A good argument could be made that creating the item should be easier - this now perhaps adds some incentive/value to making items. Killing X is difficult, but I can make an item that makes it easier. But the other part of it is that difficulty should be tied to exp reward to a great extent. For example, if one was able to create arrows of slaying hill giant easily, then the exp reward for making those items should be fairly low. If creating arrows of slaying orcs is really hard, it should be worth more exp. Now from a game perspective, the above scenario doesn't make much sense - making arrows of slaying orcs should be easier than arrows of slaying hill giants. But in the end, arrows of slaying X tend to require a body part from X - that is the main part that makes it difficult, but also is quite reasonable. The balancing part of this in terms of alchemy is the actual exp reward, and risk of failure. For example, if you go out and kill a hill giant, the risk of failure in that case is the character may die. However, for alchemy, the effects of failure are random - cauldron may blow up, you may take some damage, but typically character won't be killed. A possible way to balance this is long term (say 30-60 minute real time) penalty on the character - for example, character fails in alchemy, and it results in his mind being muddle so he can't attempt alchemy for 30 minutes (or gets an appropriate potion or high level spell cast) That tends to balance the timing and reward cycle. Fighters can relatively safely gain levels all they want if they stick to easy monsters (relative to their level) - the disadvantage of doing that is it takes quite a bit longer. Balancing alchemy can be done in the same way - that really complex recipe gets you a lot of exp, such that if you do it 5 times successfully, that may get you enough exp to gain a level. However, each attempt only has a 50% chance of success, and on failure, there is a 50% chance you can not do alchemy for 30 minutes - that effectively limits the rate you can go up in levels in alchemy, or the character can stick with safer recipes (say 90% success rate, minimal chance for a long term penalty, but needs to perform 100 of them to gain a level, etc. >> Just doing damage/range gains per level may be workable with the revised >> monsters. In the past, that didn't work when a first level monster had 20 >> hp and the level 20 monster had 2000 - there just wasn't any good way to >> scale up the damage on the spell properly. But it is probably too early to >> really say if that is the case. > > There is an infinite amount of functions to choose from. There *is* a suitable > function to scale up the damage no matter how the monsters' HP scale. The > question is how to figure out the correct function... That's really not a true statement. If I have a sequence of 1,2,8,12,20,25,35,60,100,120, can you find a _reasonable_ function that results in that progression? Now sure, that may not be a real world case, but if the function amounts to a lookup table, or has a dozen possible input parameters to get that output, it is a meaningless function as far as this discussion is concerned. The real problem with an overly complex function is that it can be very difficult to tune later on - changing one of the input parameters may result in output radically different, making it very difficult to tune. If the function has to be rewritten to adjust the damage, then it is worthless for our purpose IMO. We want a simple function whose output is easily understood and can be adjusted within the archetypes. > >> But the other issue with different versions is a mix of area vs damage. > > Is this really so hard? Can't we just say that a spell with maximum inflicted > damage (on stationary targets) of X hit points costs f(X) mana points? That > way, a bullet which hits a single target and has maximum damage X, costs > f(X); a bolt which has maximum damage Y per square and envelops N squares, > costs f(Y*N) etc. That would be quite fair and it would really discourage the > use of area effect spells against individual targets (although that is the > player's choice, not something we want to prevent). Sure, you could do that, and everyone would use a spell that hits a single target for a bunch of damage, as that would almost always be most effective at higher levels. It makes doing the spells easy - just remove the cone, exploding ball, and most other spells because they would not be as effective. The only time a cone would inflict the same overall amount of damage is if every space the cone may hit as a monster in it - that seldom happens - there are often empty spaces, walls, monsters that may be resistant to that attacktype type, etc. So to make cones more worthwhile, you'd want to give some amount of reduction in mana cost, on the basis the spell would seldom be 100% effective. The only downside to a bullet that does a bunch of damage is you can't hit a bunch of targets with it - that tends to be less an issue at high level, simply because monsters are bigger (so there are not a bunch of targets in the same area), and it is more clear cut of what specific target you want to hit. > >> The harder part IMO is trying to sort that out on the server side. It is >> fairly straight forward to say 'a fireball of radius=3, base damage=20, >> duration=5 cost X sp' and 'a fireball of radius=6, base damage=10, >> duration=6 costs y SP' an balance out those SP or other values. > > Could we not use small/medium/large balls/bolts/cones for this? It would be > less flexible, but easier for players. The damage could scale the same way, > but damage/area would be less for the large versions than medium than small. > Total (maximum) damage would be the same. Even if we let players specify the > kind of spell they want (which is, btw, a nice touch, I think!) the above > mentioned f(X) -method of figuring out the sp cost should work fine. That has several issues. For example, lets suppose as a 10th level caster, I can put 100 damage into the spell. If a small cone spreads it out so that each space takes 10 damage, but the large one (double size of small) spreads it out so each space takes 5 damage, that makes the large one relatively meaningless unless you're fighting mice. And as per my note above, you probably want to give increased effect or decrease in effecting cast for the large one, as it is most likely that even more of the potential spaces it hits it will note damage, either because of no monster or walls (and in fact, a set of walls could greatly diminish the effect of the large one) The other problem is that if the caster puts that into a bullet, you really can't allow a 100 point bullet that hits a single space - it becomes too deadly, both for monsters, and for other players that may step in front of it. Or for that matter, when monsters cast that spell at players - after all, monsters use the same spell casting logic. Also, I believe it was Ryo who noted he would prefer for there not to be large, medium, and small versions of a spell, but rather just a general 'fire cone' 'ice cone', type of spells which damage can be modulated by the player. I'm thinking that as a first pass of rebalancing spells, things are done as now, with static spells defined. Dynamic spell generation (or creation) is hardly a requirement for a balanced spell casting system - it is certainly something we can discuss, but I'm not sure it has a simple answer. But as a quick thought, one could certainly come up with general parameters for custom spell creation. For example, something like: bullet: damage is *0.5, spell cost normal bolt: damage is *1.25/range (min range=5), spell cost normal cone: damage is *.75/range (min range=4), spell cost normal. Range in this context is number of spaces cone extends So as a simple example, a 10th level caster is allowed a 100 point damage spell at cost of 10 mana. A bullet does 50 damage, costs 10 mana. A bolt (that hits 5 spaces) does 25 damage/space (125/5), costs 10 mana a cone that extends 5 spaces does 15 damage/space. Note I think a 5 range cone hits a potential of 15 spaces That certainly needs tuning, but something like that is less clear cut what the best spell is. If you are just hitting a single create, that bullet is best. But if you can get a creatures in 2 of the 5 spaces of the bolt range, it is equal, and 3+ spaces, bolt is effectively better. For the cone, you need 3+ spaces - if there are lots of monsters about, you'll get that. To me, something like that looks more balanced and worthwhile. At higher levels, I could still see using bullets, bolts, and cones, depending on how the monsters are on the map, how tough, etc but if the bullet always did 50, and a 5 space bolt did 10 points/space, and a 5 range cone (15 spaces) did 3 points/space, I don't think I'd ever use cone or bolt - 3 points/space is pretty much meaningless if I'm 10th level. >> Traps need to be retuned for higher HP. > > Can't we just bind trap damage to dungeon level? If a 1st level player enters > a 50th level dungeon, he is expected to die - it does not matter if it's a > monster or a trap that kills him. This would solve the problem that traps are > either harmless to higher level characters or immediate death to lower level > ones. It is tuned to some extent, but dungeon difficulty != player level. I can't think of may dungeons with a high difficulty. I think the tuning needs to be improved, because I think at higher levels, it doesn't keep pace, so a trap is never really deadly. > >> What would probably be good to add to crossfire, especially for traps, is >> some idea of bleeding wounds. > > Could this not be done with a new type of disease? You don't need a disease to do a bleeding wound - any force object with negative hp I think would cause damage (it would be very simple to make it do that). The problem with diseases is that players can become immune to them, and if it was a disease, then a cure disease spell would end the damage, which isn't quite right in this context - if I have a severe cut, you don't take antibiotics to heal it, instead you get stitches. Adding bleeding wounds would be trivially easy - the slightly harder part in it is linking it in with the traps. Or maybe it just gets linked in with all damage that has a physical attacktype For example, character has 100 max hp. Any physical attack that does more than say half characters maxhp results in character taking half maxhp right then, and the remainder done over 100 ticks. So lets say character has 75 out of 100 hp. He fails to disarm a trap that does 150 damage. He takes 50 right now, leaving him at 25, and the remaining 100 damage is dealt over the next 100 ticks, or in this case, 1 damage/tick. It means the character has 25 ticks to do some sort of healing. Maybe the level of the healing has to be greater than level of bleeding wound, so if the trap was say 5th level, a 5th level or high spell would stop the bleeding right there. However, our hapless character only has a level 3 wand. He can keep healing himself to keep alive, and eventually (100 ticks), the wound will close on its own. But if the character has no healing ability what so ever, he dies - but in this example, at least he has some ways to try and survive - its better than that trap just killing him outright. From crossfire at ailesse.com Sat Jan 12 11:18:40 2008 From: crossfire at ailesse.com (Lauwenmark Akkendrittae) Date: Sat, 12 Jan 2008 18:18:40 +0100 Subject: [crossfire] Client and Editor packages Message-ID: <200801121818.49273.crossfire@ailesse.com> Hi, Just a short note to tell you that Debian and Yum packages for daily builds of the Gridarta Editor (Crossfire version) and JXClient are now available. The version number used is "1.0-", followed by a revision number equal to the SVN commit the packages were made from. For Apt users, add the following to your /etc/apt/sources.list: deb http://crossfire.ailesse.com/debian binary/ For Yum users, a repo file is available at: http://crossfire.ailesse.com/yum_crossfire.repo The package names are crossfire-editor-java and crossfire-client-java. The Debian packages depend on sun-java6-jre. Don't forget - those are quite experimental packages ! **** X.org 1.4 users may get difficulties running the Java client in fullscreen mode, due to changes in X.org that are not compatible with Java6. Patching the libmawt.so file shipped with your java *may* solve the problem for you (it does for me, but of course I offer no guarantee). Patch it using: sed -i 's/XINERAMA/FAKEEXTN/g' libmawt.so That's all folks ! -- Lauwenmark. ------------ "Drive defensively: buy a tank." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080112/87c8f25b/attachment.pgp From nicolas.weeger at laposte.net Sun Jan 13 01:31:07 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 13 Jan 2008 08:31:07 +0100 Subject: [crossfire] Client and Editor packages In-Reply-To: <200801121818.49273.crossfire@ailesse.com> References: <200801121818.49273.crossfire@ailesse.com> Message-ID: <200801130831.13059.nicolas.weeger@laposte.net> > Just a short note to tell you that Debian and Yum packages for daily builds > of the Gridarta Editor (Crossfire version) and JXClient are now available. > The version number used is "1.0-", followed by a revision number equal to > the SVN commit the packages were made from. Nifty, thanks for those users :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080113/2e1f00c4/attachment.pgp From agschult at ucalgary.ca Fri Jan 18 14:31:50 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Fri, 18 Jan 2008 13:31:50 -0700 Subject: [crossfire] Potions of Life Message-ID: <20080118133150.5986d22a@alzerion> Hi, Recently after some discussion in IRC with both players and other developers, it was pointed out while it's kind of good that there are multiple levels of potions of life, they don't solve the issue of depletion being quite harsh and difficult to recover from for newbies. In order to deal with this, I'm planning to soon re-balance potions of life by adjusting their costs, level limits, and how often different ones appear in treasure lists. I'm thinking of making the level limits as follows: up to 20, up to 40, up to 105, and then unlimited With pricing in shops along the following lines: 5pp, 40pp, 300pp, and then the last only being obtainable from alchemy and treasure. In addition, I'm thinking of making either: 1) Up to level 5 or 10 unaffected by stat depletion at death or 2) A NPC in the house of healing which can give free healing of stat depletion to characters up to about level 5 or 10. Any comments/objections/suggestions on this plan? Alex Schultz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080118/c94ee165/attachment.pgp From leaf at real-time.com Fri Jan 18 15:09:09 2008 From: leaf at real-time.com (Rick Tanner) Date: Fri, 18 Jan 2008 15:09:09 -0600 Subject: [crossfire] Potions of Life In-Reply-To: <20080118133150.5986d22a@alzerion> References: <20080118133150.5986d22a@alzerion> Message-ID: <47911575.4050804@real-time.com> > In order to deal with this, I'm planning to soon re-balance potions of > life by adjusting their costs, level limits, and how often different > ones appear in treasure lists. I'm thinking of making the level limits > as follows: > up to 20, up to 40, up to 105, and then unlimited I think there should be more of a level breakdown for the potions. Otherwise, I suspect, people in the 'teens levels will be cleaning out the newbie areas for the easy potions. I would propose something like this: Up to level 10, level 11-20, 21-40, 41-80, level 100+ > With pricing in shops along the following lines: > 5pp, 40pp, 300pp, and then the last only being obtainable from alchemy > and treasure. I think that pricing looks reasonable. Assuming the level breakdown I mentioned earlier, pricing like this: 5pp, 25pp, 625pp, 1000pp Okay, maybe not that sharp of an increase - it just seems that if there is a pattern or explanation for pricing structure, there is less confusion by players. > In addition, I'm thinking of making either: > 1) Up to level 5 or 10 unaffected by stat depletion at death If this is implemented, there should be some sort of post-death message (instead of the usual "You have Died! You have weaker, less healthy, et al.) indicating this information. And, then some sort of message display at level 6 or 11 letting them know that now when they die, they will be depleted and what they need to do to restore those lost stats. > or 2) A NPC in the house of healing which can give free healing of stat > depletion to characters up to about level 5 or 10. Hmm.. need more time to ponder & comment on this idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080118/7f8c0a0a/attachment.pgp From agschult at ucalgary.ca Fri Jan 18 16:21:15 2008 From: agschult at ucalgary.ca (Alex Schultz) Date: Fri, 18 Jan 2008 15:21:15 -0700 Subject: [crossfire] Potions of Life In-Reply-To: <47911575.4050804@real-time.com> References: <20080118133150.5986d22a@alzerion> <47911575.4050804@real-time.com> Message-ID: <20080118152115.096a87cf@alzerion> On Fri, 18 Jan 2008 15:09:09 -0600 Rick Tanner wrote: > > In order to deal with this, I'm planning to soon re-balance potions > > of life by adjusting their costs, level limits, and how often > > different ones appear in treasure lists. I'm thinking of making the > > level limits as follows: > > up to 20, up to 40, up to 105, and then unlimited > > I think there should be more of a level breakdown for the potions. > Otherwise, I suspect, people in the 'teens levels will be cleaning out > the newbie areas for the easy potions. > > I would propose something like this: > > Up to level 10, level 11-20, 21-40, 41-80, level 100+ Well, now you list 5 level groupings, not 4 as currently exists. Just to double check, was this an error or do you mean to suggest having 5 level groupings would be preferred? :) Currently we have: -minor potion of life -medium potion of life -major potion of life -supreme potion of life If we have another, where would be a good place to put it in the ranks? Perhaps "superior potion of life" just below supreme? Another thought is, perhaps left clicking a potion of life, should tell the player what level it's effective up to? > > With pricing in shops along the following lines: > > 5pp, 40pp, 300pp, and then the last only being obtainable from > > alchemy and treasure. > > I think that pricing looks reasonable. > > Assuming the level breakdown I mentioned earlier, pricing like this: > > 5pp, 25pp, 625pp, 1000pp > > Okay, maybe not that sharp of an increase - it just seems that if > there is a pattern or explanation for pricing structure, there is less > confusion by players. That pattern also seems fairly reasonable to me presuming that level breakdown. Alex Schultz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080118/85cef1f6/attachment.pgp From leaf at real-time.com Fri Jan 18 16:44:07 2008 From: leaf at real-time.com (Rick Tanner) Date: Fri, 18 Jan 2008 16:44:07 -0600 Subject: [crossfire] Potions of Life In-Reply-To: <20080118152115.096a87cf@alzerion> References: <20080118133150.5986d22a@alzerion> <47911575.4050804@real-time.com> <20080118152115.096a87cf@alzerion> Message-ID: <47912BB7.3030605@real-time.com> >> I would propose something like this: >> >> Up to level 10, level 11-20, 21-40, 41-80, level 100+ > > Well, now you list 5 level groupings, not 4 as currently exists. Just > to double check, was this an error or do you mean to suggest having 5 > level groupings would be preferred? :) Didn't realize I listed 5 when there is only 4 in place right now. > Currently we have: > -minor potion of life > -medium potion of life > -major potion of life > -supreme potion of life > If we have another, where would be a good place to put it in the ranks? > Perhaps "superior potion of life" just below supreme? Yeah.. (I know.. pushing creative limits on this..) Or add one to the top of the list, for instance: lesser potion of life Another name to consider for something in the middle: greater potion of life > Another thought is, perhaps left clicking a potion of life, should tell > the player what level it's effective up to? Yes, use the lore fields! =-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080118/754bb606/attachment.pgp From mwedel at sonic.net Fri Jan 18 22:16:13 2008 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 18 Jan 2008 20:16:13 -0800 Subject: [crossfire] Potions of Life In-Reply-To: <47912BB7.3030605@real-time.com> References: <20080118133150.5986d22a@alzerion> <47911575.4050804@real-time.com> <20080118152115.096a87cf@alzerion> <47912BB7.3030605@real-time.com> Message-ID: <4791798D.3060900@sonic.net> Quick thoughts: Not having any stat depletion until level 5 or so seems quite reasonable. The cost of lost exp is likely a big enough penalty. If that is done, then I'm not sure of need/reason of npc that restores depletion. If so, maybe pricing like 5-10 50 pp 11-20 250 pp 21-40 1000 pp 41-80 5000 pp 80+ 25000 pp Bit extreme? Don't know - I always here about players at higher level having gobs of money, so 25k pp probably isn't much. I actually don't think these costs at any of these levels is actually all that difficult- 50 pp at levels 5-10 isn't that hard, same for the 250 pp, etc. Having the examine option tell the level of the potion makes perfect sense. I also think a goodly supply of all of these should be available in the house of healing - sure, those could get cleared out, but in general, one should be able to buy these (one note being, maybe the higher level ones are not available in the scorn house of healing, but rather the higher level towns). It'd also perhaps be interesting to give restoration to certain gods (gaea?) and let players restore other players. To limit this, the caster level is effectively the same as restoration level, so you wouldn't be able to restore stat death from your own death, at least not until you regained the levels. One could also make it some ratio, like effective level is 75%, thus, a level 50 praying skill restores death loss up to level 37. From kbulgrien at worldnet.att.net Sat Jan 19 01:49:06 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sat, 19 Jan 2008 01:49:06 -0600 Subject: [crossfire] FYI: Libglade client saved window positions now restore properly. Message-ID: <200801190149.06332.kbulgrien@worldnet.att.net> This is a general notice that the bug that prevented saved window positions from being restored when the libglade (GTK V2 on trunk) client starts up. The fix was applied with SVN revision 8204. This was a .glade file update only. No code changed, so you could browse to < http://crossfire.svn.sourceforge.net/viewvc/crossfire/client/trunk/gtk-v2/glade/ > to snag an update of your favorite .glade file. Enjoy, Kevin Bulgrien From mwedel at sonic.net Sat Jan 19 02:03:54 2008 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 19 Jan 2008 00:03:54 -0800 Subject: [crossfire] Reminder: Release 1.11 forthcoming Message-ID: <4791AEEA.7000309@sonic.net> I delayed the 1.11 release a little to give the stringbuffer changes a little time to soak in. Those look good. So in all likelihood, I'll be packing up a 1.11 release sometime soon - maybe even as soon as this Sunday (1/20), so just a heads up. From kbulgrien at worldnet.att.net Sun Jan 20 12:29:01 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Sun, 20 Jan 2008 12:29:01 -0600 Subject: [crossfire] Recent trunk server changes affect scrolls? Message-ID: <200801201229.01562.kbulgrien@worldnet.att.net> A level 4 fenx tried to use three lvl 8 scrolls (after making sure they were not cursed on a detect curse altar). No items were identified. No messages were output to indicate spell failure... Something seems broken. Anybody else seeing this kind of thing? Was playing on ailesse which is advertising 2.0-dev-r8210. Kevin From kbulgrien at worldnet.att.net Mon Jan 21 00:53:24 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 21 Jan 2008 00:53:24 -0600 Subject: [crossfire] Reminder: Release 1.11 forthcoming In-Reply-To: <4791AEEA.7000309@sonic.net> References: <4791AEEA.7000309@sonic.net> Message-ID: <200801210053.24513.kbulgrien@worldnet.att.net> > I delayed the 1.11 release a little to give the stringbuffer changes a > little time to soak in. Those look good. > > So in all likelihood, I'll be packing up a 1.11 release sometime soon - > maybe even as soon as this Sunday (1/20), so just a heads up. I'd really be interested in getting one more patch into the GTK V2 client before the release. I just made a modification that seems to fix all of the problems listed in "[ 1527973 ] bind command does not work" < http://sourceforge.net/tracker/index.php?func=detail&aid=1527973&group_id=13833&atid=113833 > The only thing is, it is late, and I haven't probably tested it hard enough, but need to hit the sack as it is work tomorrow. I'd like a bit more time to bang on it before committing. Keybinding in the client is very broken, so I think this maybe worth waiting on since it looks like I have something viable. I am positive it is an improvement even if it isn't perfect. So far the Keybinding Modifier checkboxes all behave consistently unlike the current behavior. The new code changes the logic of the checkboxes on the keybinding dialog. The existing logic is broken and somewhat inconsistent in implementation. The new behavior is if no Run/Fire/Alt/Meta checkboxes are checked, KEYF_NORMAL is assumed (mode N). But, if all Run/Fire/Alt/Meta are checked, KEYF_MODIFIERS is assumed (mode A). So far it seems like it works. I just have not tested interaction with the command-line bind/unbind extensively, but enough to think I can close #1527973. I'd also want to check to see if it fixes [ 1839894 ] Keybind editor flaw (gtk2, gtkv2) But even if not, it is a far sight better than the current code. Kevin From subs at eracc.com Mon Jan 21 08:06:47 2008 From: subs at eracc.com (ERACC Subscriptions) Date: Mon, 21 Jan 2008 08:06:47 -0600 Subject: [crossfire] Reminder: Release 1.11 forthcoming In-Reply-To: <200801210053.24513.kbulgrien@worldnet.att.net> References: <4791AEEA.7000309@sonic.net> <200801210053.24513.kbulgrien@worldnet.att.net> Message-ID: <200801210806.48698.subs@eracc.com> On Monday 21 January 2008 Kevin R. Bulgrien wrote: > I'd also want to check to see if it fixes [ 1839894 ] Keybind editor > flaw (gtk2, gtkv2) Since I submitted that and you are working on resolving the problem I made a change in Tracker and updated with you as the "Assigned To" guy. I will attempt to get a new build of the GTKv2 client and help test if I can get some time to do so in the next day or so (or before 1.11 is released, whichever comes first). Gene Alexander -- ERA Computers & Consulting Preloaded computers - eComStation, Linux and Unix Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From kbulgrien at worldnet.att.net Mon Jan 21 21:39:40 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Mon, 21 Jan 2008 21:39:40 -0600 Subject: [crossfire] Reminder: Release 1.11 forthcoming In-Reply-To: <200801210806.48698.subs@eracc.com> References: <4791AEEA.7000309@sonic.net> <200801210053.24513.kbulgrien@worldnet.att.net> <200801210806.48698.subs@eracc.com> Message-ID: <200801212139.40605.kbulgrien@worldnet.att.net> > > I'd also want to check to see if it fixes [ 1839894 ] Keybind editor > > flaw (gtk2, gtkv2) > > Since I submitted that and you are working on resolving the problem I made > a change in Tracker and updated with you as the "Assigned To" guy. I will > attempt to get a new build of the GTKv2 client and help test if I can get > some time to do so in the next day or so (or before 1.11 is released, > whichever comes first). > > Gene Alexander Unfortunately this patch does not address your issue with the Update Binding button. I'll keep at it though. I did commit the fixes and marked the other tracker as Pending. I really think it can be closed, but figured I'd let the OP decide. I checked the GUI keybinding dialog for consistency with the keys file and bind commands. Everything seems right (except that due to your bug, the updated bindings don't actually work. This is more a technical issue with data structures in the client than with the binding process itself as the keys file is updated properly. Maybe I can figure it out fast enough to slip it in before the release too? Hopefully it isn't too bad to figure out. Kevin Bulgrien From kbulgrien at worldnet.att.net Tue Jan 22 00:26:46 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 22 Jan 2008 00:26:46 -0600 Subject: [crossfire] Reminder: Release 1.11 forthcoming In-Reply-To: <200801210053.24513.kbulgrien@worldnet.att.net> References: <4791AEEA.7000309@sonic.net> <200801210053.24513.kbulgrien@worldnet.att.net> Message-ID: <200801220026.46365.kbulgrien@worldnet.att.net> On Monday 21 January 2008 00:53, Kevin R. Bulgrien wrote: > > I delayed the 1.11 release a little to give the stringbuffer changes a > > little time to soak in. Those look good. > > > > So in all likelihood, I'll be packing up a 1.11 release sometime soon - > > maybe even as soon as this Sunday (1/20), so just a heads up. > > I'd really be interested in getting one more patch into the GTK V2 client > before the release. I just made a modification that seems to fix all of > the problems listed in "[ 1527973 ] bind command does not work" > > < > http://sourceforge.net/tracker/index.php?func=detail&aid=1527973&group_id=1 >3833&atid=113833 > > > The only thing is, it is late, and I haven't probably tested it hard > enough, but need to hit the sack as it is work tomorrow. I'd like a > bit more time to bang on it before committing. Keybinding in the > client is very broken, so I think this maybe worth waiting on since > it looks like I have something viable. > > I am positive it is an improvement even if it isn't perfect. So far > the Keybinding Modifier checkboxes all behave consistently unlike > the current behavior. > > The new code changes the logic of the checkboxes on the keybinding > dialog. The existing logic is broken and somewhat inconsistent > in implementation. The new behavior is if no Run/Fire/Alt/Meta > checkboxes are checked, KEYF_NORMAL is assumed (mode N). But, > if all Run/Fire/Alt/Meta are checked, KEYF_MODIFIERS is assumed > (mode A). > > So far it seems like it works. I just have not tested interaction > with the command-line bind/unbind extensively, but enough to think > I can close #1527973. > > I'd also want to check to see if it fixes [ 1839894 ] Keybind editor > flaw (gtk2, gtkv2) > > But even if not, it is a far sight better than the current code. > > Kevin SVN revision 8247 does seem to have also fixed [ 1839894 ] Keybind editor > flaw (gtk2, gtkv2). I am marking it as pending. Testing shows Update Binding does work after all. The caveat is that if you have multiple bindings to the same key, things can behave somewhat unexpectedly if you aren't careful. Say a key is bound separately for normal, run, fire, meta, alt, then is bound A. It will not be possible to get the last binding because one of the others will trigger first. In my case, I thought it wasn't working at first because my keys file had conflicting entries. Marking this as pending to close the issue technically speaking because the description is no longer applicable in my opinion. Whether the keybinding code is too simple because it is possible to get into situations like this is another issue, but, considering the keys file is manually editable, whether it is worth doing any more work on it is debateable. So, Mark, I believe I'm clear on work to go in before the update if the libglade client is released instead of the branch revision. I haven't put my edits down on branch yet. I'll check and fix branch - maybe tomorrow? Gene, and others, feel free to test trunk keybinding and report back. Kevin Bulgrien From mwedel at sonic.net Tue Jan 22 00:50:27 2008 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 21 Jan 2008 22:50:27 -0800 Subject: [crossfire] Recent trunk server changes affect scrolls? In-Reply-To: <200801201229.01562.kbulgrien@worldnet.att.net> References: <200801201229.01562.kbulgrien@worldnet.att.net> Message-ID: <47959233.6030101@sonic.net> Kevin R. Bulgrien wrote: > A level 4 fenx tried to use three lvl 8 scrolls (after making sure they > were not cursed on a detect curse altar). No items were identified. > No messages were output to indicate spell failure... > > Something seems broken. Anybody else seeing this kind of thing? > > Was playing on ailesse which is advertising 2.0-dev-r8210. As far as I recall seeing, I don't think there has been anything that should affect scrolls. From kbulgrien at worldnet.att.net Tue Jan 22 07:48:36 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Tue, 22 Jan 2008 07:48:36 -0600 Subject: [crossfire] Reminder: Release 1.11 forthcoming (On GTK V2 Client) In-Reply-To: <200801212139.40605.kbulgrien@worldnet.att.net> References: <4791AEEA.7000309@sonic.net> <200801210806.48698.subs@eracc.com> <200801212139.40605.kbulgrien@worldnet.att.net> Message-ID: <200801220748.36383.kbulgrien@worldnet.att.net> After sleeping on it... I really want to push for a LibGlade client release. I've killed some big bugs. With the recent murmurs of dual text in the clients, I think it only fair to mention that I'm not at all interested in debugging the branch GTK V2 client. We have people actively using the trunk LibGlade. I've got way too much time in the new one to start maintaining dinosaurs. I don't care if we have to copy it down to branch to keep versions of the client equivalent with the server. Please consider this thoughtfully. Kevin Bulgrien From mwedel at sonic.net Wed Jan 23 01:32:05 2008 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 Jan 2008 23:32:05 -0800 Subject: [crossfire] Reminder: Release 1.11 forthcoming (On GTK V2 Client) In-Reply-To: <200801220748.36383.kbulgrien@worldnet.att.net> References: <4791AEEA.7000309@sonic.net> <200801210806.48698.subs@eracc.com> <200801212139.40605.kbulgrien@worldnet.att.net> <200801220748.36383.kbulgrien@worldnet.att.net> Message-ID: <4796ED75.8070404@sonic.net> Kevin R. Bulgrien wrote: > After sleeping on it... I really want to push for a LibGlade client > release. I've killed some big bugs. With the recent murmurs of dual > text in the clients, I think it only fair to mention that I'm not at > all interested in debugging the branch GTK V2 client. We have people > actively using the trunk LibGlade. I've got way too much time in the > new one to start maintaining dinosaurs. > > I don't care if we have to copy it down to branch to keep versions of > the client equivalent with the server. Please consider this > thoughtfully. By its very nature, a 1.11 release would come from the stable branch, and not from the trunk. There are several possible things that could be done: 1) Backport libglade changes to 1.11 release. If that is done, it almost makes more sense to just make a copy of what is currently the trunk client and call that the stable and 1.11 release (probably easier, and I'm not sure of any unique changes in the trunk right now). Note that going forward, that may not be true - point of trunk client is to be able to make changes, etc, without having to worry about backwards compatibility - it just has to be compatible with the trunk server. 2) Make the 1.11 client release from the branch client, and also do a snapshot release of the trunk client. That's just extra work. 3) Just do a 1.11 client release - folks wanting to use the trunk could still get it from SVN. As an aside, has the rpmspec been updated for the libglade changes? Do we care about RPM's? From kbulgrien at worldnet.att.net Wed Jan 23 07:53:05 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 23 Jan 2008 07:53:05 -0600 Subject: [crossfire] =?iso-8859-1?q?Reminder=3A_Release_1=2E11_forthcoming?= =?iso-8859-1?q?_=28On_GTK_V2=09Client_=29?= In-Reply-To: <4796ED75.8070404@sonic.net> References: <4791AEEA.7000309@sonic.net> <200801220748.36383.kbulgrien@worldnet.att.net> <4796ED75.8070404@sonic.net> Message-ID: <200801230753.05481.kbulgrien@worldnet.att.net> > > I don't care if we have to copy it down to branch to keep versions of > > the client equivalent with the server. Please consider this > > thoughtfully. > > By its very nature, a 1.11 release would come from the stable branch, and > not from the trunk. The version of a client may not need to track the server, though as it is a tradition, I'll not push against that. > There are several possible things that could be done: > 1) Backport libglade changes to 1.11 release. If that is done, it almost > makes more sense to just make a copy of what is currently the trunk client > and call that the stable and 1.11 release (probably easier, and I'm not > sure of any unique changes in the trunk right now). Note that going > forward, that may not be true - point of trunk client is to be able to make > changes, etc, without having to worry about backwards compatibility - it > just has to be compatible with the trunk server. No backporting. I already looked at it. The two codebases are too far apart. People have been featuring trunk and not branch, so the merge down would be a terrible amount of effort to pare out things that are not incompatible with branch nor unstable. Trunk is stable at the moment, and I know of no reason the trunk client shouldn't be treated as "the client" for the branch. If it must be 1.11, then copying it down is the way to get back to a common base. Besides, without more distribution, there will not be as much feedback on how to improve it, so it will mostly stay a toy for a few - which is not a good thing in my opinion. > 2) Make the 1.11 client release from the branch client, and also do a > snapshot release of the trunk client. That's just extra work. > > 3) Just do a 1.11 client release - folks wanting to use the trunk could > still get it from SVN. Branch GTK V2 is not a people's client and picks no bones about saying so in the README. I think that not releasing the improvements would be a travesty. I did the work to put GTK V2 into people's hands who would not previously consider it - myself included. I've decided to jump over and make it what it should be rather than just complain about it. > As an aside, has the rpmspec been updated for the libglade changes? Do > we care about RPM's? No, I don't recall seeing an rpmspec in the client, but now that you ask, I see it. I'll look into updating it. Kevin From kbulgrien at worldnet.att.net Wed Jan 23 22:50:42 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 23 Jan 2008 22:50:42 -0600 Subject: [crossfire] =?iso-8859-1?q?Reminder=3A_Release_1=2E11_forthcoming?= =?iso-8859-1?q?_=28On_GTK_V2=09Client_=29?= In-Reply-To: <200801230753.05481.kbulgrien@worldnet.att.net> References: <4791AEEA.7000309@sonic.net> <4796ED75.8070404@sonic.net> <200801230753.05481.kbulgrien@worldnet.att.net> Message-ID: <200801232250.42623.kbulgrien@worldnet.att.net> > Branch GTK V2 is not a people's client and picks no bones about saying > so in the README. I think that not releasing the improvements would be > a travesty. I did the work to put GTK V2 into people's hands who would > not previously consider it - myself included. I've decided to jump over > and make it what it should be rather than just complain about it. > > > As an aside, has the rpmspec been updated for the libglade changes? Do > > we care about RPM's? > > No, I don't recall seeing an rpmspec in the client, but now that you ask, > I see it. I'll look into updating it. Ok, granted, the above is a bit overstated, but I still feel that to keep this client on trunk for another year is not really good for Crossfire, especially when you consider the distribution lag that occurs since they do not pick up new packages for a while. Some distributions will be picking up new packages within 6 months or so. We really need to have an upgraded client out as soon as we can. I really do not see the GTK-V2 as released as helping the user base much. Maybe nobody cares with jxclient up and coming... but I think this client still has a place in the lineup. I started working on the packaging tonight. In the process I stumbled on the man pages, etc... I guess I see some linkages between the three clients here that I had not taken into consideration before. I don't think that has to preclude a release for this client, but it does actually shine some light on a change that went down to branch that I should fix up regarding the image cache directory. It would be awkward to release those clients when they do not all use the same directory. That's my bad. Also, the packaging for trunk has name changes (albeit not fully converted) for the binaries, man pages, etc., so I guess it will take a bit more work to pull it down to branch than I initially thought. I suppose if the release is impending, that this work will just be annoying to the releaser. I'll live with it not going in this time around if it needs to be that way, but it makes me not feel so good. I guess I can spend the time putting some polish on the packaging in the mean time. On the other hand, if there is desire to work this in... I'd still appreciate the consideration. Kevin Bulgrien From kbulgrien at worldnet.att.net Wed Jan 23 23:19:55 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 23 Jan 2008 23:19:55 -0600 Subject: [crossfire] =?iso-8859-1?q?Reminder=3A_Release_1=2E11_forthcoming?= =?iso-8859-1?q?_=28On_GTK_V2=09Client_=29?= In-Reply-To: <200801232250.42623.kbulgrien@worldnet.att.net> References: <4791AEEA.7000309@sonic.net> <200801230753.05481.kbulgrien@worldnet.att.net> <200801232250.42623.kbulgrien@worldnet.att.net> Message-ID: <200801232319.55625.kbulgrien@worldnet.att.net> >I don't think that > has to preclude a release for this client, but it does actually shine some > light on a change that went down to branch that I should fix up regarding > the image cache directory. It would be awkward to release those clients > when they do not all use the same directory. That's my bad. False alarm. The change was in the common directory. Kevin Bulgrien From mwedel at sonic.net Wed Jan 23 23:30:42 2008 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 23 Jan 2008 21:30:42 -0800 Subject: [crossfire] Reminder: Release 1.11 forthcoming (On GTK V2 Client ) In-Reply-To: <200801232250.42623.kbulgrien@worldnet.att.net> References: <4791AEEA.7000309@sonic.net> <4796ED75.8070404@sonic.net> <200801230753.05481.kbulgrien@worldnet.att.net> <200801232250.42623.kbulgrien@worldnet.att.net> Message-ID: <47982282.80000@sonic.net> I basically agree that the new changes should be seen. But at some point, that also applies to other reas, like the server. In the case of the server, it would clearly need to be documented as alpha quality, and even questionable if code that is in flux should be released. Now the client code is stable, and as mentioned, no big changes have been made yet. But as I do think about it, I believe all the deprecated protocol stuff was removed from the trunk client, but not that stable client - I believe that does mean that the trunk client may not be playable on some very old servers. I'm not sure if there are any servers that old, and I think even if they are, no requirement that latest client should support them - if you want to play on an old server, use an old client. Right now I'm leaning to just releasing stable version of all the components now, and maybe do a snapshot release of the trunk client in a week or two when everything on it gets sorted out (packaging, etc) - there isn't any real reason that has to coincide with the stable release - and in fact, it may make more sense to do future snapshots if there are changes out there we want tested. That also gives us feedback on any issues before really committing the trunk client to be the stable client - it would be bad to make that commitment now, only to find out that there are some issues which really doesn't make it suitable for that right now. From kbulgrien at worldnet.att.net Thu Jan 24 22:40:49 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu, 24 Jan 2008 22:40:49 -0600 Subject: [crossfire] Reminder: Release 1.11 forthcoming (On GTK V2 Client ) In-Reply-To: <47982282.80000@sonic.net> References: <4791AEEA.7000309@sonic.net> <200801232250.42623.kbulgrien@worldnet.att.net> <47982282.80000@sonic.net> Message-ID: <200801242240.49313.kbulgrien@worldnet.att.net> > Right now I'm leaning to just releasing stable version of all the > components now, and maybe do a snapshot release of the trunk client in a > week or two when everything on it gets sorted out (packaging, etc) - there > isn't any real reason that has to coincide with the stable release - and in > fact, it may make more sense to do future snapshots if there are changes > out there we want tested. > > That also gives us feedback on any issues before really committing the > trunk client to be the stable client - it would be bad to make that > commitment now, only to find out that there are some issues which really > doesn't make it suitable for that right now. As the recent spate of commits illustrates, I think it ironic that the branch is being touted as stable. The volume of bug fixes on trunk that were not applied to branch was quite high. At some point it may be helpful to realize that the branch is freezing in a broken state. That was a lot of work when merging down trunk would have fixed it and would have brought in the new client. I did the work because I think a release means that due diligence was done to fix known issues. As it was, it wasn't, so to speak. I'd rather be doing something more productive to advance the project instead of prolong the life of a dead branch, but, I sort of did it in the interest of trying to go along with the above. I know I'm not the only one holding that view. Kevin From mwedel at sonic.net Fri Jan 25 00:34:02 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 24 Jan 2008 22:34:02 -0800 Subject: [crossfire] Reminder: Release 1.11 forthcoming (On GTK V2 Client ) In-Reply-To: <200801242240.49313.kbulgrien@worldnet.att.net> References: <4791AEEA.7000309@sonic.net> <200801232250.42623.kbulgrien@worldnet.att.net> <47982282.80000@sonic.net> <200801242240.49313.kbulgrien@worldnet.att.net> Message-ID: <479982DA.8050406@sonic.net> Kevin R. Bulgrien wrote: > As the recent spate of commits illustrates, I think it ironic that the > branch is being touted as stable. The volume of bug fixes on trunk that > were not applied to branch was quite high. At some point it may be helpful > to realize that the branch is freezing in a broken state. Thanks for all your work on backporting your changes. Clearly, something isn't working right in the process - bug fixes made to the trunk should be backported to the stable version. But I'm as guilty as anyone else for not doing it. But, this seems to work fine for the server - I haven't looked, but it seems bugfixes are backported more there. One reason could be the perception that the trunk client is the one that can/should be released, where that really isn't the case for the server (things are more in flux there with combat changes). In retrospect, it may have (and would be) better to treat the trunk client as the official & stable client, and branch from that for releases. If big changes are expected to be made, then perhaps do a branch before those changes to have an established stable version for release. But this does require more careful monitoring of changes made to the client to make sure something hasn't been changed that will make it unable to work against 1.x servers. The point of trunk was pretty clear - place to be able to make big changes without having to worry about breaking things in short term (or backwards compatibility long term) - I think that is clearly good. Some big changes, like making the client use libglade, was a big (and good) change, but I think in short term, was something that needed to be done apart from the stable branch. so I rambled a bit here without really saying much. I think it does make sense for what is currently trunk to become the 'new' stable branch, as lots of good changes have been made. I'm just not sure how things will keep in sync going forward so this doesn't happen again. From nicolas.weeger at laposte.net Sun Jan 27 02:11:31 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 27 Jan 2008 09:11:31 +0100 Subject: [crossfire] New plugin: citylife - help needed Message-ID: <200801270911.35887.nicolas.weeger@laposte.net> Hello. I just committed (to trunk) the first version of a plugin named "citylife" that aims to add NPCs to towns. Plugin is doxygen-documented for interested people. Basic summary: when a map is loaded, adds NPCs to random zones. When the map is in memory, will randomly spawn NPCs from predefined points (houses / shops). Behaviour is for now totally dumb, NPCs will just move around randomly. Plugin relies on spawn zones and points, and archetype list (to vary NPCs for regions). Help would be appreciated to define the spawn zones / points for various towns (only Scorn is done for now) :) (or improve the plugin! see the todo list, or use your imagination). Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080127/73bf7173/attachment.pgp From lalo.martins at gmail.com Mon Jan 28 05:39:42 2008 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 28 Jan 2008 11:39:42 +0000 (UTC) Subject: [crossfire] New plugin: citylife - help needed References: <200801270911.35887.nicolas.weeger@laposte.net> Message-ID: Also spracht Nicolas Weeger (Sun, 27 Jan 2008 09:11:31 +0100): > Hello. > > I just committed (to trunk) the first version of a plugin named > "citylife" that aims to add NPCs to towns. (...) > Behaviour is for now totally dumb, NPCs will just move around randomly. I don't know if you already know this, already use it, already plan to use it, whatever, but: Sim City (classic) has been just GPLed under the name "Micropolis", and the automata that runs the "sims" in the game is available as a library within the source tree. http://www.donhopkins.com/home/micropolis/ When that happened, one of the first things I thought was, how awesome it would be to use it to control NPCs in a game like Crossfire! best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Wed Jan 30 01:59:49 2008 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 29 Jan 2008 23:59:49 -0800 Subject: [crossfire] volunteer to build 32 bit RPMS Message-ID: <47A02E75.2060606@sonic.net> anyone out there want to build 32 bit RPMs of the client? It is really easy to do, but I don't have a 32 bit linux system anymore. I originally started building the RPM's because it was really easy and I already had the resources to do so. While I could set up the necessary environment to build the 32 bit binaries, that goes beyond the 'it is really easy'. If someone out there already has a 32 bit system that uses rpms, makes life easy. Or if you have such a system, don't want to build the binaries yourself, but want to give me access to build them, that is doable. But would be easier just for someone else to build them. Flip side is there isn't a huge number of folks downloading the rpm's (I see 975 downloads of crossfire-client-1.10.0-1.i386.rpm, but only 300 of the common package, of which that package depends on, so not sure how real that 975 number is. 7700 folks downloaded the source (tar.gz) package off sourcforge, so number of folks downloading rpm is a fairly small number. From subs at eracc.com Wed Jan 30 10:16:14 2008 From: subs at eracc.com (ERACC Subscriptions) Date: Wed, 30 Jan 2008 10:16:14 -0600 Subject: [crossfire] volunteer to build 32 bit RPMS In-Reply-To: <47A02E75.2060606@sonic.net> References: <47A02E75.2060606@sonic.net> Message-ID: <200801301016.15459.subs@eracc.com> On Wednesday 30 January 2008 Mark Wedel wrote: > anyone out there want to build 32 bit RPMs of the client? > > It is really easy to do, but I don't have a 32 bit linux system anymore. > I originally started building the RPM's because it was really easy and I > already had the resources to do so. > > While I could set up the necessary environment to build the 32 bit > binaries, that goes beyond the 'it is really easy'. If someone out there > already has a 32 bit system that uses rpms, makes life easy. > > Or if you have such a system, don't want to build the binaries yourself, > but want to give me access to build them, that is doable. But would be > easier just for someone else to build them. > > Flip side is there isn't a huge number of folks downloading the rpm's (I > see 975 downloads of crossfire-client-1.10.0-1.i386.rpm, but only 300 of > the common package, of which that package depends on, so not sure how real > that 975 number is. 7700 folks downloaded the source (tar.gz) package off > sourcforge, so number of folks downloading rpm is a fairly small number. Hi Mark, I could do this if you assist me with it. Or I can give you a shell on my 32-bit box. Whichever you prefer is fine with me. Send me a private e-mail about it (gene \a\t eracc \d\o\t com) or ping me on IRC. Gene Alexander -- ERA Computers & Consulting Preloaded computers - eComStation, Linux and Unix Voice messages: 1(731)256-0973 - FAX & Voice messages: 1(731)664-8524 [E-mail preferred. Please reply BELOW this line.] From nicolas.weeger at laposte.net Wed Jan 30 16:53:00 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 30 Jan 2008 23:53:00 +0100 Subject: [crossfire] Volunteer for Windows builds? Message-ID: <200801302353.04427.nicolas.weeger@laposte.net> Hello. Is there anyone willing to do binary builds for Windows for now on? I don't mind doing the .11 release, but I must say if someone else would like to do the next ones, I'll gladly let him/her handle things :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080130/017ea185/attachment.pgp From nicolas.weeger at laposte.net Wed Jan 30 16:59:22 2008 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 30 Jan 2008 23:59:22 +0100 Subject: [crossfire] Weather code Message-ID: <200801302359.22703.nicolas.weeger@laposte.net> Hello. Is anyone actually using the weather system? Or does anyone actually understand the aim it has? Or has any plan to improve it? I was pondering making that a plugin, or simply trashing it... Opinions? Thoughts? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080130/761c470c/attachment.pgp From leaf at real-time.com Wed Jan 30 17:35:57 2008 From: leaf at real-time.com (Rick Tanner) Date: Wed, 30 Jan 2008 17:35:57 -0600 Subject: [crossfire] Volunteer for Windows builds? In-Reply-To: <200801302353.04427.nicolas.weeger@laposte.net> References: <200801302353.04427.nicolas.weeger@laposte.net> Message-ID: <47A109DD.9030002@real-time.com> Nicolas Weeger wrote: > Hello. > > Is there anyone willing to do binary builds for Windows for now on? (Moving the discussion from IRC to the ML) What about using something like CMake ? http://www.cmake.org/HTML/Index.html http://www.cmake.org/HTML/About.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080130/307c5f8c/attachment.pgp From kbulgrien at worldnet.att.net Wed Jan 30 18:17:38 2008 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Wed, 30 Jan 2008 18:17:38 -0600 Subject: [crossfire] Weather code In-Reply-To: <200801302359.22703.nicolas.weeger@laposte.net> References: <200801302359.22703.nicolas.weeger@laposte.net> Message-ID: <200801301817.38564.kbulgrien@worldnet.att.net> > Is anyone actually using the weather system? Or does anyone actually > understand the aim it has? Or has any plan to improve it? > > I was pondering making that a plugin, or simply trashing it... > > Opinions? Thoughts? I do not care about the weather code. IMO, there are more valuable things to work on that would more dramatically improve game play. I am not even sure I have ever seen it in use, and presently do not see it as something worth fixing when compared with some of the more reasonable feature requests. I have a hard time thinking weather would significantly improve a Crossfire gaming experience. This is not to say that I can't think of things weather could conceptually do - I just don't think they have enough bang-for-the-buck, so to speak. Kevin From juhaj at iki.fi Thu Jan 31 14:19:46 2008 From: juhaj at iki.fi (Juha =?iso-8859-1?q?J=E4ykk=E4?=) Date: Thu, 31 Jan 2008 22:19:46 +0200 Subject: [crossfire] Weather code In-Reply-To: <200801301817.38564.kbulgrien@worldnet.att.net> References: <200801302359.22703.nicolas.weeger@laposte.net> <200801301817.38564.kbulgrien@worldnet.att.net> Message-ID: <200801312219.51128.juhaj@iki.fi> > not even sure I have ever seen it in use, and presently do not see it I have used it, but it has two drawbacks: it only ever seems to make snow fall on the ground, making all the world (well, the parts I checked) basically a big puddle of water (making moving very slow unless you levitate). The second drawback is that with slower "weather speeds" (I fail to recall what the real name of the setting is) it never does anything and the moment it starts to do something (i.e. fast enough to be noticed), it changes way too fast (and produces the puddles). IMO it's absolutely useless as is. And I agree with Kevin: there are more important things to work at at the moment. -Juha -- ----------------------------------------------- | Juha J?ykk?, juolja at utu.fi | | home: http://www.utu.fi/~juolja/ | ----------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20080131/f2ddc719/attachment.pgp From tchize at gmail.com Thu Jan 31 16:25:07 2008 From: tchize at gmail.com (David Delbecq) Date: Thu, 31 Jan 2008 23:25:07 +0100 Subject: [crossfire] Weather code In-Reply-To: <200801302359.22703.nicolas.weeger@laposte.net> References: <200801302359.22703.nicolas.weeger@laposte.net> Message-ID: <47A24AC3.3080509@gmail.com> I remember 2 main facts about weather code. 1st, original author wanted to make it so complex it would be impossible to predict it's behaviour 2nd, after 2 weeks fixing performances issue to make it barely useable, original author told me i "didn't understand the code" and broke it with my acceleration. Just Trash it! Nicolas Weeger a ?crit : > Hello. > > Is anyone actually using the weather system? Or does anyone actually > understand the aim it has? Or has any plan to improve it? > > I was pondering making that a plugin, or simply trashing it... > > > Opinions? Thoughts? > > Nicolas > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From mwedel at sonic.net Thu Jan 31 22:32:31 2008 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 31 Jan 2008 20:32:31 -0800 Subject: [crossfire] Weather code In-Reply-To: <47A24AC3.3080509@gmail.com> References: <200801302359.22703.nicolas.weeger@laposte.net> <47A24AC3.3080509@gmail.com> Message-ID: <47A2A0DF.40802@sonic.net> I'd also say it could go, and probably doesn't need to be replaced. A few other notes I recall about it: - A goal was not only to mimic weather, but also try and mimic and alter the environment. For example, if an area that currently had forest never got rain, it would turn to desert, or if desert got bunches of rain, it would turn to grass or forest. A problem with that is that I think the world is laid out how folks want it, so it would actually be annoying to have the great forest disappear and turn into a desert (certain maps and quests correspond to actual terrain, like the ruins are in the northern desert) - Related was the idea of different plants (herbs) that could be harvested spawning based on right conditions - eg, this area gets right amount of rain fall, has right temperature, and so ginseng would grow there. While that could still be nice, probably better ways to do it. One could come up with basic rules of where certain things grow (this only grows in plains, only in hills, etc). And then at a map level, could have some basic climate information which dictates things further. For example, ginseng might grow in grassland in warm areas, and beladona in grasslands in cold climates. The map information itself could dictate if something is a warm or cold climate (while some world map tiles may be on the both, in general, I think that resolution would be enough) That could get the different plants growing without the need for an entire weather system.