From crossfire-devel at archives.real-time.com Mon Nov 1 00:16:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:15 2005 Subject: [CF-Devel] New weapons from MikeeUSA (more_ In-Reply-To: <20041030162826.82390.qmail@web61004.mail.yahoo.com> Message-ID: <20041101061644.58486.qmail@web61004.mail.yahoo.com> t_star1 kama1 sai1 brdaxe1 also snowstorm_x.arc was updated so now it works correctly. --- Mitch Obrian wrote: > 4 New weapons > Name........:Arc File.....Image File > War Axe.....: dhaxe1.arc dhaxe_1.base.111.png > Spiked Flail: sflail1.arc sflail_1.base.111.png > Scythe......: scythe1.arc scythe_1.base.111.png > Sickle......: sickle1.arc sickle_1.base.111.png > > New Treasure Lists With Appropriate Additions to > Mele: > treasures > > All available at https://cat2.ath.cx/crossfirearch/ > > Also please upload the new broze armor to CVS aswell > as the new black and white boots and gloves. > > If some need a tar of this just ask. > > (Please credit MikeeUSA in cvs if you add them) > > You can test these out on the cat2.ath.cx server. > Note: these weapons have a 1% chance of appearing. > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 1 15:53:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:15 2005 Subject: [CF-Devel] New weapons from MikeeUSA (even more) In-Reply-To: <20041101061644.58486.qmail@web61004.mail.yahoo.com> Message-ID: <20041101215321.94892.qmail@web61007.mail.yahoo.com> dhaxe2 b_axe1 (a new bronze axe) chalice2 (diffrent metal chalices) chalice_* https://cat2.ath.cx/crossfirearch/ Running on cat2.ath.cx server --- Mitch Obrian wrote: > t_star1 > kama1 > sai1 > brdaxe1 > > also snowstorm_x.arc was updated so now it works > correctly. > --- Mitch Obrian wrote: > > > 4 New weapons > > Name........:Arc File.....Image File > > War Axe.....: dhaxe1.arc dhaxe_1.base.111.png > > Spiked Flail: sflail1.arc sflail_1.base.111.png > > Scythe......: scythe1.arc scythe_1.base.111.png > > Sickle......: sickle1.arc sickle_1.base.111.png > > > > New Treasure Lists With Appropriate Additions to > > Mele: > > treasures > > > > All available at > https://cat2.ath.cx/crossfirearch/ > > > > Also please upload the new broze armor to CVS > aswell > > as the new black and white boots and gloves. > > > > If some need a tar of this just ask. > > > > (Please credit MikeeUSA in cvs if you add them) > > > > You can test these out on the cat2.ath.cx server. > > Note: these weapons have a 1% chance of appearing. > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > > protection around > > http://mail.yahoo.com > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We > finish. > http://promotions.yahoo.com/new_mail > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 1 17:50:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] New weapons from MikeeUSA (even more) In-Reply-To: <20041101215321.94892.qmail@web61007.mail.yahoo.com> References: <20041101215321.94892.qmail@web61007.mail.yahoo.com> Message-ID: <1099353017.3498.6.camel@oberon.kameria> I would like to suggest making a tar file with these arches and pictures and including a diff file for treasures if appropriate and submitting this as a patch on the SF site. This allows people to deal with submissions in a way that reduces duplication, lets us evaluate the package with less work and allows people to make comments on the SF site about it. Also keeping the packages smaller or otherwise related means they are more likely to get evaluated properly and allows for packages to be deferred for fixes while others are not impacted. I think that this has been agreed on as the way we want to manage these sort of submissions. Thanks On Mon, 2004-11-01 at 13:53 -0800, Mitch Obrian wrote: > dhaxe2 > b_axe1 (a new bronze axe) > chalice2 (diffrent metal chalices) > chalice_* > > https://cat2.ath.cx/crossfirearch/ > > Running on cat2.ath.cx server > > --- Mitch Obrian wrote: > > > t_star1 > > kama1 > > sai1 > > brdaxe1 > > > > also snowstorm_x.arc was updated so now it works > > correctly. > > --- Mitch Obrian wrote: > > > > > 4 New weapons > > > Name........:Arc File.....Image File > > > War Axe.....: dhaxe1.arc dhaxe_1.base.111.png > > > Spiked Flail: sflail1.arc sflail_1.base.111.png > > > Scythe......: scythe1.arc scythe_1.base.111.png > > > Sickle......: sickle1.arc sickle_1.base.111.png > > > > > > New Treasure Lists With Appropriate Additions to > > > Mele: > > > treasures > > > > > > All available at > > https://cat2.ath.cx/crossfirearch/ > > > > > > Also please upload the new broze armor to CVS > > aswell > > > as the new black and white boots and gloves. > > > > > > If some need a tar of this just ask. > > > > > > (Please credit MikeeUSA in cvs if you add them) > > > > > > You can test these out on the cat2.ath.cx server. > > > Note: these weapons have a 1% chance of appearing. > > > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Nov 4 20:42:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] Exit Bug (in code) Message-ID: <20041105024209.33179.qmail@web61010.mail.yahoo.com> Bug occurs when blocksview is set to 1 on a type 66 (exit) archtype: Apply does not work but middle click does due to the 'level' (as in ground, otherstuff, exit, rather than ground, exit, otherstuff) stacking being higher than it should be. found a bug that is hindering me on a blocksview exit apply dosnt work (only middle click works) the guys on the server liked the blocks view buildings The effect of having building exits (ones that are 1, 2, or 4 tiles) set to blocksview 1 is that the towns seem more immersive as you can't see over buildings (like in the real world). It was tested on the cat2 server and the players liked the effect. However the code didnt let it be applied by the command, only by middle clicking the exit. So we rest everything and need to ask assistance from the programmers now :) __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 10 01:47:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] More questions about the plugin code Message-ID: <20041110074708.GA5007@idefix2.dvlp.in-medias-res.com> I'm currently updating the Python documentation doc/Developers/python and checking that the Python functions are working. Currently, I have the following questions: - CFPython.SetQuantity() allows to set ob->nrof=0. I tried this with a random object ("cloak"), but it did not work very well: most objects did not merge anymore, other objects just disappeared after picking up or dropping. Therefore: should the function CFPython.SetQuantity() make sure that "nrof>0" or is "nrof=0" actually useful for some kind of objects? - CFPython.SetName() sets ob->name only, but I think it should set ob->name_pl as well. For example, the IPO script creates objects named "mailscroll: T: xxx F: yyy" but two of these objects are called "scrolls". I'd like to add another (optional) parameter to CFPython.SetName(): # set obj->name="single" and obj->name_pl="multiple" CFPython.SetName(obj, "single", "multiple") # set obj->name=obj->name_pl="name" CFPython.SetName(obj, "name") This solution would not break existing scripts but allows (new) scripts to generate proper plural names. - The functions CFPython.SetPreviousObject(who, what) and CFPython.SetNextObject(who, what) basically do "who->above=what" and "who->below=what". I think, this interface is (too) dangerous because it is difficult to use correctly but it allows a script to (easily) create loops in the linked list or link objects from different environments into one list. Therefore I'd like to remove (or at least disable) these functions from the Python script interface. (No existing script in maps-bigworld uses these functions.) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Nov 11 01:53:14 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] More questions about the plugin code In-Reply-To: <20041110074708.GA5007@idefix2.dvlp.in-medias-res.com> References: <20041110074708.GA5007@idefix2.dvlp.in-medias-res.com> Message-ID: <41931A6A.6010205@sonic.net> Andreas Kirschbaum wrote: > I'm currently updating the Python documentation doc/Developers/python > and checking that the Python functions are working. > > Currently, I have the following questions: > > - CFPython.SetQuantity() allows to set ob->nrof=0. I tried this with a > random object ("cloak"), but it did not work very well: most objects > did not merge anymore, other objects just disappeared after picking > up or dropping. > > Therefore: should the function CFPython.SetQuantity() make sure that > "nrof>0" or is "nrof=0" actually useful for some kind of objects? At some level, the script writers should be allowed to shoot themselves in the foot. That said, nrof of 0 is valid for some objects - this is used for objects that are not supposed to merge, like sacks for example (the number of non mergable objects tend to get lower and lower as time passes). So nrof=0 is useful for some objects. > > - CFPython.SetName() sets ob->name only, but I think it should set > ob->name_pl as well. For example, the IPO script creates objects > named "mailscroll: T: xxx F: yyy" but two of these objects are called > "scrolls". > > I'd like to add another (optional) parameter to CFPython.SetName(): > > # set obj->name="single" and obj->name_pl="multiple" > CFPython.SetName(obj, "single", "multiple") > > # set obj->name=obj->name_pl="name" > CFPython.SetName(obj, "name") > > This solution would not break existing scripts but allows (new) > scripts to generate proper plural names. That looks good to me. > > - The functions CFPython.SetPreviousObject(who, what) and > CFPython.SetNextObject(who, what) basically do > "who->above=what" and "who->below=what". > > I think, this interface is (too) dangerous because it is difficult to > use correctly but it allows a script to (easily) create loops in the > linked list or link objects from different environments into one > list. > > Therefore I'd like to remove (or at least disable) these functions > from the Python script interface. (No existing script in > maps-bigworld uses these functions.) I agree. The only case where I could really see those needed (vs just the standard insert object functions) is if the script really wanted to insert the new object above or below some specific object. That really shouldn't come up that often, and even if so, a function that does just that could be done instead. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Nov 13 10:38:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] Death message fix Message-ID: <398dd1ee0411130838445868f9@mail.gmail.com> There is a bug in the server when a should die, but does not, and a death message is displayed both to the player doing the killing and globally. Also a kill is logged, whilst it does not actualy occur. I think making sure that the player is dead before outputting the kill messages should fix the bug. I also made a quick patch that should fix the bug. What do you think of the general idea? -------------- next part -------------- A non-text attachment was scrubbed... Name: death_message.patch Type: text/x-patch Size: 5715 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20041113/707ee903/death_message.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 15 11:30:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] Death message fix In-Reply-To: <398dd1ee0411130838445868f9@mail.gmail.com> References: <398dd1ee0411130838445868f9@mail.gmail.com> Message-ID: <20041115173042.GA19424@idefix2.dvlp.in-medias-res.com> Salathar wrote: > What do you think of the general idea? The idea is good, but the solution does not work: > *** crossfire/server/attack.c 10 Sep 2004 07:03:45 -0000 1.101 > --- crossfire/server/attack.c 13 Nov 2004 16:21:01 -0000 > *************** > *** 1404,1409 **** > --- 1404,1413 ---- > */ > maxdam = dam + op->stats.hp + 1; > > + /* If we think we are killing another player and they don't die then give up */ > + if (op->type == PLAYER && !kill_player(op)) > + return 0; > + > if(QUERY_FLAG(op,FLAG_BLOCKSVIEW)) > update_all_los(op->map,op->x, op->y); /* makes sure los will be recalculated */ You call kill_player() from kill_object(). The function kill_object() records the killer in op->contr->killer (see the last few lines of that function), kill_player() uses this information to create a gravestone. Therefore (after your change), kill_player() uses a variable that is not yet set by kill_object(): You get a gravestone that reads "...who was killed by .". _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 15 13:19:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] Death message fix In-Reply-To: <20041115173042.GA19424@idefix2.dvlp.in-medias-res.com> References: <398dd1ee0411130838445868f9@mail.gmail.com> <20041115173042.GA19424@idefix2.dvlp.in-medias-res.com> Message-ID: <398dd1ee04111511195b76b09@mail.gmail.com> Andreas Kirschbaum wrote: > Salathar wrote: > > What do you think of the general idea? > > The idea is good, but the solution does not work: I've tried the patch on localhost and gravestones are generated with the killer's name as they were before applying the patch. >From what I understand kill_player attempts the kill and does all the aftereffects (creates gravestone, teleport back to last savebed). The function is called everytime the player should die and the everyone is sent the death message. However an item of lifesaving will keep the character alive and the death message should not be sent. I changed kill_player to return 0 if the player does not die and 1 if he does. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 16 02:33:19 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] Death message fix In-Reply-To: <398dd1ee04111511195b76b09@mail.gmail.com> References: <398dd1ee0411130838445868f9@mail.gmail.com> <20041115173042.GA19424@idefix2.dvlp.in-medias-res.com> <398dd1ee04111511195b76b09@mail.gmail.com> Message-ID: <20041116083319.GA16347@idefix2.dvlp.in-medias-res.com> Salathar wrote: > I've tried the patch on localhost and gravestones are generated with > the killer's name as they were before applying the patch. Strange. I applied the patch to a clean checkout and got the following gravestone: (note the missing killer name after "by") arch gravestone name test's gravestone name_pl test's gravestone msg RIP Here rests the hero test the dwarf, who was killed by . endmsg end > From what I understand kill_player attempts the kill and does all the > aftereffects (creates gravestone, teleport back to last savebed). The > function is called everytime the player should die and the everyone is > sent the death message. I think this is correct except the death message is sent from kill_object(), not from kill_player(): (about line 1530 in server/attack.c) (void) sprintf(buf,"%s killed %s%s.",hitter->name,op->name, battleg? " (duel)":""); [...] new_draw_info(NDI_ALL, op->type==PLAYER?1:10, NULL, buf); > However an item of lifesaving will keep the character alive and the death > message should not be sent. I agree, this should be changed. > I changed kill_player to return 0 if the player does not die and 1 if he > does. This is fine -- but my concerns are about the variable op->contr->killer which records the object that has killed the player "op". The application flow in the unpatched server is: 1. kill_object() gets called. It checks if the object will die, prints the death message and removes/frees the object. But if the object is a player, it does *not* remove/free him but sets op->contr->killer only. 2. do_some_living() is called for the player object and calls kill_player() if it thinks the player has died. 3. kill_player() actually kills the player and creates the gravestone. The problem I see with the patch is: step 3 is called before step 1 has set op->contr->killer to the current killer. Therefore the killer name on the gravestone is the "old" value. (No value after login or the previous killer.) _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 16 07:49:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] Death message fix In-Reply-To: <20041116083319.GA16347@idefix2.dvlp.in-medias-res.com> References: <398dd1ee0411130838445868f9@mail.gmail.com> <20041115173042.GA19424@idefix2.dvlp.in-medias-res.com> <398dd1ee04111511195b76b09@mail.gmail.com> <20041116083319.GA16347@idefix2.dvlp.in-medias-res.com> Message-ID: <398dd1ee04111605494ca2a8bc@mail.gmail.com> Andreas Kirschbaum wrote: > Strange. I applied the patch to a clean checkout and got the following > gravestone: (note the missing killer name after "by") > > arch gravestone > name test's gravestone > name_pl test's gravestone > msg > RIP > Here rests the hero test the dwarf, > who was killed > by . > endmsg > end Yes, you are perfectly right! op->contr->killer was not updated properly, I did not notice this on localhost because only the first gravestone had a name missing. All the other gravestones had names from a previous killer too. Thanks alot for pointing this out! > 1. kill_object() gets called. It checks if the object will die, > prints the death message and removes/frees the object. But if the > object is a player, it does *not* remove/free him but sets > op->contr->killer only. > > 2. do_some_living() is called for the player object and calls > kill_player() if it thinks the player has died. > > 3. kill_player() actually kills the player and creates the > gravestone. > > The problem I see with the patch is: step 3 is called before step 1 has > set op->contr->killer to the current killer. Therefore the killer name > on the gravestone is the "old" value. (No value after login or the > previous killer.) What I have done now is move death message code to the very end of kill_object() function and add the check to see if the the player did die just before it. That way all of kill_object() is executed and kill message is displayed only if kill_player() succeeds. Calling kill_player() in kill_object() makes sure the player will not regenerate hp before next call to do_some_living(). What do you think of it now? I hope I did not miss anything important out. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 16 07:52:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] Death message fix In-Reply-To: <398dd1ee04111605494ca2a8bc@mail.gmail.com> References: <398dd1ee0411130838445868f9@mail.gmail.com> <20041115173042.GA19424@idefix2.dvlp.in-medias-res.com> <398dd1ee04111511195b76b09@mail.gmail.com> <20041116083319.GA16347@idefix2.dvlp.in-medias-res.com> <398dd1ee04111605494ca2a8bc@mail.gmail.com> Message-ID: <398dd1ee04111605522adc67a4@mail.gmail.com> Here is the patch itself. -------------- next part -------------- A non-text attachment was scrubbed... Name: death_message2.patch Type: text/x-patch Size: 7389 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20041116/53465077/death_message2.bin -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 17 02:00:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:16 2005 Subject: [CF-Devel] Death message fix In-Reply-To: <398dd1ee04111605522adc67a4@mail.gmail.com> References: <398dd1ee0411130838445868f9@mail.gmail.com> <20041115173042.GA19424@idefix2.dvlp.in-medias-res.com> <398dd1ee04111511195b76b09@mail.gmail.com> <20041116083319.GA16347@idefix2.dvlp.in-medias-res.com> <398dd1ee04111605494ca2a8bc@mail.gmail.com> <398dd1ee04111605522adc67a4@mail.gmail.com> Message-ID: <20041117080034.GA24352@idefix2.dvlp.in-medias-res.com> Just a few notes (without actually testing them): > + /* These may have been set in the player code section above */ > + if (!skop) skop = hitter->chosen_skill; > + if (!skill && skop) skill=skop->skill; These lines probably should not be moved down. (The variables are used after the old code position but not needed for the death message.) > + if (op->type == PLAYER && !kill_player(op)) > + return maxdam; I'm not sure, but it seems to me that kill_object() should return -1 if op was not killed. > + * because of an item of lifesaving or because he regenerates to zero or > + * positive hp before kill_player() is called in do_some_living() This comment is valid but I think that you should try to avoid such comments: it refers to other code (far away). Therefore it probably will not be updated if the other code is changed. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 17 09:02:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] Death message fix In-Reply-To: <20041117080034.GA24352@idefix2.dvlp.in-medias-res.com> References: <398dd1ee0411130838445868f9@mail.gmail.com> <20041115173042.GA19424@idefix2.dvlp.in-medias-res.com> <398dd1ee04111511195b76b09@mail.gmail.com> <20041116083319.GA16347@idefix2.dvlp.in-medias-res.com> <398dd1ee04111605494ca2a8bc@mail.gmail.com> <398dd1ee04111605522adc67a4@mail.gmail.com> <20041117080034.GA24352@idefix2.dvlp.in-medias-res.com> Message-ID: <398dd1ee04111707027068523@mail.gmail.com> Thanks alot for commening :) > > + if (op->type == PLAYER && !kill_player(op)) > > + return maxdam; > > I'm not sure, but it seems to me that kill_object() should return -1 if > op was not killed. I wasn't quite sure either. This is the very end of the kill_object() function: /* This was return -1 - that doesn't seem correct - if we return -1, process * continues in the calling function. */ return maxdam; That's why I felt I should just leave it as it was. Searched for some more clues as to what it should be. These lines are found at the beginning of kill_object() if (op->stats.hp>=0) return -1; kill_object() is called in two places. attack.c : /* See if the creature has been killed */ rtn_kill = kill_object(op, maxdam, hitter, type); if (rtn_kill != -1) return rtn_kill; plugins.c: /*****************************************************************************/ /* kill_object wrapper. */ /*****************************************************************************/ /* 0 - killed object; */ /* 1 - damage done; */ /* 2 - killer object; */ /* 3 - type of killing. */ /*****************************************************************************/ CFParm* CFWKillObject(CFParm* PParm) { CFParm *CFP; static int val; CFP = (CFParm*)(malloc(sizeof(CFParm))); val = kill_object( (object *)(PParm->Value[0]), *(int *)(PParm->Value[1]), (object *)(PParm->Value[2]), *(int *)(PParm->Value[3]) ); CFP->Value[0] = &val; return CFP; }; This looks like what you said: kill_object() should return -1 if op is not dead _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Nov 18 15:31:00 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] Exit Bug (in code) In-Reply-To: <20041105024209.33179.qmail@web61010.mail.yahoo.com> References: <20041105024209.33179.qmail@web61010.mail.yahoo.com> Message-ID: <419D1494.8010005@laposte.net> This was submitted as bug #1066347 ( https://sourceforge.net/tracker/index.php?func=detail&aid=1066347&group_id=13833&atid=113833 ) and patch #1066665 ( https://sourceforge.net/tracker/index.php?func=detail&aid=1066665&group_id=13833&atid=313833 ). I'm ready to apply the first part of the patch, as it is a minor change (put stuff under a 'blockview' square when it's an exit). Mikeesua sent me updated archetypes (matching the big archetype diff of the patch), but there are a few arches updated, and it'll change a lot of things for player's view. So i'm asking opinion before updating arches :) Code & archetypes can be tested on Mikeeusa's server, at cat2.ath.cx Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Nov 29 21:40:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] Python Guilds Message-ID: <1101786042.6785.36.camel@oberon.kameria> Jumping on work done by Woo on Metalforge, I've been working on Python based Guild stuff for the last few weeks this has been mostly following a thread among DMs on the Metalforge DM Forum so I thought I should fire up what has been done to the list for others to take a look. Basic premise - automate much guild functions, remove keys and add more features like rankings, status and membership levels. New Guilds should be add-able entirely from the maps module. The package is not complete however much of the basic functionality is there (there is still a lot to do in the maps to fix them up so you need DM access to really play with it ATM however). The guild template was originally based on the PoisonedDagger in darcap but it will be abstracted so that guilds can be added pretty easily by copying the template and running a script to change the main exits and some script parameters. http://abraxis/games/cfstuff/python_guild_test8.tar.gz Unpack to your maps dir, it requires current CVS (espically the cfdatafile scripts) and the Python plugin (Python 2.1 or higher). If you have access to the forum -> http://www.metalforge.net/cfmb/viewtopic.php?t=692&start=0&postdays=0&postorder=asc&highlight= _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Nov 24 22:53:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] Windows Message-ID: <20041125045301.77899.qmail@web61107.mail.yahoo.com> Skipped content of type multipart/alternative-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 30 07:12:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] Windows In-Reply-To: <20041125045301.77899.qmail@web61107.mail.yahoo.com> References: <20041125045301.77899.qmail@web61107.mail.yahoo.com> Message-ID: <41AC71CA.2040404@laposte.net> Andrew Bosworth a ?crit : > I am begging someone to make an updated version of crossfire for windows > xp. I can't use the input tab anymore, which means i can't put > commands, talk, or anything. If you can help please e-mail me at > bozy_boy2005@yahoo.com . Hello. What client version are you using? What GTK version? Can you click on the command line to enter text? Or it doesn't even work? Ryo _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 30 14:36:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] AC on dragons, perhaps other races Message-ID: <41ACD9E7.5080902@telemuse.net> I've noticed with dragons, when you get past level 95~100 on clawing, you cease to add to your ac. While with other races, when they level up their attack skills, they gain more ac. perhaps this could be examined, and possibly allow for advancement in races that need it? Balancing CF is critical, because it enhances gameplay with a different race without making it too unfair. Selenium _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 30 20:40:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] Suggestion Message-ID: I think you should add an Archer class. It would make some things easier in the game for some people. _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 30 23:08:28 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] AC on dragons, perhaps other races In-Reply-To: <41ACD9E7.5080902@telemuse.net> References: <41ACD9E7.5080902@telemuse.net> Message-ID: On Tue, 30 Nov 2004, Ben Jolitz wrote: > I've noticed with dragons, when you get past level 95~100 on clawing, you > cease to add to your ac. Does the AC score depend on overall character level or their level in clawing (or other skill)? What is the maximum AC that you are talking about? > While with other races, when they level up their attack skills, they > gain more ac. IIRC, only 2 other races (fireborn and quetzalcoatl) have this capability. And, it depends on their overall level instead of a level in a particular skill. > perhaps this could be examined, and possibly allow for advancement in > races that need it? What did you have in mind for further advancement? _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 30 23:20:59 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] Suggestion In-Reply-To: References: Message-ID: There a few undocumented(?) features for using a bow. They are: bowmode Toggles arrow shooting options between normal, threewide, spreadshot, firenorth, firene, fireeast, firese, firesouth, firesw, firewest, firenw and bestarrow normal - fires one arrow in pointed direction per key stroke threewide - fires three arrows in pointed direction per key stroke, each arrow is to the left/right or top/bottom of original arrow spreadshot - fires three arrows at 45 degree angles, originating from direction the player is facing firenorth - sets the default shot direction to north, one arrow is always fired north per key stroke firene - sets the default shot direction to north east, one arrow is always fired north east per key stroke fireeast - sets the default shot direction to east, one arrow is always fired east per key stroke firese - sets the default shot direction to south east, one arrow is always fired south east per key stroke firesw - sets the default shot direction to south west, one arrow is always fired south west per key stroke firewest - sets the default shot direction to west, one arrow is always fired west per key stroke firenw - sets the default shot direction to north west, one arrow is always fired north west per key stroke bestarrow - allows the character to pick out of their quiver(s) the most effective arrow for the battle at hand; this will slow down the rate of fire and the arrow selection is not always accurate Example usage: 'bowmode firesw 'bowmode normal This option is available to any character that can wield a bow (or crossbow). On Tue, 30 Nov 2004, Michael Luttrell wrote: > I think you should add an Archer class. It would make some things easier in > the game for some people. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Nov 30 23:27:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:17 2005 Subject: [CF-Devel] AC on dragons, perhaps other races In-Reply-To: <41ACD9E7.5080902@telemuse.net> References: <41ACD9E7.5080902@telemuse.net> Message-ID: <398dd1ee04113021273d9898fd@mail.gmail.com> On Tue, 30 Nov 2004 20:36:55 +0000, Ben Jolitz wrote: > I've noticed with dragons, when you get past level 95~100 on clawing, > you cease to > add to your ac. While with other races, when they level up their attack > skills, they gain more > ac. perhaps this could be examined, and possibly allow for advancement > in races that > need it? Balancing CF is critical, because it enhances gameplay with a > different race without > making it too unfair. > Selenium My understanding is that you gain AC proportionally to your overall level. living.c lines 847-848 /* for players which cannot use armour, they gain AC -1 per 3 levels, * plus a small amount of physical resist, those poor suckers. ;) If there are suspicions that the code does not quite work as expected or one would like to suggest an alternative, it would be great help if some examples were given :) Salathar _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel