[crossfire] Re: [Crossfire-cvs] CVS commit: crossfire
[EMAIL PROTECTED] wrote:
Module Name:crossfire
Committed By: cavesomething
Date: Mon Oct 3 03:29:41 UTC 2005
Modified Files:
crossfire: ChangeLog
crossfire/common: item.c loader.l map.c
crossfire/doc/Developers: map-technical
crossfire/include: define.h libproto.h map.h sproto.h
crossfire/server: apply.c c_object.c shop.c skill_util.c
Added Files:
crossfire/doc/Developers: shops
Log Message:
add support for specialised shops
Mikee and I both discovered a segfault caused here:
Saving map /scorn/shops/bowshop
Program received signal SIGSEGV, Segmentation fault.
print_shop_string (m=0xafffee20, output_string=0xafffee20 ) at map.c:710
710 for (i=0; iitems[0].index; i++) {
(gdb) bt
#0 print_shop_string (m=0xafffee20, output_string=0xafffee20 ) at
map.c:710
#1 0x080d29d9 in new_save_map (m=0x888d1d8, flag=0) at map.c:1194
#2 0x080aab16 in swap_map (map=0x888d1d8) at swap.c:166
#3 0x080aabf2 in check_active_maps () at swap.c:194
#4 0x08085429 in main (argc=13, argv=0xafffee20) at main.c:1247
(gdb) print i
$13 = 0
(gdb) print items[i]
Cannot access memory at address 0x0
(gdb) print items
$15 = (shopitems *) 0x0
(gdb) print m-shopitems
$14 = (shopitems *) 0x2e3a72
(gdb) print *m-shopitems
Cannot access memory at address 0x2e3a72
Looking at this, the issue is items being a null pointer. Also, from
what I've found, it's something perticular about the bowshop that's
causing it. Also, if this helps:
(gdb) up
#1 0x080d29d9 in new_save_map (m=0x888d1d8, flag=0) at map.c:1194
1194print_shop_string(m, shop);
(gdb) print m
$19 = (mapstruct *) 0x888d1d8
(gdb) print shop
$20 =
\000\000\000\000\000\000\000\004\000\000\000\000\210S\035\b(\u\u\b\000\000\000\000\004\000\000\000\u7\u\bK\001\000\000\000\000\000\000\210\u\u\u\uU\v\b\u\205\u\b,
'\0' repeats 19 times,
\004\000\000\000\000\210S\035\b(\u\u\b\000\000\000\000\004\000\000\000\000{\u\bJ\001\000\000\000\000\000\000\u\u\u\u\uU\v\b\u7\u\b,
'\0' repeats 19 times,
\004\000\000\000\000\210S\035\b(\u\u\b\000\000\000\000\004\000\000\000\220u\u\bI\001\000\000\000\000\000\000\b\u\u\u\uU\v\b\000{\u\b,
'\0' repeats 19 times,
\004\000\000\000\000\210S\035\b(\u\u\b\000\000\000\000\004\000\000\000(\u\u\bH\001\000...
Alex Schultz
___
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
[crossfire] Re: [Crossfire-cvs] CVS commit: crossfire
***
*** 1190,1199
*/
if (m-difficulty) fprintf(fp,difficulty %d\n, m-difficulty);
if (m-region) fprintf(fp,region %s\n, m-region-name);
! if (m-shopgreed) {
print_shop_string(m, shop);
fprintf(fp,shopitems %s\n, shop);
}
if (m-shopmin) fprintf(fp,shopgreed %d\n, m-shopmin);
if (m-shopmax) fprintf(fp,shopgreed %d\n, m-shopmax);
if (m-shoprace) fprintf(fp,shoprace %s\n, m-shoprace);
--- 1190,1200
*/
if (m-difficulty) fprintf(fp,difficulty %d\n, m-difficulty);
if (m-region) fprintf(fp,region %s\n, m-region-name);
! if (m-shopitems) {
print_shop_string(m, shop);
fprintf(fp,shopitems %s\n, shop);
}
+ if (m-shopgreed) fprintf(fp,shopgreed %f\n, m-shopgreed);
if (m-shopmin) fprintf(fp,shopgreed %d\n, m-shopmin);
if (m-shopmax) fprintf(fp,shopgreed %d\n, m-shopmax);
Is that code there really correct? It seems you are saving shopgreed as the
field name when you are actually saving shopmin and shopmax.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire
On 10/4/05, Mark Wedel [EMAIL PROTECTED] wrote: if (m-shopmin) fprintf(fp,shopgreed %d\n, m-shopmin); if (m-shopmax) fprintf(fp,shopgreed %d\n, m-shopmax); Is that code there really correct? It seems you are saving shopgreed as the field name when you are actually saving shopmin and shopmax. no, no it isn't, those are typos. I've fixed that now in CVS. Thanks for pointing it out. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
