From leaf at real-time.com Wed Oct 5 00:42:58 2011 From: leaf at real-time.com (Rick Tanner) Date: Wed, 05 Oct 2011 00:42:58 -0500 Subject: [crossfire] Tower of Vim (Crossfire) In-Reply-To: <1317216187.33460.YahooMailClassic@web125809.mail.ne1.yahoo.com> References: <1317216187.33460.YahooMailClassic@web125809.mail.ne1.yahoo.com> Message-ID: <4E8BEE62.9010802@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/28/11 8:23 AM, David Safir wrote: > Hello, I just play the game Crossfire, I don't write much, but I > was wondering about the Tower of Vim/ Elven Moon quest, World > 110_128, just to the right of Lake Country, Long time player, first time posting? ;-) > It seems the entrance was missing, and also that there was no way > to get to the lower levels back in troll canyon, the elven moon > counterpart quest, I will look in to this and see if it something with the old map set that Metalforge is using or a bigger map problem. Thank you for posting and bringing this to our attention. > Plus, we need more interesting bows in Crossfire and I think > there's one in that quest :D Interesting in what way? Stats, damage types, names, graphics, et al. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOi+5ihHyvgBp+vH4RAk5PAJ0RfUAsynjdWnU2TuPcvXncUSXMzwCfb8mR tLO2ik5fFMIylq86iNyjaF0= =IiCc -----END PGP SIGNATURE----- From mwedel at sonic.net Sun Oct 9 00:13:59 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 08 Oct 2011 22:13:59 -0700 Subject: [crossfire] exp loss changes Message-ID: <4E912D97.5000302@sonic.net> After long last, I've started work on the skill system I suggested at: http://wiki.metalforge.net/doku.php/user:mwedel:skills (it helps to have some free time between jobs) On that page, in the notes, I mention that level loss will not result in loss of AP - rather, it just means that it will take longer before they get any new ones. What I mean by this is lets suppose the character got to level 10, and spent the AP he got there. He dies or is drained, and is now level 9 - none of his existing skills are decreased (no way to really fairly do that), and he does not lose any AP. He adventures, regains level 10, but since this does not exceed the max level he previously achieved, he does not get any AP for that level - not until level 11 does he get any AP. Doing this avoids all sorts of headaches within the code, and from a player perspective, is perhaps a little nicer - since the character does not really lose a level, they can go back to the same map they died and still have a good chance at finishing it - except for stat loss, they are the same level before. With such a method, I was thinking that instead of decreasing exp from the player total, instead add a new field like exp_penalty or exp_loss. When a player dies, that field is increased by appropriate amount- exp_loss += (exp - exp_loss) * death_penalty_ratio. Then, any earned experience after that point gets applied to exp_loss first, and only when that is zero, does exp get applied to normal total. This system can be applied to the existing skill system, as well as monsters. I think this would also simplify the permanent exp ratios - in a sense, exp_loss gets limited to exp * permanent_exp_ratio - this would also mean that the permanent_exp_ratio can get changed on an existing server and work as expectedly (right now, it doesn't really, as permanent exp is added to the bucket as it is earned). I think for permanent exp servers, the output may be a bit more clear - show total exp earned, total penalty, and effective total. I also think that in many ways, this just simplifies a lot of the code. And if one did still want to reduce levels, that is pretty easy - just use exp - exp_loss when looking up what should be the level of the skill. Thoughts? From leaf at real-time.com Thu Oct 13 00:04:46 2011 From: leaf at real-time.com (Rick Tanner) Date: Thu, 13 Oct 2011 00:04:46 -0500 Subject: [crossfire] exp loss changes In-Reply-To: <4E912D97.5000302@sonic.net> References: <4E912D97.5000302@sonic.net> Message-ID: <4E96716E.90306@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/9/11 12:13 AM, Mark Wedel wrote: > > After long last, I've started work on the skill system I suggested > at: > > http://wiki.metalforge.net/doku.php/user:mwedel:skills > > (it helps to have some free time between jobs) If that means what I think it does.. very sorry to hear this. > On that page, in the notes, I mention that level loss will not > result in loss of AP - rather, it just means that it will take > longer before they get any new ones. Very interesting. > With such a method, I was thinking that instead of decreasing exp > from the player total, instead add a new field like exp_penalty or > exp_loss. When a player dies, that field is increased by > appropriate amount- exp_loss += (exp - exp_loss) * > death_penalty_ratio. > > Then, any earned experience after that point gets applied to > exp_loss first, and only when that is zero, does exp get applied to > normal total. By chance could some of this exp loss by death or drain be regained through quest items/rewards or other in game mechanics? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOlnFuhHyvgBp+vH4RAoO7AKCYHtP+G8/n5dasEkvAUlJfyAh4xQCgx98H UDIIPBglVoFdC2O8LTLbqPQ= =m4YO -----END PGP SIGNATURE----- From mwedel at sonic.net Thu Oct 13 01:44:32 2011 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 12 Oct 2011 23:44:32 -0700 Subject: [crossfire] exp loss changes In-Reply-To: <4E96716E.90306@real-time.com> References: <4E912D97.5000302@sonic.net> <4E96716E.90306@real-time.com> Message-ID: <4E9688D0.2000902@sonic.net> On 10/12/11 10:04 PM, Rick Tanner wrote: >> On that page, in the notes, I mention that level loss will not >> result in loss of AP - rather, it just means that it will take >> longer before they get any new ones. > > Very interesting. > >> With such a method, I was thinking that instead of decreasing exp >> from the player total, instead add a new field like exp_penalty or >> exp_loss. When a player dies, that field is increased by >> appropriate amount- exp_loss += (exp - exp_loss) * >> death_penalty_ratio. >> >> Then, any earned experience after that point gets applied to >> exp_loss first, and only when that is zero, does exp get applied to >> normal total. > > By chance could some of this exp loss by death or drain be regained > through quest items/rewards or other in game mechanics? I didn't initially think about that, but yes, this would allow that to happen. A problem right now is there is no way to know how much exp a character has lost through death/draining. As such, there is no way to restore it - if you give a character 10,000 exp, that is just 10,000 exp, which means if the character has not lost exp, that is just a bonus. But by tracking loss, one could basically do something like exp_loss -= 10000; if exp_loss < 0 exp_loss=0; So things like quests, potions, spells, etc, could reduce that field, but if that field is already 0, they gain nothing. One could think of this to the restoration spell in AD&D - it is used to regain lost levels, but doesn't give the character exp. So in crossfire, one could have expensive potions to get back that lost exp. This would make monsters that do drain attacks much less annoying than now - it might cost a fair amount of platinum to get that potion, but at least you could. Having spells that do it would probably not work, as it would just be too easy for players then. But potions, scrolls, praying at altars, etc, would seem to be possible solutions - and of course, there is nothing that they would have to restore it all - maybe they reduce it by 50%. One could repeat that many times and get the number closer and closer to zero, but still never get it to zero by that method. From mwedel at sonic.net Thu Oct 13 01:52:01 2011 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 12 Oct 2011 23:52:01 -0700 Subject: [crossfire] skill/class cost table Message-ID: <4E968A91.90003@sonic.net> Following up on: http://wiki.metalforge.net/doku.php/user:mwedel:skills I've made up: http://wiki.metalforge.net/doku.php/user:mwedel:skill_classes Which goes into a bit more detail on costs - mostly because I got to the point where I started to need to know that information to progress on work of the system. That is only a first pass (as noted on the page), but I don't see any reason not to share it - other folks can make suggestions even at this point. From mwedel at sonic.net Fri Oct 14 00:39:32 2011 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 13 Oct 2011 22:39:32 -0700 Subject: [crossfire] exp loss changes In-Reply-To: <4E9688D0.2000902@sonic.net> References: <4E912D97.5000302@sonic.net> <4E96716E.90306@real-time.com> <4E9688D0.2000902@sonic.net> Message-ID: <4E97CB14.6050503@sonic.net> Just a note on this - changing it as suggested does effect permanent experience in a subtle way. Right now, experience you earn after losing experience still goes towards permanent experience. Suppose a situation where a character has 100,000 experience and has not died. Permanent exp is set at 20%, and a character loses 10% of exp on death. In the old system, character would have 20,000 perm exp. He dies, goes to 90,000 exp, and as he regains that 10K exp, he gets permanent experience for it, so when he is back at 100,000 (assuming no more deaths), his permanent experience is now 22,000, since that goes up on all exp gain. If the character is constantly dying, eventually he'll get down to his permanent exp total, at which he could slowly level up just by permanent experience. Under the suggested system, a characters would be limited to having an exp loss of 80% of total, or 80K. The character dies, his exp loss is 10K. If he gets to 100K again and dies, this could repeat forever - he will never get to a point where he is down to his permanent exp total. One way to work around this is that if a character has an exp loss, and permanent exp is in place, when they regain it, some of it goes to his total. Taking the above example, character dies. His exp total is still 100K, but he has 10K in exp_loss, so effective experience is 90K. He regains that 10K - 20% (2K) goes to his total, and 80% (8K) goes to the exp loss, so at the end, he has 102K total exp, and 2K exp loss - his effective total is still 100K, but he has not worked off all his loss. I think this would pretty closely match the permanent exp thing as is now. Since his real exp is slowly going up, the cap of his exp loss is also slowly going up. From mwedel at sonic.net Sat Oct 15 00:57:05 2011 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 14 Oct 2011 22:57:05 -0700 Subject: [crossfire] skill/class cost table In-Reply-To: <4E968A91.90003@sonic.net> References: <4E968A91.90003@sonic.net> Message-ID: <4E9920B1.3050506@sonic.net> On 10/12/11 11:52 PM, Mark Wedel wrote: > > Following up on: > > http://wiki.metalforge.net/doku.php/user:mwedel:skills > > I've made up: > > http://wiki.metalforge.net/doku.php/user:mwedel:skill_classes Just a note - I've updated the above to include race/skill combos. In doing so, I've more less come to these conclusions: 1) Races modify skill costs instead of giving skills at fixed costs. I think this is more interesting - as noted on the page, fixed point skills didn't work out - if the cost of the skill is greater than the class gets it, it does no good, and if it is too low, it it just too powerful. For example, if some race got divine casting at 4, they could basically turn any of the other classes into a priest/whatever hybrid. 2) Skill Scrolls get removed, and characters know all of those skills. However, skills start at level 0, and must be increased to level 1 before they are usable. For example, a knight character starts out at with fire magic at level 0. He can use 8 AP to increase it to level 1, and now use it as a level 1 skill. My basis for this change is several: The vast majority of skills are things a person would know to do (anyone can pick up an axe, or try to make a sword - they might be very poor at it, but could do so). Also, I see the starting skills in the existing system as the way to create the classes - fighters don't start with magic skills, not everyone starts with praying skill, etc. But with skills costing different costs, that is what really defines the class in the new system - a fighter will be a better fighter because the fighting skills are fewer points for them than the mage. Also, skill scrolls really just created a short term limitation - once a character got enough money, which typically wasn't too many levels, they could go out and buy all the different skill scrolls. 3) Abilities may be things that need to be learned/bought. Abilities are a lot like spells but for other skills. For example, the ability to do triple shot would be an ability, and that might be something the character needs to go out and learn (ideally by quest, but perhaps also by random scrolls). I haven't really thought much about all the possible abilities - ideally there would be 10-20 per skill (and evenly distributed out so a character gets one every 5 levels or soemthing). For crafting feats, the recipes could like abilities in some context - knowing how to make certain items. For combat skills, special attack moves. Spellcasting already has spells. 4) As is now, this will certainly mix up the races and classes a bit. A good example is there is no class for the dragon player which is good with unarmed combat (claws) and spellcasting - as it is, the dragon either has to choose to be a melee dragon or a spellcasting dragon. I am sure some things will need to get adjusted. From nicolas.weeger at laposte.net Sun Oct 16 04:06:45 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 16 Oct 2011 11:06:45 +0200 Subject: [crossfire] skill/class cost table In-Reply-To: <4E9920B1.3050506@sonic.net> References: <4E968A91.90003@sonic.net> <4E9920B1.3050506@sonic.net> Message-ID: <201110161106.48692.nicolas.weeger@laposte.net> Hello. Thanks for the updates on the new skill system, sounds really nice :) > 1) Races modify skill costs instead of giving skills at fixed costs. I > think this is more interesting - as noted on the page, fixed point skills > didn't work out - if the cost of the skill is greater than the class gets > it, it does no good, and if it is too low, it it just too powerful. For > example, if some race got divine casting at 4, they could basically turn > any of the other classes into a priest/whatever hybrid. Makes sense. > 2) Skill Scrolls get removed, and characters know all of those skills. > However, skills start at level 0, and must be increased to level 1 before > they are usable. For example, a knight character starts out at with fire > magic at level 0. He can use 8 AP to increase it to level 1, and now use > it as a level 1 skill. My basis for this change is several: The vast > majority of skills are things a person would know to do (anyone can pick > up an axe, or try to make a sword - they might be very poor at it, but > could do so). Also, I see the starting skills in the existing system as > the way to create the classes - fighters don't start with magic skills, > not everyone starts with praying skill, etc. But with skills costing > different costs, that is what really defines the class in the new system - > a fighter will be a better fighter because the fighting skills are fewer > points for them than the mage. > > Also, skill scrolls really just created a short term limitation - once a > character got enough money, which typically wasn't too many levels, they > could go out and buy all the different skill scrolls. Only thing I see is meditation, which is (in the current system) restricted to the monk. If you give that skill to everyone, even at a 100 AP per level cost, I'm sure people will use it for the regen benefit. > 3) Abilities may be things that need to be learned/bought. Abilities are a > lot like spells but for other skills. For example, the ability to do > triple shot would be an ability, and that might be something the character > needs to go out and learn (ideally by quest, but perhaps also by random > scrolls). I haven't really thought much about all the possible abilities > - ideally there would be 10-20 per skill (and evenly distributed out so a > character gets one every 5 levels or soemthing). For crafting feats, the > recipes could like abilities in some context - knowing how to make certain > items. For combat skills, special attack moves. Spellcasting already has > spells. Seems interesting, yes. For spells, something like increased range, or why not having the "fire all around you instead of a cone" be an ability too? > 4) As is now, this will certainly mix up the races and classes a bit. A > good example is there is no class for the dragon player which is good with > unarmed combat (claws) and spellcasting - as it is, the dragon either has > to choose to be a melee dragon or a spellcasting dragon. I am sure some > things will need to get adjusted. Well, sure, but adjustments are to be expected when there are many changes :) Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sun Oct 16 04:12:44 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 16 Oct 2011 11:12:44 +0200 Subject: [crossfire] exp loss changes In-Reply-To: <4E97CB14.6050503@sonic.net> References: <4E912D97.5000302@sonic.net> <4E9688D0.2000902@sonic.net> <4E97CB14.6050503@sonic.net> Message-ID: <201110161112.45198.nicolas.weeger@laposte.net> > One way to work around this is that if a character has an exp loss, and > permanent exp is in place, when they regain it, some of it goes to his > total. I think perm exp can be used for two goals: - enable even really unskilled or unlucky players to level up even if they die a lot ; in which case increaseing perm xp at each chance is indeed a good idea - be a safety net for players wanting to try dungeons, so that even if they die they aren't too penalized anyway ; in this case I'm not sure increasing perm xp is such a good idea But anyway however this is adjusted, it can be changed later if needed :) Regards Nicoals -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sun Oct 16 06:21:35 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 16 Oct 2011 13:21:35 +0200 Subject: [crossfire] Proposal for artifacts changes Message-ID: <201110161321.39868.nicolas.weeger@laposte.net> Hello. I'd like to change artifacts handling by introducing archetypes for all artifacts combos. So for instance, for the 'Thieves' artifacts, an archetype named '__ring_Thieves' would be generated with the relevant properties, and used for the actual ring of Thieves. There would be various '__helmet_(whatever)' for helmets, and so on for all artifact possibilities. I see various benefits to that. First, it would be possible to remove totally an artifact, leading to load errors warnings and discarding (making a singularity I think) the "actual" items this artifact represents. And secondly it enables changing artifacts like other archetypes, with the change being applied directly to all existing items, instead of having various variants of the artifact. The drawback I see is the introduction of many temporary archetypes, but I guess we can live with that. What do you think of this proposal? Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Sun Oct 16 15:01:14 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 16 Oct 2011 13:01:14 -0700 Subject: [crossfire] exp loss changes In-Reply-To: <201110161112.45198.nicolas.weeger@laposte.net> References: <4E912D97.5000302@sonic.net> <4E9688D0.2000902@sonic.net> <4E97CB14.6050503@sonic.net> <201110161112.45198.nicolas.weeger@laposte.net> Message-ID: <4E9B380A.8080805@sonic.net> On 10/16/11 02:12 AM, Nicolas Weeger wrote: >> One way to work around this is that if a character has an exp loss, and >> permanent exp is in place, when they regain it, some of it goes to his >> total. > > > I think perm exp can be used for two goals: > > - enable even really unskilled or unlucky players to level up even if they die > a lot ; in which case increaseing perm xp at each chance is indeed a good idea > > - be a safety net for players wanting to try dungeons, so that even if they > die they aren't too penalized anyway ; in this case I'm not sure increasing > perm xp is such a good idea The second case is probably a tough one - I suppose it depends on what percentage perm exp is set to, as well as what percentage is lost on death, but I suspect for most servers, the perm exp isn't going to help out on a single death, as it would take several deaths before you work down to your perm exp total. One area where perm exp comes into use now is hard to advance skills. The permanent exp will protect some portion of experience in those skills. For example, you get exp in some skill, and you may die a bunch of times before you advance it again - the perm exp protects at least some portion of that. In my new system, that doesn't really apply anymore - since skills don't have exp, you don't need to protect those skills (and with AP, hard to advance skills have sort of a different meaning) > But anyway however this is adjusted, it can be changed later if needed :) One could certainly have 2 tunables here - maximum exp loss percentage, and percentage of new exp that is always added to new total. So one could have a server with perm exp at 50%, but only 25% for amount added to new exp. So on death, 75% of exp gained after that point goes to work off the exp loss, and only 25% goes to increasing the total. Or other server admins could set that to 0% added to new exp - you have to work off all your death loss before you get any more. I think the only gotcha here is that if percentage added to new total is greater than max loss, you would get in the situation that as the character regains exp, his current exp_loss would exceed what the limit should be based on his new total. From mwedel at sonic.net Sun Oct 16 15:09:53 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 16 Oct 2011 13:09:53 -0700 Subject: [crossfire] skill/class cost table In-Reply-To: <201110161106.48692.nicolas.weeger@laposte.net> References: <4E968A91.90003@sonic.net> <4E9920B1.3050506@sonic.net> <201110161106.48692.nicolas.weeger@laposte.net> Message-ID: <4E9B3A11.2080009@sonic.net> On 10/16/11 02:06 AM, Nicolas Weeger wrote: >> 2) Skill Scrolls get removed, and characters know all of those skills. >> However, skills start at level 0, and must be increased to level 1 before >> they are usable. For example, a knight character starts out at with fire >> magic at level 0. He can use 8 AP to increase it to level 1, and now use >> it as a level 1 skill. My basis for this change is several: The vast >> majority of skills are things a person would know to do (anyone can pick >> up an axe, or try to make a sword - they might be very poor at it, but >> could do so). Also, I see the starting skills in the existing system as >> the way to create the classes - fighters don't start with magic skills, >> not everyone starts with praying skill, etc. But with skills costing >> different costs, that is what really defines the class in the new system - >> a fighter will be a better fighter because the fighting skills are fewer >> points for them than the mage. >> >> Also, skill scrolls really just created a short term limitation - once a >> character got enough money, which typically wasn't too many levels, they >> could go out and buy all the different skill scrolls. > > Only thing I see is meditation, which is (in the current system) restricted to > the monk. > > If you give that skill to everyone, even at a 100 AP per level cost, I'm sure > people will use it for the regen benefit. I see meditation as an ability (see below) that only monks would get. Meditation would be an ability not linked to any skill (as it doesn't advance with levels). There would be other abilities tied to specific races. For example, wraith touch would be only for wraith, and tied to unarmed combat. Clawing would be for dragons and also tied to unarmed combat. There are probably some others out there. Note that this could get extended - one could add abilities that only certain classes get just to add some more color to the game. >> 3) Abilities may be things that need to be learned/bought. Abilities are a >> lot like spells but for other skills. For example, the ability to do >> triple shot would be an ability, and that might be something the character >> needs to go out and learn (ideally by quest, but perhaps also by random >> scrolls). I haven't really thought much about all the possible abilities >> - ideally there would be 10-20 per skill (and evenly distributed out so a >> character gets one every 5 levels or soemthing). For crafting feats, the >> recipes could like abilities in some context - knowing how to make certain >> items. For combat skills, special attack moves. Spellcasting already has >> spells. > > Seems interesting, yes. For spells, something like increased range, or why not > having the "fire all around you instead of a cone" be an ability too? Actually, you can do that right now - just fire in direction 0. For spells, since there are already a lot of them, I'm not as concerned about tweaking them. But for many of the other skills, abilities need to be determined. As examples, some that come to mind off the top of my head: For weapons, some ability that hits all enemies around the character For certain weapons, maybe special slowing, paralyzing, etc, attacks. For thievery, something like backstab for extra damage, bypass dodge, etc. Just like spells, the list could be endless. But some of my idea here is that this also adds things to make the skills more interesting. Just as right now, spell skills would not be that interesting if you just got a few spells to start and all that happened as you went up level is the damage went up slightly, so it would be with other skills. Spell skills are more interesting as you get new spells to try - and ideally similar things should be in place for other skills, so that you have something to look forward to and new things to try out. Some could also be strategic - some special attacks may take more time to perform, so the player has to make the choice if the effect you get would be worth it or not. From mwedel at sonic.net Sun Oct 16 15:28:42 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 16 Oct 2011 13:28:42 -0700 Subject: [crossfire] Proposal for artifacts changes In-Reply-To: <201110161321.39868.nicolas.weeger@laposte.net> References: <201110161321.39868.nicolas.weeger@laposte.net> Message-ID: <4E9B3E7A.3040104@sonic.net> On 10/16/11 04:21 AM, Nicolas Weeger wrote: > Hello. > > > I'd like to change artifacts handling by introducing archetypes for all > artifacts combos. > > So for instance, for the 'Thieves' artifacts, an archetype named > '__ring_Thieves' would be generated with the relevant properties, and used for > the actual ring of Thieves. There would be various '__helmet_(whatever)' for > helmets, and so on for all artifact possibilities. Do you see this as being done automatically (at collect time for example), or this all done by hand? Or some combo? > > > I see various benefits to that. > > First, it would be possible to remove totally an artifact, leading to load > errors warnings and discarding (making a singularity I think) the "actual" > items this artifact represents. In general, using singularities is not a good thing. I'd have to look at the code in particular, but when that happens, all that can happen is that the singularity created can only fill in the values that it is reading from the save file. And the save file only contains differences from the artifact, so the end result is that the loaded object is likely to be missing a lot of information to the extent it probably isn't usable (it may even be missing name information). > And secondly it enables changing artifacts like other archetypes, with the > change being applied directly to all existing items, instead of having various > variants of the artifact. And that would be a good thing. I do wonder if it might make sense to only apply this to equipment and not monsters however. Monsters, being short lived and generated at that time, probably don't need archetypes - if the artifact gets changed, it is not like there are a bunch of artifact monsters sitting about that are out of date. > > The drawback I see is the introduction of many temporary archetypes, but I > guess we can live with that. I do wonder if rather than making artifacts for everything, if it would be easier to just store a reference to the artifact that an item was created from. I honestly don't really know - the problem with what I suggest is that you need to have the logic at load time to go through and look at the artifact, look at the original object (clone), and re-apply the artifact changes and see if they are different. So as I think about it, archetypes probably is simpler. Few questions/thoughts on this: - If the archetype for an artifact combo is missing, what happens? Does the server just treat that as an invalid combo and do nothing? Or something else? I'd personally suggest it do nothing - in that way, combos can be further tweaked by not having the corresponding archetype. There are some combos that really just don't work - this is because the artifact applies a percentage difference to the original, but the original has base values too low such that no difference actually results. - If archetypes for all now exist, does it perhaps then make sense to just make up treasurelists for these instead? Such that the occurrence for these can be better tweaked, or more easily seen what the chances are? > > What do you think of this proposal? Sounds good to me. One other advantage here is that this would make adding artifacts to maps more consistent - one could basically just take the armor or helmet or whatever archetype as is, and put it on the map and the right thing should happen. From nicolas.weeger at laposte.net Fri Oct 21 11:54:07 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 21 Oct 2011 18:54:07 +0200 Subject: [crossfire] skill/class cost table In-Reply-To: <4E9B3A11.2080009@sonic.net> References: <4E968A91.90003@sonic.net> <201110161106.48692.nicolas.weeger@laposte.net> <4E9B3A11.2080009@sonic.net> Message-ID: <201110211854.11743.nicolas.weeger@laposte.net> > I see meditation as an ability (see below) that only monks would get. > Meditation would be an ability not linked to any skill (as it doesn't > advance with levels). Ok, makes sense. > There would be other abilities tied to specific races. For example, > wraith touch would be only for wraith, and tied to unarmed combat. > Clawing would be for dragons and also tied to unarmed combat. There are > probably some others out there. Seems ok. > > Seems interesting, yes. For spells, something like increased range, or > > why not having the "fire all around you instead of a cone" be an ability > > too? > > Actually, you can do that right now - just fire in direction 0. My proposal of course implied to remove that feature for spells, unless you have the matching ability :) After all, firing in all directions at the same time isn't that easy to do, is it? > For spells, since there are already a lot of them, I'm not as concerned > about tweaking them. But for many of the other skills, abilities need to > be determined. There are too many, even... Especially redundant ones (small, medium and large variants). > Just like spells, the list could be endless. But some of my idea here is > that this also adds things to make the skills more interesting. Just as > right now, spell skills would not be that interesting if you just got a > few spells to start and all that happened as you went up level is the > damage went up slightly, so it would be with other skills. Spell skills > are more interesting as you get new spells to try - and ideally similar > things should be in place for other skills, so that you have something to > look forward to and new things to try out. > > Some could also be strategic - some special attacks may take more time to > perform, so the player has to make the choice if the effect you get would > be worth it or not. Makes sense. Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Sat Oct 22 12:33:47 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 22 Oct 2011 19:33:47 +0200 Subject: [crossfire] Proposal for artifacts changes In-Reply-To: <4E9B3E7A.3040104@sonic.net> References: <201110161321.39868.nicolas.weeger@laposte.net> <4E9B3E7A.3040104@sonic.net> Message-ID: <201110221933.53332.nicolas.weeger@laposte.net> After some thinking, maybe the best way would be to add a "from_artifact" field, or something like that, in generated artifacts. At loading the server would just see that field and instantiante the artifact from the archetype. At save time, generate the artifact, compare to the item (in case of really specific fields - besides, I think "magic" isn't modified by artifacts), and save as usual. Ensure simply that "from_artifact" is the first field after the archetype, and it should be ok. Regards Nicolas Le dimanche 16 octobre 2011 22:28:42, Mark Wedel a ?crit : > On 10/16/11 04:21 AM, Nicolas Weeger wrote: > > Hello. > > > > > > I'd like to change artifacts handling by introducing archetypes for all > > artifacts combos. > > > > So for instance, for the 'Thieves' artifacts, an archetype named > > '__ring_Thieves' would be generated with the relevant properties, and > > used for the actual ring of Thieves. There would be various > > '__helmet_(whatever)' for helmets, and so on for all artifact > > possibilities. > > Do you see this as being done automatically (at collect time for > example), or this all done by hand? Or some combo? > > > I see various benefits to that. > > > > First, it would be possible to remove totally an artifact, leading to > > load errors warnings and discarding (making a singularity I think) the > > "actual" items this artifact represents. > > In general, using singularities is not a good thing. I'd have to look at > the code in particular, but when that happens, all that can happen is that > the singularity created can only fill in the values that it is reading > from the save file. And the save file only contains differences from the > artifact, so the end result is that the loaded object is likely to be > missing a lot of information to the extent it probably isn't usable (it > may even be missing name information). > > > And secondly it enables changing artifacts like other archetypes, with > > the change being applied directly to all existing items, instead of > > having various variants of the artifact. > > And that would be a good thing. I do wonder if it might make sense to > only apply this to equipment and not monsters however. Monsters, being > short lived and generated at that time, probably don't need archetypes - > if the artifact gets changed, it is not like there are a bunch of artifact > monsters sitting about that are out of date. > > > The drawback I see is the introduction of many temporary archetypes, but > > I guess we can live with that. > > I do wonder if rather than making artifacts for everything, if it would > be easier to just store a reference to the artifact that an item was > created from. I honestly don't really know - the problem with what I > suggest is that you need to have the logic at load time to go through and > look at the artifact, look at the original object (clone), and re-apply > the artifact changes and see if they are different. So as I think about > it, archetypes probably is simpler. > > Few questions/thoughts on this: > - If the archetype for an artifact combo is missing, what happens? Does > the server just treat that as an invalid combo and do nothing? Or > something else? I'd personally suggest it do nothing - in that way, combos > can be further tweaked by not having the corresponding archetype. There > are some combos that really just don't work - this is because the artifact > applies a percentage difference to the original, but the original has base > values too low such that no difference actually results. > > - If archetypes for all now exist, does it perhaps then make sense to just > make up treasurelists for these instead? Such that the occurrence for > these can be better tweaked, or more easily seen what the chances are? > > > What do you think of this proposal? > > Sounds good to me. One other advantage here is that this would make > adding artifacts to maps more consistent - one could basically just take > the armor or helmet or whatever archetype as is, and put it on the map and > the right thing should happen. -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Sat Oct 22 23:17:10 2011 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 22 Oct 2011 21:17:10 -0700 Subject: [crossfire] skill/class cost table In-Reply-To: <201110211854.11743.nicolas.weeger@laposte.net> References: <4E968A91.90003@sonic.net> <201110161106.48692.nicolas.weeger@laposte.net> <4E9B3A11.2080009@sonic.net> <201110211854.11743.nicolas.weeger@laposte.net> Message-ID: <4EA39546.3080904@sonic.net> On 10/21/11 09:54 AM, Nicolas Weeger wrote: >>> Seems interesting, yes. For spells, something like increased range, or >>> why not having the "fire all around you instead of a cone" be an ability >>> too? >> >> Actually, you can do that right now - just fire in direction 0. > > My proposal of course implied to remove that feature for spells, unless you > have the matching ability :) > > After all, firing in all directions at the same time isn't that easy to do, is > it? True. There could also be modifications for other spells - maybe at some level, you get a 'split bolt' ability, so when cast, you get a triple wide bolt (split would suggest 2, but with the aligning of spaces, that would be a headache to know what other space it goes down). Such an ability may increase casting time and increase mana cost, but things like that could be done. Instead of 360? cones, maybe also have something that allows 180? cones instead of the current 90? cones. > > >> For spells, since there are already a lot of them, I'm not as concerned >> about tweaking them. But for many of the other skills, abilities need to >> be determined. > > There are too many, even... Especially redundant ones (small, medium and large > variants). Yep - I know revamping spells has been suggested to remove the variants. One could boil it down to the basic - bolt, cone, ball. Now one might still need the different elements (fire, ice, lightning, earth) just to tie properly to skills, having small/medium/large varieties of each may not be needed. Perhaps at some level, being able to do 'medium ball' spells is an ability that is learned, and applies to all ball spells you may do - that reduces number of spells somewhat. I'd have to think how to do it, but perhaps chaos versions require a minimal level in all the different elements (since you are mixing them). This goes a bit beyond the initial skill system - the new skill system may make it easier to do these features. But my higher priority is getting the combat skills sorted out. As an aside, I'm thinking of setting up an arch & server branch for this (the maps really should not need changing on this). My main thought is that this is going to be a pretty radical change in how things work for players, and so servers probably need some time to adjust (and probably some time is needed just to balance this out before going live on servers). Now I could work to make it so that both skill systems are available in the same code base, and by tweaking config values, you get one or the other, but long term, this is a big enough change, there is no way both can be supported. And in many ways, cleaning up the code now makes sure the code gets cleaned up, vs putting it off to some point in the future. From om at iki.fi Sun Oct 23 14:47:37 2011 From: om at iki.fi (Otto J. Makela) Date: Sun, 23 Oct 2011 22:47:37 +0300 Subject: [crossfire] Skill effectiveness changes? Message-ID: <4EA46F59.3000303@iki.fi> Crossfire.metalforge.net seems to be running version v1.12-beta-r12190M. Has the "effectiveness" of skills (specially trap disarming and lock picking) been changed around this version in respect to some earlier releases? Even though I have a character with fair skill levels, I've yet to successfully disarm or unlock anything with this version in even slightly higher-level dungeons (like the Scorn Prison)? Or was gaining skill levels perhaps easier in earlier versions? Or am I just imagining things? -- /* * * Otto J. Makela * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */ From nicolas.weeger at laposte.net Mon Oct 24 11:58:53 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 24 Oct 2011 18:58:53 +0200 Subject: [crossfire] skill/class cost table In-Reply-To: <4EA39546.3080904@sonic.net> References: <4E968A91.90003@sonic.net> <201110211854.11743.nicolas.weeger@laposte.net> <4EA39546.3080904@sonic.net> Message-ID: <201110241858.57547.nicolas.weeger@laposte.net> > True. There could also be modifications for other spells - maybe at some > level, you get a 'split bolt' ability, so when cast, you get a triple wide > bolt (split would suggest 2, but with the aligning of spaces, that would > be a headache to know what other space it goes down). > > Such an ability may increase casting time and increase mana cost, but > things like that could be done. > > Instead of 360? cones, maybe also have something that allows 180? cones > instead of the current 90? cones. Yes, many abilities can be thought of. Also some could be given through a quest only, to make them more interesting. > As an aside, I'm thinking of setting up an arch & server branch for this > (the maps really should not need changing on this). My main thought is > that this is going to be a pretty radical change in how things work for > players, and so servers probably need some time to adjust (and probably > some time is needed just to balance this out before going live on > servers). > > Now I could work to make it so that both skill systems are available in > the same code base, and by tweaking config values, you get one or the > other, but long term, this is a big enough change, there is no way both > can be supported. And in many ways, cleaning up the code now makes sure > the code gets cleaned up, vs putting it off to some point in the future. IMO, either make that server private, or ask Meflin and use his server. There are enough empty servers on the tracker right now, no need to add another one. Also, feel free to ask for help, of course :) Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Mon Oct 24 22:56:23 2011 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 24 Oct 2011 20:56:23 -0700 Subject: [crossfire] skill/class cost table In-Reply-To: <201110241858.57547.nicolas.weeger@laposte.net> References: <4E968A91.90003@sonic.net> <201110211854.11743.nicolas.weeger@laposte.net> <4EA39546.3080904@sonic.net> <201110241858.57547.nicolas.weeger@laposte.net> Message-ID: <4EA63367.2090604@sonic.net> On 10/24/11 09:58 AM, Nicolas Weeger wrote: >> As an aside, I'm thinking of setting up an arch& server branch for this >> (the maps really should not need changing on this). My main thought is >> that this is going to be a pretty radical change in how things work for >> players, and so servers probably need some time to adjust (and probably >> some time is needed just to balance this out before going live on >> servers). >> >> Now I could work to make it so that both skill systems are available in >> the same code base, and by tweaking config values, you get one or the >> other, but long term, this is a big enough change, there is no way both >> can be supported. And in many ways, cleaning up the code now makes sure >> the code gets cleaned up, vs putting it off to some point in the future. > > > IMO, either make that server private, or ask Meflin and use his server. There > are enough empty servers on the tracker right now, no need to add another one. > > > Also, feel free to ask for help, of course :) That is one reason I'm thinking of doing a different SVN branch - that makes it easier for others to work on and test this. But in this somewhat incomplete state, I really don't want to put this into the main branch, in case it takes a while to complete, and I don't want to break folks currently running the main branch while this works goes on. The only real downside of a branch is making sure that changes in the trunk make their way to the branch. From shjohnson.pi at gmail.com Tue Oct 25 00:27:03 2011 From: shjohnson.pi at gmail.com (Steven Johnson) Date: Tue, 25 Oct 2011 01:27:03 -0400 Subject: [crossfire] Autoreconf Warnings Bug Message-ID: Hello everyone, I'm Steven. Hopefully if time permits I can keep helping out with this fun project. I created a bug report and uploaded a patch: https://sourceforge.net/tracker/?func=detail&aid=3428070&group_id=13833&atid=113833 It deals with autoreconf warnings and is very low priority and the fix was just adding two brackets. The warning was: (running from root directory of client trunk on Ubuntu Linux 11.10) $ autoreconf ... macros/libcurl.m4:38: LIBCURL_CHECK_CONFIG is expanded from... configure.ac:416: the top level configure.ac:416: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From leaf at real-time.com Tue Oct 25 14:14:55 2011 From: leaf at real-time.com (Rick Tanner) Date: Tue, 25 Oct 2011 14:14:55 -0500 Subject: [crossfire] Skill effectiveness changes? In-Reply-To: <4EA46F59.3000303@iki.fi> References: <4EA46F59.3000303@iki.fi> Message-ID: <4EA70AAF.80406@real-time.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/23/11 2:47 PM, Otto J. Makela wrote: > Crossfire.metalforge.net seems to be running version > v1.12-beta-r12190M. Has the "effectiveness" of skills (specially > trap disarming and lock picking) been changed around this version > in respect to some earlier releases? As far as I can recall and find, nothing has changed on Metalforge in quite some time. > Even though I have a character with fair skill levels, I've yet to > successfully disarm or unlock anything with this version in even > slightly higher-level dungeons (like the Scorn Prison)? Or was > gaining skill levels perhaps easier in earlier versions? Or am I > just imagining things? Feedback was it was easier to gain exp, but took much longer to level up the skill. With latest or most recent server releases, skills such as lockpicking grant more EXP for high (or harder) level locks and this change was made in March-2010. http://crossfire.svn.sourceforge.net/crossfire/?rev=12721&view=rev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOpwqthHyvgBp+vH4RAlhfAJ9VXS59zzb4Br1jM2SvXA7mcyZbSgCbB78h BwMCvKcWzDiGIzA362OtzGg= =o3B8 -----END PGP SIGNATURE----- From shjohnson.pi at gmail.com Tue Oct 25 16:38:25 2011 From: shjohnson.pi at gmail.com (Steven Johnson) Date: Tue, 25 Oct 2011 17:38:25 -0400 Subject: [crossfire] Autoreconf Warnings Bug In-Reply-To: References: Message-ID: I put the brackets in the wrong spots! Here's the new patch attached and pasted: Index: macros/libcurl.m4 =================================================================== --- macros/libcurl.m4 (revision 15261) +++ macros/libcurl.m4 (working copy) @@ -142,7 +142,7 @@ _libcurl_save_libs=$LIBS LIBS="$LIBCURL $LIBS" - AC_LINK_IFELSE(AC_LANG_PROGRAM([#include ],[ + AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]],[ /* Try and use a few common options to force a failure if we are missing symbols or can't link. */ int x; @@ -153,7 +153,7 @@ x=CURLOPT_ERRORBUFFER; x=CURLOPT_STDERR; x=CURLOPT_VERBOSE; -]),libcurl_cv_lib_curl_usable=yes,libcurl_cv_lib_curl_usable=no) +])],[libcurl_cv_lib_curl_usable=yes],[libcurl_cv_lib_curl_usable=no]) CPPFLAGS=$_libcurl_save_cppflags LIBS=$_libcurl_save_libs On Tue, Oct 25, 2011 at 1:27 AM, Steven Johnson wrote: > Hello everyone, I'm Steven. Hopefully if time permits I can keep helping > out with this fun project. > > > I created a bug report and uploaded a patch: > > https://sourceforge.net/tracker/?func=detail&aid=3428070&group_id=13833&atid=113833 > > It deals with autoreconf warnings and is very low priority and the fix was > just adding two brackets. > > The warning was: (running from root directory of client trunk on Ubuntu > Linux 11.10) > $ autoreconf > ... > macros/libcurl.m4:38: LIBCURL_CHECK_CONFIG is expanded from... > configure.ac:416: the top level > configure.ac:416: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call > detected in body > ... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-libcurl-m4-2.diff Type: text/x-patch Size: 822 bytes Desc: not available URL: From nicolas.weeger at laposte.net Thu Oct 27 11:43:49 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 27 Oct 2011 18:43:49 +0200 Subject: [crossfire] Autoreconf Warnings Bug In-Reply-To: References: Message-ID: <201110271843.54366.nicolas.weeger@laposte.net> Hello. > I put the brackets in the wrong spots! Here's the new patch attached and > pasted: Thanks for the patch! I committed it to SVN, both client and server trees (it was for client, but fixes the same bug on the server). Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Thu Oct 27 11:52:35 2011 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 27 Oct 2011 18:52:35 +0200 Subject: [crossfire] Guild facilities cost Message-ID: <201110271852.36245.nicolas.weeger@laposte.net> Hello. In the various guilds, one can buy replacement for stoves, bowyer desk, and such. The current cost seems really high to me, from 10 amberium to 24 amberium. This makes the rooms really unattractive I think, since it's pretty easy to destroy (or curse) a cauldron even at high level. I was thinking of setting the price around 50 jade, which seems slightly better. What do you think of that? Regards Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: