Re: [crossfire] Summon pet monster
Benjamin Lerman wrote: But there are also some other possible considerations - I think you'd want to make sure that a character doesn't have the same skill equipped through both methods (holy symbol and actual praying skill) - I think that may cause some issues - probably more see with the arcane skills. Do you have more idea on what problem that may cause ? It is not very useful to have the same skill equipped twice, but I don't see how it could cause problems. Not 100% sure. My initial thought could be that some of the wizardry skills/talismans may have attunements and replusions/denials to spellpaths. Thus, if I have a talsman equipped and then explicitly ready wizardry, that talisman should become unequipped because it may be preventing me from casting the spell I want. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
I think you really need to set up 2 slots for a proper solution (body_item_skill and body_natural_skill or the like) and not make body_skill be two slots. Doing the later is completely the wrong approach, and was one of the things that the body_... stuff was meant to prevent. Sorry to have been misunderstood, but yes, that was exactly what I was suggesting... But there are also some other possible considerations - I think you'd want to make sure that a character doesn't have the same skill equipped through both methods (holy symbol and actual praying skill) - I think that may cause some issues - probably more see with the arcane skills. Do you have more idea on what problem that may cause ? It is not very useful to have the same skill equipped twice, but I don't see how it could cause problems. Also, every place that checks to see if the skill is already ready would need to be updated, but that would have to be done regardless (I'm pretty sure that that code checkes the pl-ranges[range_skill] - so you'd probably need to add a new range slot (just like the body stuff above) and update all the code to look for it. Ok. All this said, one could make the case that having only 1 skill equipped at a time, regardless of natural or item, is a play balance limitation. Well, it does not really change the balance of play having 1 or 10 skill items equipped because the change of skill item is automatic, but when some items give bonuses and you cannot use natural skill without unequipping it, it made those items nearly useless... I'll modify the code to gace x_item_skill and x_natural_skill and put the patch to sourceforge... -- Benjamin ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
Hi all, And at least, I have a question, does there exists a way to force the client to wear a particular holy symbol whenever possible. Right now, whenever I change skill, even if I do not need any object to get my new skill, my holy symbol is unapplied, which is quite a problem when the holy symbol does a lot more than give the skill praying... Well, I find out where the problem was with this issue: there is only one slot (body_skill) to handle natural skills (any skills learned with a scroll, or any natural skills), to handle object that give skills. My advice is there should be two... I do not see any reason to be obliged to remove an amulet when you use a skill you know. I can try to modify that if there is a consensus, but then I have a slight problem... I'll have to change all the code where skill and object_skill do the same thing, because it will be needed to force not to use 2 skills at the same time and not 2 object_skills at the same time but allow 1 skill and 1 object_skill. Would this be fine? Benjamin Lerman ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
Benjamin Lerman wrote: Hi all, And at least, I have a question, does there exists a way to force the client to wear a particular holy symbol whenever possible. Right now, whenever I change skill, even if I do not need any object to get my new skill, my holy symbol is unapplied, which is quite a problem when the holy symbol does a lot more than give the skill praying... Well, I find out where the problem was with this issue: there is only one slot (body_skill) to handle natural skills (any skills learned with a scroll, or any natural skills), to handle object that give skills. My advice is there should be two... I do not see any reason to be obliged to remove an amulet when you use a skill you know. I can try to modify that if there is a consensus, but then I have a slight problem... I'll have to change all the code where skill and object_skill do the same thing, because it will be needed to force not to use 2 skills at the same time and not 2 object_skills at the same time but allow 1 skill and 1 object_skill. I think you really need to set up 2 slots for a proper solution (body_item_skill and body_natural_skill or the like) and not make body_skill be two slots. Doing the later is completely the wrong approach, and was one of the things that the body_... stuff was meant to prevent. Such a change would require changing all the natural skills to use the other slot, but that wouldn't be that hard (just an archetype update). But there are also some other possible considerations - I think you'd want to make sure that a character doesn't have the same skill equipped through both methods (holy symbol and actual praying skill) - I think that may cause some issues - probably more see with the arcane skills. Also, every place that checks to see if the skill is already ready would need to be updated, but that would have to be done regardless (I'm pretty sure that that code checkes the pl-ranges[range_skill] - so you'd probably need to add a new range slot (just like the body stuff above) and update all the code to look for it. In fact, I'm pretty sure your proposed solution won't work just for that reason - even if I have two skill slots, you'd get this scenario - I equip holy symbol, so range_skill is the holy symbol. Then I use some other (natural) skill. the holy symbol is still equipped, but now range_skill is that other skill (say disarm traps). When I go to cast the spell, the range_skill isn't appropriate so it goes and finds something to equip for me. All this said, one could make the case that having only 1 skill equipped at a time, regardless of natural or item, is a play balance limitation. A case could also be made that perhaps things like talismans should share the amulet spot, lock picks require unequipping your weapon, etc (eg, skill items shouldn't have their own slot, but rather use one of the normal body locations of characters - that after all actually makes even more sense.) - Can't really pick a lock holding a long sword and shield. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
Committed your 2 patches. Just changed one call from (pseudo variables) (x)?f(a,b,c):f(a,b,d) to f(a,b,x?c:d) to not duplicate 2 similar calls Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
On 9/29/05, Benjamin Lerman [EMAIL PROTECTED] wrote: Now, I plan to create Enchant Ring and Enchant Amulet scrolls that would work like Enchant Weapon, but because it demands a little more work than for the 2 previous patch, I'd like to know if those scrolls would be Ok. I'd like to also implement think like Improve resistance to `foo' for Weapons, but once again, would that be Ok? The one comment I would make here is to be sure to deal with the item power properly. What exactly 'properly' is in this context is not neccessarily clear, too little an effect and these scrolls would make rings overpowered, too much, and they would be useless. I would suggest however that if the results of enchanting rings to the extent that their stats are about the same as one with similar item power from the item generator, then you are probably ok. Something that does interest me though, is how you intend to fit this in with the jeweler skill. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re:[crossfire] Summon pet monster
Hello. The first one allow you to summon pet that are of lower level that the current pet you can summon. It is mainly a one line patch that use the same argument that create food or create weapon use. Saw it on SF, sounds ok. The second one allow to use argument with the cast command so that you can use: Isn't there already a field in player structure for spell argument? used when spells have delays, iirc. Now, I plan to create Enchant Ring and Enchant Amulet scrolls that would work like Enchant Weapon, but because it demands a little more work than for the 2 previous patch, I'd like to know if those scrolls would be Ok. I'd like to also implement think like Improve resistance to `foo' for Weapons, but once again, would that be Ok? I'd say you must take care of the overall game balance. Rings and amulets may already be quite powerful, probably don't want to give too much new powerful stuff. As for resistances, i'd say rather no. Unless well though, it could lead to have really high resistances almost everywhere, thus making everything too easy. And at least, I have a question, does there exists a way to force the client to wear a particular holy symbol whenever possible. Right now, whenever I change skill, even if I do not need any object to get my new skill, my holy symbol is unapplied, which is quite a problem when the holy symbol does a lot more than give the skill praying... Afaik no. And yes it's quite a pain. Maybe something to change, ie whenever you cast a spell or something a talisman is autoapplied. Nicolas Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
Isn't there already a field in player structure for spell argument? used when spells have delays, iirc. I did (and still don't) see it. If I grep for char in player.h, I obtain: logrus ~/download/crossfire/include $ grep char player.h ... snip what is not on the pl struct charmaplevel[MAX_BUF]; /* On which level is the player? */ charsavebed_map[MAX_BUF]; /* map where player will respawn after death */ charspellparam[MAX_BUF];/* What param to add to spells */ const char *invis_race;/* What race invisible to? */ charown_title[MAX_NAME];/* Title the player has chosen for themself */ chartitle[BIG_NAME];/* Default title, like fighter, wizard, etc */ charkiller[BIG_NAME]; /* Who killed this player. */ charlast_tell[MAX_NAME]; /* last player that told you something [mids 01/14/2002] */ charwrite_buf[MAX_BUF]; /* Holds arbitrary input from client */ charinput_buf[MAX_BUF]; /* Holds command to run */ charpassword[16]; /* 2 (seed) + 11 (crypted) + 1 (EOS) + 2 (safety) = 16 */ charsearch_str[MAX_BUF];/* Item we are looking for */ If you remove spellparam which is the field I added, I do not see which other field you are referring to. Benjamin Lerman ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re:[crossfire] Summon pet monster
Resistances are bad, I agree. That would basically make all maps in the game worthlessly easy. Same with upping ring power. One has to, as of now, search for good rings which, I think, is the correct way. If anything CF needs to be made harder. --- Nicolas Weeger [EMAIL PROTECTED] wrote: Hello. The first one allow you to summon pet that are of lower level that the current pet you can summon. It is mainly a one line patch that use the same argument that create food or create weapon use. Saw it on SF, sounds ok. The second one allow to use argument with the cast command so that you can use: Isn't there already a field in player structure for spell argument? used when spells have delays, iirc. Now, I plan to create Enchant Ring and Enchant Amulet scrolls that would work like Enchant Weapon, but because it demands a little more work than for the 2 previous patch, I'd like to know if those scrolls would be Ok. I'd like to also implement think like Improve resistance to `foo' for Weapons, but once again, would that be Ok? I'd say you must take care of the overall game balance. Rings and amulets may already be quite powerful, probably don't want to give too much new powerful stuff. As for resistances, i'd say rather no. Unless well though, it could lead to have really high resistances almost everywhere, thus making everything too easy. And at least, I have a question, does there exists a way to force the client to wear a particular holy symbol whenever possible. Right now, whenever I change skill, even if I do not need any object to get my new skill, my holy symbol is unapplied, which is quite a problem when the holy symbol does a lot more than give the skill praying... Afaik no. And yes it's quite a pain. Maybe something to change, ie whenever you cast a spell or something a talisman is autoapplied. Nicolas Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
On Thursday 29 September 2005 08:21 am Benjamin Lerman wrote: [...] The second one allow to use argument with the cast command so that you can use: cast create food waybread or cast summon pet monster spider [...] Isn't this what 'invoke is meant to do? If 'cast will do it now then why have 'invoke? Seems to me we should either leave 'cast as is or make that change and remove 'invoke. There is no reason to have both. I vote to leave 'cast as is because I have an oodle of key bindings using 'invoke. :-) Gene Alexander -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 13:57:12 up 134 days, 14:38, 8 users, load average: 0.13, 0.19, 0.14 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer UnixWare resellers ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
On 9/29/05, ERACC [EMAIL PROTECTED] wrote: ... Isn't this what 'invoke is meant to do? If 'cast will do it now then why have 'invoke? Seems to me we should either leave 'cast as is or make that change and remove 'invoke. There is no reason to have both. I vote to leave 'cast as is because I have an oodle of key bindings using 'invoke. :-) Cast readys the spell for use, while invoke imediatly uses the spell. Bolth have their place, but cast doesn't accept arguments like invoke does. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Summon pet monster
On Thursday 29 September 2005 02:15 pm Andrew Fuchs wrote: On 9/29/05, ERACC [EMAIL PROTECTED] wrote: ... Isn't this what 'invoke is meant to do? If 'cast will do it now then why have 'invoke? Seems to me we should either leave 'cast as is or make that change and remove 'invoke. There is no reason to have both. I vote to leave 'cast as is because I have an oodle of key bindings using 'invoke. :-) Cast readys the spell for use, while invoke imediatly uses the spell. Bolth have their place, but cast doesn't accept arguments like invoke does. Ah, I get it now. Ready the spell *with* an argument so that when one does cast it the argument is used. Ok. Yeah, that would be good. Gene Alexander -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 15:15:03 up 134 days, 15:56, 8 users, load average: 0.19, 0.17, 0.13 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer UnixWare resellers ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
