From crossfire-devel at archives.real-time.com Tue Jun 1 01:52:00 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> Message-ID: <40BC2790.60201@sonic.net> Andreas Kirschbaum wrote: > When an attempt to steal an item fails, the moved object may vanish from > the inventory view in the client. > > In server/skills.c the function attempt_steal() reads > > else if (roll < chance ) { > if (op->type == PLAYER) > esrv_del_item(op->contr, tmp->count); > pick_up(who, tmp); > > The function pick_up() may fail (for various reasons). When this > happens, the item has been removed from the inventory view but may > actually remain in the inventory. Yep. > > My attached patch tries to fix this. I tested it (player stealing from > monster into inventory or container; monster stealing from player with > or without success) but I still have some questions: The patch as provided does violate proper C - you can't legally declare new variables just anyplace - has to be at the head of a block. That is allowed in C++, and many C compilers allow various forms of C++ code. > > 1. I assume that > > for(tmp = op->inv; tmp != NULL; tmp = next) > assert(tmp->env == op); > > hold for all items in the game. > > Is this assumption correct? If not: how can I detect if the object > was actually moved? (The current "who == is_player_inv(tmp)" > does not hold for monsters stealing items, I presume.) That assertion is correct. Note that for objects on maps, env will (or should be) null. But I think the code you had in place should be fine, and is what I'll commit. > > 2. If the function pick_up() destroys the object (though don't know if > that can happen here) attempt_steal() uses this object afterwards > (as "tmp" or "success"). Is this acceptable? I'd have to dig into the code more. The only case where tmp could be 'destroyed' is if it merges with another object. It may be that pick_up covers that case, and sets tmp to that new (merged) object. > > 3. The character weight in the client does not get updated. Even the > command 'fix_me' executed from the client does not fix it. > > How should I fix this issue? Depends on the bug, as I'm not sure exactly what you are reporting. It could be: 1) Player has item stolen, but the theif can't pick it up. It disappears from the players inventory, but he still has it. In this case, no bug, as the player still has it. 2) Player steals an item successfully - now in his inventory, but his weight is not updated. 3) Player has item stolen, and theif correctly has it in his inventory, but old player still shows higher weight. Case 2 & 3 are bugs. I see that fix_player() actually doesn't fix the weight. I've updated fix_me to also recalculate the players weight. > > > ------------------------------------------------------------------------ > > Index: server/skills.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/server/skills.c,v > retrieving revision 1.51 > diff -u -w -r1.51 skills.c > --- server/skills.c 12 May 2004 04:43:06 -0000 1.51 > +++ server/skills.c 28 May 2004 19:41:19 -0000 > @@ -146,15 +146,18 @@ > if((chance=adj_stealchance(who,op,(stats_value+skill->level * 10 - op->level * 3)))==-1) > return 0; > else if (roll < chance ) { > - if (op->type == PLAYER) > - esrv_del_item(op->contr, tmp->count); > + tag_t tmp_count = tmp->count; > + > pick_up(who, tmp); > /* need to see if the player actually stole this item - > * if it is in the players inv, assume it is. This prevents > * abuses where the player can not carry the item, so just > * keeps stealing it over and over. > */ > - if (who == is_player_inv(tmp)) { > + if(was_destroyed(tmp, tmp_count) || tmp->env != op) { > + if(op->type == PLAYER) { > + esrv_del_item(op->contr, tmp_count); > + } > /* for players, play_sound: steals item */ > success = tmp; > CLEAR_FLAG(tmp, FLAG_INV_LOCKED); > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ 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 Jun 1 02:14:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:40 2005 Subject: [CF-Devel] Bug ? Automatic Pickup of Arrows and Client crash In-Reply-To: <40B2E790.4010803@sonic.net> References: <20040521135739.66f62e94.scachi@gmx.de> <200405211956.30412.tchize@myrealbox.com> <20040521230802.7cfaa6be.scachi@gmx.de> <20040522001933.6492dc21.scachi@gmx.de> <40B2E790.4010803@sonic.net> Message-ID: <40BC2CD7.1090102@sonic.net> Mark Wedel wrote: > ScaChi wrote: > >>> From what I have observed, a thrown object that hits you ends up in >>> your inventory. >> >> >> That is exactly what I tried to say. >> >> >>> Or, are you using the NEWPickup capability in the GTK client? >> >> >> No, both automatic pickup functions are disabled. > > > it is I believe an intentional feature in the code that things that are > thrown at you that hit you end up in your inventory. > > This wasn't a big deal when the only thing this happened for was arrows > (I suppose the theory being they were stuck in you). It doesn't make a > lot of sense for things like boulders. Just a note - I looked at the code, and there is already logic in place to cap such inserted objects at 5 kg. _______________________________________________ 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 Jun 1 15:05:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Resend: Scorn Sale Shop - big world - updated Message-ID: <200406011505.36310.eracclists@bellsouth.net> Apologies if this hits the list more than once. Sent on 29 May and it never showed up... --------------------------------------------------------------------- Todd, et al, The updated maps for world/world_105_115, scorn/misc/scorn.sale, world/world_104_116 and scorn/shops/generalshop are in the following file: http://www.eracc.com/files/scorn_sale_shop.zip I've made a few changes to Scorn Square and moved the buildings as requested. Anyone running a non-public server (or public if you wish) please try this out and give me feedback. TIA, Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 15:05:09 up 94 days, 9:00, 14 users, load average: 0.03, 0.05, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 1 15:06:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Resend: Navar Thaumaturgy Shop - big world - updated Message-ID: <200406011506.22783.eracclists@bellsouth.net> Apologies if this hits the list more than once. Sent on 29 May and it never showed up... --------------------------------------------------------------------- Greetings, The thaumaturgy shop in Navar (navar_city/misc/thamshop, Wizards Workshop) has an exploit for gaining huge amounts of platinum. One can buy a horn (archetype horn2) for 20 platinum, ID the horn and then sell it for 200 or more platinum. Players that know about this exploit seem to be happy to take advantage of it. The following file has a fixed map that charges 100 diamonds for the horn. After all, thaumaturgy is an expensive path to follow. :-) http://www.eracc.com/files/navar_thamshop.zip Would be nice if adding this to CVS and cf.mf.net could be expedited. Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 15:06:01 up 94 days, 9:01, 14 users, load average: 0.08, 0.06, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 1 23:10:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_Resend:_Navar_Thaumaturgy_Shop_-_big_world_-_updated?= Message-ID: I already removed the horn table from that map in CVS and closed the bug but I can look at this as a longer term solution. The reason I removed the horn table was I wanted take more time to check the recipies to make sure that it was the proper arch which would work. There is also a request for a talisman table since ther seems to be a derth of generic talismans now... I will look at the general store/pawn shop change for Scorn and I noticed a pile of map fixes in the patch system on the sourceforge site which I will test out and commit as soon as I have a minute to do so (and if it doesn't get done sooner). I liked seeing some use of the patch system on the sourceforge site - it is a good way to keep track of these sort of things IMHO. > The thaumaturgy shop in Navar (navar_city/misc/thamshop, Wizards > Workshop) has an exploit for gaining huge amounts of platinum. One > can buy a horn (archetype horn2) for 20 platinum, ID the horn and > then sell it for 200 or more platinum. Players that know about this > exploit seem to be happy to take advantage of it. The following file > has a fixed map that charges 100 diamonds for the horn. After all, > thaumaturgy is an expensive path to follow. :-) > > http://www.eracc.com/files/navar_thamshop.zip > > Would be nice if adding this to CVS and cf.mf.net could be expedited. > > Gene (poof|Galahad) > -- _______________________________________________ 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 Jun 2 02:50:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Resend: Navar Thaumaturgy Shop - big world - updated In-Reply-To: References: Message-ID: <200406020250.05707.eracclists@bellsouth.net> On Tuesday 01 June 2004 23:10 Todd Mitchell wrote: > I already removed the horn table from that map in CVS and closed > the bug but I can look at this as a longer term solution. The > reason I removed the horn table was I wanted take more time to > check the recipies to make sure that it was the proper arch which > would work. Ah! I just looked at the recipe file. All the horns call for a unicorn horn. IMO those should not be sold but found. So, the table for horns is not even needed unless you disagree. :-) > There is also a request for a talisman table since ther seems to be > a derth of generic talismans now... I'll look at putting that in the shop since I still have the file open from Saturday. Just need to find the correct archetype. > I will look at the general store/pawn shop change for Scorn Great. Thank you. > and I noticed a pile of map fixes in the patch system on the > sourceforge site which I will test out and commit as soon as I have > a minute to do so (and if it doesn't get done sooner). I liked > seeing some use of the patch system on the sourceforge site - it is > a good way to keep track of these sort of things IMHO. Didn't even know about it. I'll go take a look. Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 02:45:49 up 94 days, 20:40, 14 users, load average: 0.00, 0.02, 0.05 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 2 03:23:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Resend: Navar Thaumaturgy Shop - big world - updated In-Reply-To: <200406020250.05707.eracclists@bellsouth.net> References: <200406020250.05707.eracclists@bellsouth.net> Message-ID: <200406020323.07613.eracclists@bellsouth.net> On Wednesday 02 June 2004 02:50 ERACC wrote: > On Tuesday 01 June 2004 23:10 > Todd Mitchell wrote: > > There is also a request for a talisman table since ther seems to > > be a derth of generic talismans now... > > I'll look at putting that in the shop since I still have the file > open from Saturday. Just need to find the correct archetype. Ok, after reviewing the recipes I added three tables for purchasing talisman of evocation, pyromancy and sorcery. I made the cost 100 diamonds for each. If that is too high or too low then let me know what a proper cost should be. IMO it should be expensive to be able to just buy these amulets from a known location instead of looking for them in the various shops. I'll wait to post an updated .zip file until I hear from you about the pricing. Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 03:05:18 up 94 days, 21:00, 14 users, load average: 0.04, 0.06, 0.03 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 2 08:16:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Some points for discussion! Message-ID: <20040602131606.GA7807@kevin> Apologies for writing this so late at night. Tinkering mainly with the client, I've got some discussion items: * Late November last year, it was said that should commands like 'eat' for food or 'unwield' for weapons be made, they should go in the client. Unfortunately, the server has access to several different sorts of names (base name, short name, custom_name) for items, used in item_matched_string (arch.c line 212). The client only gets one or two 'cooked' strings. Opinions? (It's worse for 'turn' for levers; levers don't get a client_type. Perhaps guess by face?) * A minor inconsistency in script_tell (client/common/script.c:851); most things the client sends to its scripts are terminated with just "\n", but script_tell ends with "\r\n". I was going to ask about sending function bodies to a running script. I suppose I could just send * 'function_start\n' * 'function_line %s\n' * 'function_end\n' as a group, and reassemble it at the script end; then it doesn't matter if the pipes mangle line-endings. * Installing from CVS, I had to copy the various bits and pieces in lib (bmaps, faces, animations, formulae...) by hand after doing make install. Running autogen.sh, "it" complains about "invalid variables" in the doc/ and lib/ directories. (I guess I didn't notice the docs...). It might just be a version mismatch on my part (see big appendix at the end). "Invalid variables" ==================== krudat@kevin:~/fiddling/crossfire/crossfire/crossfire$ automake automake: both `configure.ac' and `configure.in' present: ignoring `configure.in' configure.ac: 8: required file `./[include/autoconf.h].in' not found configure.ac: 8: required file `./[include/stamp-h.in' not found Makefile.am:6: variable `CROSSEDIT' not defined doc/Makefile.am:29: invalid variable `dist_noinst_SCRIPTS' doc/Makefile.am:29: invalid variable `dist_noinst_SCRIPTS' doc/Makefile.am:28: invalid variable `dist_noinst_DATA' doc/playbook/Makefile.am:6: invalid variable `dist_noinst_SCRIPTS' doc/playbook/Makefile.am:6: invalid variable `dist_noinst_SCRIPTS' doc/scripts/Makefile.am:2: invalid variable `dist_noinst_SCRIPTS' doc/scripts/Makefile.am:2: invalid variable `dist_noinst_SCRIPTS' lib/Makefile.am:29: invalid variable `dist_noinst_SCRIPTS' lib/Makefile.am:77: invalid variable `dist_adm_SCRIPTS' lib/Makefile.am:29: invalid variable `dist_noinst_SCRIPTS' lib/Makefile.am:77: invalid variable `dist_adm_SCRIPTS' lib/Makefile.am:30: invalid variable `dist_pkgdata_DATA' lib/Makefile.am:55: invalid variable `dist_wizhelp_DATA' lib/Makefile.am:39: invalid variable `dist_help_DATA' utils/Makefile.am:2: invalid variable `nodist_bin_SCRIPTS' utils/Makefile.am:4: invalid variable `nodist_pkglib_SCRIPTS' utils/Makefile.am:6: invalid variable `dist_noinst_SCRIPTS' utils/Makefile.am:5: invalid variable `dist_pkglib_SCRIPTS' utils/Makefile.am:3: invalid variable `dist_bin_SCRIPTS' utils/Makefile.am:2: invalid variable `nodist_bin_SCRIPTS' utils/Makefile.am:4: invalid variable `nodist_pkglib_SCRIPTS' utils/Makefile.am:6: invalid variable `dist_noinst_SCRIPTS' utils/Makefile.am:5: invalid variable `dist_pkglib_SCRIPTS' utils/Makefile.am:3: invalid variable `dist_bin_SCRIPTS' krudat@kevin:~/fiddling/crossfire/crossfire/crossfire$ autoconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. krudat@kevin:~/fiddling/crossfire/crossfire/crossfire$ automake --version automake (GNU automake) 1.4-p6 Copyright (C) 1999, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Tom Tromey Running on Debian testing. The server otherwise runs fine. -- Thanks, -- Kevin "Third Time's an Evacuation" Rudat Has been bitten by semantics before. Sci-Fi/Fantasy ... type. Pretends to know a bit of programming. Very bad manners. Terrible posture and co-ordination. A forgetful ... wha? Humans are an example of a species rushed to life without proper testing... they have LOTS of bugs to fix. ;> _______________________________________________ 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 Jun 2 11:47:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <40BC2790.60201@sonic.net> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> <40BC2790.60201@sonic.net> Message-ID: <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> Mark Wedel wrote: > The patch as provided does violate proper C - you can't legally > declare new variables just anyplace - has to be at the head of a > block. That is allowed in C++, and many C compilers allow > various forms of C++ code. I disagree: the current Ansi C standard (C99) does indeed allow to declare new variables intermixed with "real" statements. (As well as C++ (//) comments.) Of course, Ansi C89 does not allow it. Besides this, my code declares the variable at the beginning of a block. Therefore it should be valid according to both standards. (My apologies for not using context diffs.) I tend to declare variables at the beginning of the innermost possible block. If this is not acceptable, I'll refrain from doing this and declare them at the beginning of the function. > > 3. The character weight in the client does not get updated. > > Even the command 'fix_me' executed from the client does not > > fix it. > > > > How should I fix this issue? > > Depends on the bug, as I'm not sure exactly what you are > reporting. It could be: [...] > 3) Player has item stolen, and theif correctly has it in his > inventory, but old player still shows higher weight. Case 3 does not work correctly (for player and monster interchanged): Monster steals an item successfully, item gets removed from player inventory -- you see the item disappearing from inventory view but the total player weight remains unchanged. I did ask this question (how to correctly update the player weight) to fix other places with the same bug: after eating or throwing items, the player weight does not change. _______________________________________________ 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 Jun 2 13:13:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Post subject: Godly retribution kills... Message-ID: <200406021313.40254.eracclists@bellsouth.net> Hi y'all, This is copied from the message board: http://www.metalforge.net/cfmb/viewtopic.php?t=415 > Yesterday, i thought that godly retribution was much too extreme. > Now i think it's pure nonsense. It seems that godly restributin > killed me between 5 and 17 times in 1 second ! I lost 5 billion xp > for really nothing : i was just moving around with plenty of grace > and then Whammm. > > And there is nothing to do... You spend hours and hours and hours > gaining xp, and you lose everything in a half a second, without any > monster in the level... That's REALLY not normal. Further more, as > it already happened to me, i was VERY careful with my Gr level and > always move with positive Grace. > > Az. > > PS : As i am clearly victim of injustice (or something like a bug : > the gravestone says 'killed by .') can i have my xp back ? Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 13:10:42 up 95 days, 7:05, 14 users, load average: 0.00, 0.01, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 2 13:23:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Resend: Navar Thaumaturgy Shop - big world - updated In-Reply-To: <200406020323.07613.eracclists@bellsouth.net> References: <200406020250.05707.eracclists@bellsouth.net> <200406020323.07613.eracclists@bellsouth.net> Message-ID: <200406021323.54323.eracclists@bellsouth.net> On Wednesday 02 June 2004 03:23 ERACC wrote: > Ok, after reviewing the recipes I added three tables for purchasing > talisman of evocation, pyromancy and sorcery. I made the cost 100 > diamonds for each. If that is too high or too low then let me know > what a proper cost should be. IMO it should be expensive to be able > to just buy these amulets from a known location instead of looking > for them in the various shops. > > I'll wait to post an updated .zip file until I hear from you about > the pricing. Changed my mind. I went ahead and zipped up the changed file: http://www.eracc.com/files/navar_thamshop.zip Look at it and let me know what you think. Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 13:21:36 up 95 days, 7:16, 14 users, load average: 0.10, 0.10, 0.03 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 3 01:46:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Post subject: Godly retribution kills... In-Reply-To: <200406021313.40254.eracclists@bellsouth.net> References: <200406021313.40254.eracclists@bellsouth.net> Message-ID: <40BEC951.5010201@sonic.net> ERACC wrote: > Hi y'all, > > This is copied from the message board: > > http://www.metalforge.net/cfmb/viewtopic.php?t=415 I'm guessing this happened in his apartment or wherever he last saved? Otherwise, I can't figure out how he would die multiple times. Note at least as far as that is concerned, this could happen with most any spell, eg, accidentally cast a high damage spell in your apartment, the effects could last long enough to kill you a few times. One solution to that might be to insert a short lived immunity to everything into the player when he dies (last for just a few seconds) - this would in generally allow enough time for the spell effects to finish up, but not long enough to really do much with it (and even if there is a little extra time, hard to see how it would be all that useful, or if the tradeoff for a death is worth the potential gain) In terms of the damage from the retribution - it appears the power of the retribution is based purely on the grace of the failed spell. Now there is some chance you it will allow your grace to go negative. But you could have a case where you are doing a 70 grace spell but have 60 grace, and fail the roll to sucessfully cast it. The retribution here is just as bad as if you were at -10 grace. So it may be reasonable to add some randomness in, as well as factor the current grace, eg, retribution power is something like: random(1, grace of spell - grace of player) Thus, if you were at negative grace and failed, things would be even nastier. But if you were only a few points short, no big deal. And with it being random, not necessarily a sure death in any case, which is perhaps reasonable. Nothing can really prevent accidental deaths if you hit the wrong combo of keys, but I do think dying multiple times from one spell is probably a bit excessive. _______________________________________________ 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 Jun 3 02:23:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:41 2005 Subject: [CF-Devel] Some points for discussion! In-Reply-To: <20040602131606.GA7807@kevin> References: <20040602131606.GA7807@kevin> Message-ID: <40BED1F2.5020908@sonic.net> Kevin C. Rudat wrote: > Apologies for writing this so late at night. > > Tinkering mainly with the client, I've got some discussion > items: > > * Late November last year, it was said that should commands > like 'eat' for food or 'unwield' for weapons be made, > they should go in the client. > > Unfortunately, the server has access to several different > sorts of names (base name, short name, custom_name) for items, > used in item_matched_string (arch.c line 212). > > The client only gets one or two 'cooked' strings. > > Opinions? > > (It's worse for 'turn' for levers; levers don't get a client_type. > Perhaps guess by face?) Well, client_type could perhaps get sent for those items. I most concentrated on setting client type of objects that the player picks up, so that the inventory sorting can be done sensibly. There isn't any reason that client type can't get set up for objects that aren't picked up, but that the player otherwise manipulates. Not many come to mind however. Not sure the usefulness of having specific commands to do certain things - I'm still likely to find 'apply' just more useful, but not that big an issue if other bits are added in. > > * Installing from CVS, I had to copy the various bits and pieces > in lib (bmaps, faces, animations, formulae...) by hand after > doing make install. This shouldn't be necessary - "it works for me" :) > krudat@kevin:~/fiddling/crossfire/crossfire/crossfire$ autoconf --version > autoconf (GNU Autoconf) 2.59 > Written by David J. MacKenzie and Akim Demaille. > > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. That looks reasonably up to date (I have 2.57) > krudat@kevin:~/fiddling/crossfire/crossfire/crossfire$ automake --version > automake (GNU automake) 1.4-p6 > > Copyright (C) 1999, 2001 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Written by Tom Tromey that looks pretty old - I have version 1.6.3. I'd personally suggest grabbing a later version and see if that works and fixes those automake complaints. _______________________________________________ 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 Jun 3 02:19:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:42 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> <40BC2790.60201@sonic.net> <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> Message-ID: <40BED0FA.8090704@sonic.net> Andreas Kirschbaum wrote: > Besides this, my code declares the variable at the beginning of a > block. Therefore it should be valid according to both standards. > (My apologies for not using context diffs.) Ok - maybe I didn't look closely enough. > > I tend to declare variables at the beginning of the innermost > possible block. If this is not acceptable, I'll refrain from doing > this and declare them at the beginning of the function. That is fine - declaring variables at the top of blocks is generally not a problem, but if you were doing something like: if ... { int i; .... } else { int i; .. } I'd just assume that int i be declared once at the top. >>3) Player has item stolen, and theif correctly has it in his >>inventory, but old player still shows higher weight. > > > Case 3 does not work correctly (for player and monster > interchanged): Monster steals an item successfully, item gets > removed from player inventory -- you see the item disappearing > from inventory view but the total player weight remains unchanged. > > I did ask this question (how to correctly update the player > weight) to fix other places with the same bug: after eating or > throwing items, the player weight does not change. I think the real problem here isn't that the players weight isn't getting updated, but rather that information isn't getting communicated to the client. Looking at how weight is handled for hte player, I can see why - basically, explicit calls to say 'update the weight' need to be made. This actually makes sense, because it deals with containers. The problem seems to be that remove_ob doesn't make that call to update the players weight, or adjust weight at all. This is probably because the caller is presumed to do that. Not it surprises me that the eating code would have the same issue - if decrease_ob_nr is called, that will do the work of updating the players weight. But the fix here is to just add lines like: esrv_update_item(UPD_WEIGHT, pl, pl); It might actually make more sense to treat the weight like any of the other stats (at least player weight), store the last value we sent, and send again if different instead of having these explicit calls. _______________________________________________ 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 Jun 3 15:06:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:42 2005 Subject: [CF-Devel] Random things & bugs :) Message-ID: <40BF84D3.2050306@laposte.net> Hello. First, a player reported (and i tested) a bug concerning writing glyphes/runes/... If you do 'invoke sigil cancellation', you get the message 'you can't cast protection from cancellation with sigil!'. The code gets the first matching spell, 'protection from cancellation', instead of the best match 'cancellation'. On the message board, some players suggested reducing death penalty for non combat skill (literacy, alchemy, inscription, jewelery, ...). The main reason is that you need a *lot* of time to level in those compared to combat skills like one handed weapons & such. What do you think? Nicolas '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 Fri Jun 4 16:28:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:42 2005 Subject: [CF-Devel] Map stuff - deities - inventory checking Message-ID: <200406041628.17510.eracclists@bellsouth.net> Greetings developers, There is a discussion on the web forums about map design and being able to deny access to an area based on one's deity. http://www.metalforge.net/cfmb/viewtopic.php?t=418 Is there anything in a player's inventory that indicates which deity s/he follows? I know about "valriel's light" but can't find anything I can rely on for each deity. If there is something for each deity then point me in the correct direction. If there is nothing then how difficult would it be to add an inventory item that states the deity a player follows? Something like "follows_foo" or "praysto_bar" that is added when the player prays over an altar. This could be checked with an inventory check to allow and/or deny access to an area or otherwise modify a players experiences. TIA Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 16:17:32 up 97 days, 10:12, 14 users, load average: 0.00, 0.05, 0.02 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Fri Jun 4 21:54:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:42 2005 Subject: [CF-Devel] Post subject: Godly retribution kills... In-Reply-To: <40BEC951.5010201@sonic.net> References: <200406021313.40254.eracclists@bellsouth.net> <40BEC951.5010201@sonic.net> Message-ID: Somebdy mentioned on IRC .. that spell failure effects (sh?)could check and see if the square is damned, if it is then the godly retribution or mana backlash stops. On Wed, 2 Jun 2004, Mark Wedel wrote: > ERACC wrote: > > Hi y'all, > > > > This is copied from the message board: > > > > http://www.metalforge.net/cfmb/viewtopic.php?t=415 > > I'm guessing this happened in his apartment or wherever he last saved? > Otherwise, I can't figure out how he would die multiple times. > > Note at least as far as that is concerned, this could happen with most any > spell, eg, accidentally cast a high damage spell in your apartment, the effects > could last long enough to kill you a few times. > > One solution to that might be to insert a short lived immunity to everything > into the player when he dies (last for just a few seconds) - this would in > generally allow enough time for the spell effects to finish up, but not long > enough to really do much with it (and even if there is a little extra time, hard > to see how it would be all that useful, or if the tradeoff for a death is worth > the potential gain) _______________________________________________ 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 Fri Jun 4 22:19:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:42 2005 Subject: [CF-Devel] DM - God Finger - bleah! In-Reply-To: <40BABAE1.7040704@sonic.net> References: <40BABAE1.7040704@sonic.net> Message-ID: A later conversation on IRC: dm;patch [DM_name] alive 0;patch [DM_name] no_pick 1 Note: dm;patch [DM_name] no_pass 0;patch [DM_name] alive 0 will work, but a player stepping on the DM and trying to pick them up will result in a "It must have been an illusion", combined with the DM disappearing, and dropping all of his equipment. Item number 0, and other nastiness. Creatures will also try and attack the DM now, but won't deal any damage. Can't say the same for nearby players, monsters, items, etc. On Sun, 30 May 2004, Mark Wedel wrote: > As far as blocking players - the DM is a living creature, and thus when it > goes to check if the space is blocked, it sees there is a living creature there, > and then finds that there is the DM. > > This may be simpler to fix - the update_space() code (or is it > update_position()) could be modified - if the creature is a player, and has DM > set, don't set the flags for that space. However, I'm not 100% if that will fix > everything - monsters may still be able to 'find' the DM, because they search > the list of players for nearby players (as a shortcut of searching all the > spaces). That could certainly get changed to skip DM's, etc, but there might be > lots of bits like that. _______________________________________________ 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 Jun 5 06:27:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:42 2005 Subject: [CF-Devel] Charm monster exploit Message-ID: <40C1AE37.6030203@laposte.net> Hello. Charm monster *always* works. It seems monsters just get charmed, whatever their level. I was level 10 and could charm Ancient Red Dragons, or dragonmen lol. Looking in the code, in spell_attack.c:mood_change (i think that's what is called?), there's a if (did_make_save(head, head->level, at)) continue; but i think values aren't really correctly made. I don't know the best way to fix, so i'm asking others :) I'd see something like singing for the chance to calm down, based on respective levels. Nicolas '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 Sat Jun 5 08:33:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:43 2005 Subject: [CF-Devel] Map stuff - deities - inventory checking In-Reply-To: <200406041628.17510.eracclists@bellsouth.net> References: <200406041628.17510.eracclists@bellsouth.net> Message-ID: <1086442398.40c1cb9e1e650@webmail.montevideo.com.uy> hi all, iirc it is the race of the praying skill or it's name, dont have the game here to check it out sorry :) -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ Mensaje citado por ERACC : > Is there anything in a player's inventory that indicates which deity > s/he follows? ------------------------------------------------------------ Ahora el ADSL de Montevideo COMM es hasta 4 veces mas rapido ADSL 256K / 64K -- $ 1039 + I.V.A. http://www.montevideo.net.uy/hnnoticiaj1.cgi?22 _______________________________________________ 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 Jun 5 11:17:04 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:43 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <40BED0FA.8090704@sonic.net> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> <40BC2790.60201@sonic.net> <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> <40BED0FA.8090704@sonic.net> Message-ID: <20040605161704.GA19176@idefix2.dvlp.in-medias-res.com> Mark Wedel wrote: > It might actually make more sense to treat the weight like any > of the other stats (at least player weight), store the last > value we sent, and send again if different instead of having > these explicit calls. Here is a diff that should do this. I declared the function pay_from_container() as "static" since it is called from nowhere else. In addition I removed the parameter "object *op" since it is unused. The use of the magic value "last_weight==(uint32)-1" was necessary to delay sending "upditem" commands until the player object has been sent ("player" and "item" commands). To check (and document) implicit assumptions, I use assert() statements. Since these statements are basically not used elsewhere, I'm not sure if I should remove these statements. -------------- next part -------------- Index: common/item.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/item.c,v retrieving revision 1.44 diff -w -c -5 -r1.44 item.c *** common/item.c 4 May 2004 07:14:53 -0000 1.44 --- common/item.c 5 Jun 2004 16:01:56 -0000 *************** *** 235,252 **** return buf; } /* * query_weight(object) returns a character pointer to a static buffer * containing the text-representation of the weight of the given object. * The buffer will be overwritten by the next call to query_weight(). */ char *query_weight(object *op) { static char buf[10]; ! int i=op->nrof?op->nrof*op->weight:op->weight+op->carrying; if(op->weight<0) return " "; if(i%1000) sprintf(buf,"%6.1f",i/1000.0); --- 235,260 ---- return buf; } /* + * get_weight(object) returns the weight of the given object. + */ + sint32 get_weight(const object *op) { + return op->nrof ? op->weight : op->weight+op->carrying; + } + + + /* * query_weight(object) returns a character pointer to a static buffer * containing the text-representation of the weight of the given object. * The buffer will be overwritten by the next call to query_weight(). */ char *query_weight(object *op) { static char buf[10]; ! sint32 i=op->nrof?op->nrof*op->weight:op->weight+op->carrying; if(op->weight<0) return " "; if(i%1000) sprintf(buf,"%6.1f",i/1000.0); Index: common/object.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/object.c,v retrieving revision 1.87 diff -w -c -5 -r1.87 object.c *** common/object.c 18 May 2004 16:11:52 -0000 1.87 --- common/object.c 5 Jun 2004 16:01:56 -0000 *************** *** 1641,1658 **** if (i < op->nrof) { sub_weight (op->env, op->weight * i); op->nrof -= i; if (tmp) { (*esrv_send_item_func) (tmp, op); - (*esrv_update_item_func) (UPD_WEIGHT, tmp, tmp); } } else { remove_ob (op); op->nrof = 0; if (tmp) { (*esrv_del_item_func) (tmp->contr, op->count); - (*esrv_update_item_func) (UPD_WEIGHT, tmp, tmp); } } } else { --- 1641,1656 ---- Index: include/libproto.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/libproto.h,v retrieving revision 1.56 diff -w -c -5 -r1.56 libproto.h *** include/libproto.h 28 Apr 2004 22:04:09 -0000 1.56 --- include/libproto.h 5 Jun 2004 16:01:56 -0000 *************** *** 135,144 **** --- 135,145 ---- extern void init_attackmess(void); /* item.c */ extern int get_power_from_ench(int ench); extern int calc_item_power(object *op, int flag); extern char *describe_resistance(object *op, int newline); + extern sint32 get_weight(const object *op); extern char *query_weight(object *op); extern char *get_levelnumber(int i); extern char *get_number(int i); extern char *ring_desc(object *op); extern char *query_short_name(object *op); Index: include/player.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/player.h,v retrieving revision 1.35 diff -w -c -5 -r1.35 player.h *** include/player.h 16 Feb 2004 18:05:32 -0000 1.35 --- include/player.h 5 Jun 2004 16:01:56 -0000 *************** *** 135,144 **** --- 135,145 ---- sint64 last_skill_exp[NUM_SKILLS]; /* shadow register. if != exp. obj update client */ float weapon_sp; /* Penalties to speed when fighting w speed >ws/10*/ float last_weapon_sp; /* if diff than weapon_sp, update client */ uint16 last_flags; /* fire/run on flags for last tick */ + uint32 last_weight; /* Last weight as sent to client; (uint32)-1 means do not send weight */ uint32 last_weight_limit; /* Last weight limit transmitted to client */ living orig_stats; /* Permanent real stats of player */ living last_stats; /* Last stats as sent to client */ float last_speed; /* Last speed as sent to client */ sint16 last_resist[NROFATTACKS]; /* last resist values sent to client */ Index: include/sproto.h =================================================================== RCS file: /cvsroot/crossfire/crossfire/include/sproto.h,v retrieving revision 1.106 diff -w -c -5 -r1.106 sproto.h *** include/sproto.h 24 May 2004 21:00:16 -0000 1.106 --- include/sproto.h 5 Jun 2004 16:01:56 -0000 *************** *** 626,636 **** char *cost_string_from_value(uint64 cost); char *query_cost_string(object *tmp, object *who, int flag); uint64 query_money(object *op); int pay_for_amount(int to_pay, object *pl); int pay_for_item(object *op, object *pl); - uint64 pay_from_container(object *op, object *pouch, int to_pay); int get_payment(object *pl, object *op); void sell_item(object *op, object *pl); void shop_listing(object *op); /* skills.c */ int steal(object *op, int dir, object *skill); --- 626,635 ---- Index: server/attack.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/attack.c,v retrieving revision 1.98 diff -w -c -5 -r1.98 attack.c *** server/attack.c 4 May 2004 07:14:53 -0000 1.98 --- server/attack.c 5 Jun 2004 16:01:56 -0000 *************** *** 190,200 **** if (op->env) { object *tmp= is_player_inv(op->env); if (tmp) { esrv_del_item(tmp->contr, op->count); - esrv_update_item(UPD_WEIGHT, tmp, tmp); } } if ( ! QUERY_FLAG (op, FLAG_REMOVED)) remove_ob(op); free_object(op); --- 190,199 ---- Index: server/c_object.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/c_object.c,v retrieving revision 1.57 diff -w -c -5 -r1.57 c_object.c *** server/c_object.c 26 Apr 2004 05:07:52 -0000 1.57 --- server/c_object.c 5 Jun 2004 16:01:57 -0000 *************** *** 629,642 **** */ if(pl->type!=PLAYER) return; esrv_send_item (pl, tmp); /* These are needed to update the weight for the container we ! * are putting the object in, and the players weight, if different. */ esrv_update_item (UPD_WEIGHT, pl, op); ! if (op!=pl) esrv_send_item (pl, pl); /* Update the container the object was in */ if (env && env!=pl && env!=op) esrv_update_item (UPD_WEIGHT, pl, env); } --- 629,644 ---- */ if(pl->type!=PLAYER) return; esrv_send_item (pl, tmp); /* These are needed to update the weight for the container we ! * are putting the object in. */ + if (op!=pl) { esrv_update_item (UPD_WEIGHT, pl, op); ! esrv_send_item (pl, pl); ! } /* Update the container the object was in */ if (env && env!=pl && env!=op) esrv_update_item (UPD_WEIGHT, pl, env); } *************** *** 891,903 **** */ if (tmp2 != tmp) esrv_del_item (op->contr, tmp_tag); esrv_send_item (op, tmp2); ! /* update the sacks and players weight */ esrv_update_item (UPD_WEIGHT, op, sack); - esrv_update_item (UPD_WEIGHT, op, op); } /* * This function was part of drop, now is own function. * Player 'op' tries to drop object 'tmp', if tmp is non zero, then --- 893,904 ---- */ if (tmp2 != tmp) esrv_del_item (op->contr, tmp_tag); esrv_send_item (op, tmp2); ! /* update the sacks weight */ esrv_update_item (UPD_WEIGHT, op, sack); } /* * This function was part of drop, now is own function. * Player 'op' tries to drop object 'tmp', if tmp is non zero, then Index: server/login.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/login.c,v retrieving revision 1.46 diff -w -c -5 -r1.46 login.c *** server/login.c 12 Mar 2004 19:04:15 -0000 1.46 --- server/login.c 5 Jun 2004 16:01:57 -0000 *************** *** 700,709 **** --- 700,712 ---- * the data isn't needed. */ esrv_new_player(op->contr,op->weight+op->carrying); esrv_send_inventory(op, op); + op->contr->last_weight = 0; /* set to incorrect weight, so esrv_update_item will send correct value */ + esrv_update_item(UPD_WEIGHT, op, op); + CLEAR_FLAG(op, FLAG_FRIENDLY); /* can_use_shield is a new flag. However, the can_use.. seems to largely come * from the class, and not race. I don't see any way to get the class information * to then update this. I don't think this will actually break anything - anyone Index: server/player.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/player.c,v retrieving revision 1.150 diff -w -c -5 -r1.150 player.c *** server/player.c 16 Apr 2004 06:23:44 -0000 1.150 --- server/player.c 5 Jun 2004 16:01:57 -0000 *************** *** 204,213 **** --- 204,214 ---- } for (i=0; i < NROFATTACKS; i++) { p->last_resist[i] = -1; } p->last_stats.exp = -1; + p->last_weight = (uint32)-1; p->socket.update_look=0; p->socket.look_position=0; return p; } *************** *** 2828,2838 **** for (pl = first_player; pl != NULL; pl = pl->next) { int old = pl->ob->carrying, sum = sum_weight(pl->ob); if(old == sum) continue; fix_player(pl->ob); - esrv_update_item(UPD_WEIGHT, pl->ob, pl->ob); LOG(llevDebug,"Fixed inventory in %s (%d -> %d)\n", pl->ob->name, old, sum); } } --- 2829,2838 ---- Index: server/shop.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/shop.c,v retrieving revision 1.30 diff -w -c -5 -r1.30 shop.c *** server/shop.c 6 May 2004 07:04:23 -0000 1.30 --- server/shop.c 5 Jun 2004 16:01:57 -0000 *************** *** 24,43 **** --- 24,47 ---- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. The authors can be reached via e-mail at crossfire-devel@real-time.com */ + #include #include #include #include #include #include #ifndef __CEXTRACT__ #include #endif + static uint64 pay_from_container(object *pouch, uint64 to_pay); + + #define NUM_COINS 3 /* number of coin types */ static char *coins[] = {"platinacoin", "goldcoin", "silvercoin", NULL}; /* Added F_TRUE flag to define.h to mean that the price should not * be adjusted by players charisma. With F_TRUE, it returns the amount *************** *** 333,349 **** object *pouch; if (to_pay==0) return 1; if (to_pay > query_money(pl)) return 0; ! to_pay = pay_from_container(NULL, pl, to_pay); for (pouch=pl->inv; (pouch!=NULL) && (to_pay>0); pouch=pouch->below) { if (pouch->type == CONTAINER && QUERY_FLAG(pouch, FLAG_APPLIED) && (pouch->race == NULL || strstr(pouch->race, "gold"))) { ! to_pay = pay_from_container(NULL, pouch, to_pay); } } fix_player(pl); return 1; } --- 337,353 ---- object *pouch; if (to_pay==0) return 1; if (to_pay > query_money(pl)) return 0; ! to_pay = pay_from_container(pl, to_pay); for (pouch=pl->inv; (pouch!=NULL) && (to_pay>0); pouch=pouch->below) { if (pouch->type == CONTAINER && QUERY_FLAG(pouch, FLAG_APPLIED) && (pouch->race == NULL || strstr(pouch->race, "gold"))) { ! to_pay = pay_from_container(pouch, to_pay); } } fix_player(pl); return 1; } *************** *** 368,384 **** saved_money = query_cost(op,pl,F_BUY | F_NO_BARGAIN) - to_pay; if (saved_money > 0) change_exp(pl,saved_money,"bargaining",SK_EXP_NONE); ! to_pay = pay_from_container(op, pl, to_pay); for (pouch=pl->inv; (pouch!=NULL) && (to_pay>0); pouch=pouch->below) { if (pouch->type == CONTAINER && QUERY_FLAG(pouch, FLAG_APPLIED) && (pouch->race == NULL || strstr(pouch->race, "gold"))) { ! to_pay = pay_from_container(op, pouch, to_pay); } } if (settings.real_wiz == FALSE && QUERY_FLAG(pl, FLAG_WAS_WIZ)) SET_FLAG(op, FLAG_WAS_WIZ); fix_player(pl); --- 372,388 ---- saved_money = query_cost(op,pl,F_BUY | F_NO_BARGAIN) - to_pay; if (saved_money > 0) change_exp(pl,saved_money,"bargaining",SK_EXP_NONE); ! to_pay = pay_from_container(pl, to_pay); for (pouch=pl->inv; (pouch!=NULL) && (to_pay>0); pouch=pouch->below) { if (pouch->type == CONTAINER && QUERY_FLAG(pouch, FLAG_APPLIED) && (pouch->race == NULL || strstr(pouch->race, "gold"))) { ! to_pay = pay_from_container(pouch, to_pay); } } if (settings.real_wiz == FALSE && QUERY_FLAG(pl, FLAG_WAS_WIZ)) SET_FLAG(op, FLAG_WAS_WIZ); fix_player(pl); *************** *** 391,403 **** * with weight not be subtracted properly. We now remove and * insert the coin objects - this should update the weight * appropriately * * DAMN: This function is used for the player, then for any active ! * containers that can hold money, until the op is paid for. */ ! uint64 pay_from_container(object *op, object *pouch, int to_pay) { int count, i; sint64 remain; object *tmp, *coin_objs[NUM_COINS], *next; archetype *at; object *who; --- 395,411 ---- * with weight not be subtracted properly. We now remove and * insert the coin objects - this should update the weight * appropriately * * DAMN: This function is used for the player, then for any active ! * containers that can hold money. ! * ! * pouch is the container (pouch or player) to remove the coins from. ! * to_pay is the required amount. ! * returns the amount still missing after using "pouch". */ ! static uint64 pay_from_container(object *pouch, uint64 to_pay) { int count, i; sint64 remain; object *tmp, *coin_objs[NUM_COINS], *next; archetype *at; object *who; *************** *** 475,490 **** } for (i=0; inrof) { object *tmp = insert_ob_in_ob(coin_objs[i], pouch); for (who = pouch; who && who->type!=PLAYER && who->env!=NULL; who=who->env) ; esrv_send_item(who, tmp); esrv_send_item (who, pouch); ! esrv_update_item (UPD_WEIGHT, who, pouch); if (pouch->type != PLAYER) { esrv_send_item (who, who); - esrv_update_item (UPD_WEIGHT, who, who); } } else { free_object(coin_objs[i]); } } --- 483,498 ---- } for (i=0; inrof) { object *tmp = insert_ob_in_ob(coin_objs[i], pouch); for (who = pouch; who && who->type!=PLAYER && who->env!=NULL; who=who->env) ; + assert(who != NULL && who->type == PLAYER); esrv_send_item(who, tmp); esrv_send_item (who, pouch); ! if(who != pouch) esrv_update_item (UPD_WEIGHT, who, pouch); if (pouch->type != PLAYER) { esrv_send_item (who, who); } } else { free_object(coin_objs[i]); } } *************** *** 611,621 **** tmp = insert_ob_in_ob(tmp, pouch); esrv_send_item (pl, tmp); esrv_send_item (pl, pouch); esrv_update_item (UPD_WEIGHT, pl, pouch); esrv_send_item (pl, pl); - esrv_update_item (UPD_WEIGHT, pl, pl); } } } if (i/at->clone.value > 0) { tmp = get_object(); --- 619,628 ---- *************** *** 623,633 **** tmp->nrof = i/tmp->value; i -= (uint64)tmp->nrof * (uint64)tmp->value; tmp = insert_ob_in_ob(tmp, pl); esrv_send_item (pl, tmp); esrv_send_item (pl, pl); - esrv_update_item (UPD_WEIGHT, pl, pl); } } } if (i!=0) --- 630,639 ---- Index: socket/item.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/socket/item.c,v retrieving revision 1.28 diff -w -c -5 -r1.28 item.c *** socket/item.c 11 Feb 2004 08:09:29 -0000 1.28 --- socket/item.c 5 Jun 2004 16:01:57 -0000 *************** *** 52,64 **** * * Functions related to sending object data to the client. * ******************************************************************************/ - /** This is more or less stolen from the query_weight function. */ - #define WEIGHT(op) (op->nrof?op->weight:op->weight+op->carrying) - /** * Adds string to socklist. * * This is a simple function that we use a lot here. It basically * adds the specified buffer into the socklist, but prepends a --- 52,61 ---- *************** *** 225,235 **** !pl->contr->socket.anims_sent[tmp->animation_id]) esrv_send_animation(&pl->contr->socket, tmp->animation_id); SockList_AddInt(&sl, tmp->count); SockList_AddInt(&sl, flags); ! SockList_AddInt(&sl, QUERY_FLAG(tmp, FLAG_NO_PICK) ? -1 : WEIGHT(tmp)); SockList_AddInt(&sl, tmp->face->number); if (!tmp->custom_name) { strncpy(item_n,query_base_name(tmp, 0),127); item_n[127]=0; --- 222,232 ---- !pl->contr->socket.anims_sent[tmp->animation_id]) esrv_send_animation(&pl->contr->socket, tmp->animation_id); SockList_AddInt(&sl, tmp->count); SockList_AddInt(&sl, flags); ! SockList_AddInt(&sl, QUERY_FLAG(tmp, FLAG_NO_PICK) ? -1 : get_weight(tmp)); SockList_AddInt(&sl, tmp->face->number); if (!tmp->custom_name) { strncpy(item_n,query_base_name(tmp, 0),127); item_n[127]=0; *************** *** 315,325 **** if (QUERY_FLAG(tmp,FLAG_ANIMATE) && !pl->contr->socket.anims_sent[tmp->animation_id]) esrv_send_animation(&pl->contr->socket, tmp->animation_id); SockList_AddInt(&sl, tmp->count); SockList_AddInt(&sl, flags); ! SockList_AddInt(&sl, QUERY_FLAG(tmp, FLAG_NO_PICK) ? -1 : WEIGHT(tmp)); SockList_AddInt(&sl, tmp->face->number); if (!tmp->custom_name) { strncpy(item_n,query_base_name(tmp, 0),127); item_n[127]=0; --- 312,322 ---- if (QUERY_FLAG(tmp,FLAG_ANIMATE) && !pl->contr->socket.anims_sent[tmp->animation_id]) esrv_send_animation(&pl->contr->socket, tmp->animation_id); SockList_AddInt(&sl, tmp->count); SockList_AddInt(&sl, flags); ! SockList_AddInt(&sl, QUERY_FLAG(tmp, FLAG_NO_PICK) ? -1 : get_weight(tmp)); SockList_AddInt(&sl, tmp->face->number); if (!tmp->custom_name) { strncpy(item_n,query_base_name(tmp, 0),127); item_n[127]=0; *************** *** 415,426 **** SockList_AddInt(&sl, op->env? op->env->count:0); if (flags & UPD_FLAGS) SockList_AddInt(&sl, query_flags(op)); ! if (flags & UPD_WEIGHT) ! SockList_AddInt(&sl, WEIGHT(op)); if (flags & UPD_FACE) { if (!pl->contr->socket.faces_sent[op->face->number]) esrv_send_face(&pl->contr->socket, op->face->number,0); SockList_AddInt(&sl, op->face->number); --- 412,428 ---- SockList_AddInt(&sl, op->env? op->env->count:0); if (flags & UPD_FLAGS) SockList_AddInt(&sl, query_flags(op)); ! if (flags & UPD_WEIGHT) { ! sint32 weight = get_weight(op); ! SockList_AddInt(&sl, weight); ! if (pl == op) { ! op->contr->last_weight = weight; ! } ! } if (flags & UPD_FACE) { if (!pl->contr->socket.faces_sent[op->face->number]) esrv_send_face(&pl->contr->socket, op->face->number,0); SockList_AddInt(&sl, op->face->number); *************** *** 508,518 **** !pl->contr->socket.anims_sent[op->animation_id]) esrv_send_animation(&pl->contr->socket, op->animation_id); SockList_AddInt(&sl, op->count); SockList_AddInt(&sl, query_flags(op)); ! SockList_AddInt(&sl, WEIGHT(op)); SockList_AddInt(&sl, op->face->number); if(!op->custom_name) { strncpy(item_n,query_base_name(op, 0),127); item_n[127]=0; --- 510,520 ---- !pl->contr->socket.anims_sent[op->animation_id]) esrv_send_animation(&pl->contr->socket, op->animation_id); SockList_AddInt(&sl, op->count); SockList_AddInt(&sl, query_flags(op)); ! SockList_AddInt(&sl, get_weight(op)); SockList_AddInt(&sl, op->face->number); if(!op->custom_name) { strncpy(item_n,query_base_name(op, 0),127); item_n[127]=0; Index: socket/loop.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/socket/loop.c,v retrieving revision 1.26 diff -w -c -5 -r1.26 loop.c *** socket/loop.c 2 Dec 2003 18:51:44 -0000 1.26 --- socket/loop.c 5 Jun 2004 16:01:57 -0000 *************** *** 37,46 **** --- 37,47 ---- * maintenance (checking for lost connections and if data has arrived.) * The reading of data is handled in ericserver.c */ + #include #include #ifndef __CEXTRACT__ #include #include #endif *************** *** 656,665 **** --- 657,670 ---- /* Update the players stats once per tick. More efficient than * sending them whenever they change, and probably just as useful */ esrv_update_stats(pl); + if (pl->last_weight != (uint32)-1 && pl->last_weight != get_weight(pl->ob)) { + esrv_update_item(UPD_WEIGHT, pl->ob, pl->ob); + assert(pl->last_weight == get_weight(pl->ob)); + } if (pl->ob->map && pl->ob->map->in_memory==MAP_IN_MEMORY) draw_client_map(pl->ob); if (pl->socket.update_look) esrv_draw_look(pl->ob); } } -------------- 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 Sat Jun 5 22:57:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:43 2005 Subject: [CF-Devel] Found possible cause for server hang Message-ID: In the past couple of days, crossfire.metalforge.net server has hung at what appears to be random intervals. Looking at the log files before I've had to manually kill and restart the server, I noticed some similarities in 3 different log files. Anyone have any insight or recommendations? Trying to load map /home/crossfire/share/crossfire/maps/random/world_105_0468. load_original_map: /random/world_105_0468 (0) Can't open /home/crossfire/share/crossfire/maps/random/world_105_0468 Can't read map file: No such file or directory load_original_map: /styles/doorstyles/hdoors (8) Can't open /home/crossfire/share/crossfire/maps/styles/doorstyles/hdoors - not a regular file Can't open /home/crossfire/share/crossfire/maps/styles/doorstyles/hdoors Can't read map file: Is a directory load_original_map: /styles/exitstyles/generic/tree (8) Couldn't find archetype archway_tree load_original_map: /styles/doorstyles/special (8) Can't open /home/crossfire/share/crossfire/maps/styles/doorstyles/special - not a regular file Can't open /home/crossfire/share/crossfire/maps/styles/doorstyles/special Can't read map file: Is a directory load_original_map: /styles/exitstyles/generic/archway (8) Couldn't find archetype archway_gold Couldn't find archetype archway_green Couldn't find archetype archway load_original_map: /styles/exitstyles/generic/archway (8) Couldn't find archetype archway_gold Couldn't find archetype archway_green Couldn't find archetype archway -- _______________________________________________ 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 Sun Jun 6 03:09:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:43 2005 Subject: [CF-Devel] Path: party gsay improvment Message-ID: <40C2D14F.6090907@laposte.net> Hello. Katia/Karla can't easily access the net lately, so she asked me to send a patch for her. It's some tweaks for the 'gsay' command. Looks fine to me, i'd have committed it but she seems to prefer sending it to mailing list for approval, so here it is :) Nicolas -------------- next part -------------- Index: server/c_party.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/c_party.c,v retrieving revision 1.6 diff -u -r1.6 c_party.c --- server/c_party.c 13 Sep 2003 05:02:08 -0000 1.6 +++ server/c_party.c 6 Jun 2004 08:06:38 -0000 @@ -156,7 +156,7 @@ int no=op->contr->party_number; for(pl=first_player;pl!=NULL;pl=pl->next) if(pl->ob->contr->party_number==no && pl->ob!=op) - new_draw_info(NDI_UNIQUE, NDI_WHITE, pl->ob, msg); + new_draw_info_format(NDI_WHITE, 0, pl->ob, msg); } int command_gsay(object *op, char *params) @@ -255,17 +255,18 @@ #endif /* PARTY_KILL_LOG */ if(strncmp(params, "say ", 4)==0) { - if(op->contr->party_number<=0) + if(op->contr->party_number<=0) { new_draw_info(NDI_UNIQUE, 0,op,"You are not a member of any party."); return 1; } - params += 4; - sprintf(buf, "%s says: %s", op->name, params); - send_party_message(op,buf); - new_draw_info(NDI_UNIQUE, 0,op,"Ok."); - return 1; - } + params += 4; + currentparty = find_party(op->contr->party_number,firstparty); + snprintf(buf,MAX_BUF-1, "[%s] %s says: %s", currentparty, op->name, params); + send_party_message(op,buf); + new_draw_info_format(NDI_WHITE, 0,op,"[%s] You say: %s", currentparty, params); + return 1; + } if(strncmp(params, "form ",5) == 0) { -------------- 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 Sun Jun 6 08:45:44 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:43 2005 Subject: [CF-Devel] Path: party gsay improvment In-Reply-To: <40C2D14F.6090907@laposte.net> References: <40C2D14F.6090907@laposte.net> Message-ID: <20040606134544.GA22259@idefix2.dvlp.in-medias-res.com> I suppose there is a bug in this patch: > @@ -156,7 +156,7 @@ > int no=op->contr->party_number; > for(pl=first_player;pl!=NULL;pl=pl->next) > if(pl->ob->contr->party_number==no && pl->ob!=op) > - new_draw_info(NDI_UNIQUE, NDI_WHITE, pl->ob, msg); > + new_draw_info_format(NDI_WHITE, 0, pl->ob, msg); > } > > int command_gsay(object *op, char *params) It should be + new_draw_info_format(NDI_WHITE, 0, pl->ob, "%s", msg); ^^^^ to prevent problems with messages that contain '%' characters. _______________________________________________ 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 Sun Jun 6 11:23:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:43 2005 Subject: [CF-Devel] Found possible cause for server hang In-Reply-To: References: Message-ID: <1086539037.2768.76.camel@oberon.kameria> The archways are new in CVS so a arch collect should fix the 'Couldn't find archetype' messages. Not sure why the server is hanging however. I have noticed that when using single arch wall types on random maps that there is a slight pause while the server looks for all the other wall arches in the set (e.g. tree_3_4) and doesn't find them. Otherwise I have not noticed server hanging when testing these random maps -the special door styles seem to be working properly. Maybe it is something else? On Sat, 2004-06-05 at 23:57, Rick Tanner wrote: > In the past couple of days, crossfire.metalforge.net server has hung at > what appears to be random intervals. > > Looking at the log files before I've had to manually kill and restart the > server, I noticed some similarities in 3 different log files. > > Anyone have any insight or recommendations? > > Trying to load map > /home/crossfire/share/crossfire/maps/random/world_105_0468. > load_original_map: /random/world_105_0468 (0) > Can't open /home/crossfire/share/crossfire/maps/random/world_105_0468 > Can't read map file: No such file or directory > load_original_map: /styles/doorstyles/hdoors (8) > Can't open /home/crossfire/share/crossfire/maps/styles/doorstyles/hdoors - > not a regular file > Can't open /home/crossfire/share/crossfire/maps/styles/doorstyles/hdoors > Can't read map file: Is a directory > load_original_map: /styles/exitstyles/generic/tree (8) > Couldn't find archetype archway_tree > > load_original_map: /styles/doorstyles/special (8) > Can't open /home/crossfire/share/crossfire/maps/styles/doorstyles/special > - not a regular file > Can't open /home/crossfire/share/crossfire/maps/styles/doorstyles/special > Can't read map file: Is a directory > load_original_map: /styles/exitstyles/generic/archway (8) > Couldn't find archetype archway_gold > Couldn't find archetype archway_green > Couldn't find archetype archway > > load_original_map: /styles/exitstyles/generic/archway (8) > Couldn't find archetype archway_gold > Couldn't find archetype archway_green > Couldn't find archetype archway _______________________________________________ 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 Sun Jun 6 23:32:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Path: party gsay improvment In-Reply-To: <20040606134544.GA22259@idefix2.dvlp.in-medias-res.com> References: <40C2D14F.6090907@laposte.net> <20040606134544.GA22259@idefix2.dvlp.in-medias-res.com> Message-ID: <40C3EFF2.4030403@sonic.net> Andreas Kirschbaum wrote: > I suppose there is a bug in this patch: > >>@@ -156,7 +156,7 @@ >> int no=op->contr->party_number; >> for(pl=first_player;pl!=NULL;pl=pl->next) >> if(pl->ob->contr->party_number==no && pl->ob!=op) >>- new_draw_info(NDI_UNIQUE, NDI_WHITE, pl->ob, msg); >>+ new_draw_info_format(NDI_WHITE, 0, pl->ob, msg); >> } >> >> int command_gsay(object *op, char *params) > > > It should be > > + new_draw_info_format(NDI_WHITE, 0, pl->ob, "%s", msg); > ^^^^ > > to prevent problems with messages that contain '%' characters. Actually, if you're doing to do that, might as well just call new_draw_info(), as the original code did. In fact, I have no idea what the code is trying to fix - my only guess is that the color should be white, and whoever put that code in, didn't realize the paramter passing. So something like new_draw_info(NDI_WHITE, 0, ...) should be find. The original usage of new_draw_info was no more broken that using the same paramter list for new_draw_info_format (eg, passing NDI_WHITE as the second pamaeter). Other than that, it looks fine. _______________________________________________ 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 Jun 7 01:32:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <20040605161704.GA19176@idefix2.dvlp.in-medias-res.com> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> <40BC2790.60201@sonic.net> <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> <40BED0FA.8090704@sonic.net> <20040605161704.GA19176@idefix2.dvlp.in-medias-res.com> Message-ID: <40C40C14.4010000@sonic.net> > esrv_send_inventory(op, op); > > + op->contr->last_weight = 0; /* set to incorrect weight, so esrv_update_item will send correct value */ > + esrv_update_item(UPD_WEIGHT, op, op);Andreas Kirschbaum wrote: > Mark Wedel wrote: > >>It might actually make more sense to treat the weight like any >>of the other stats (at least player weight), store the last >>value we sent, and send again if different instead of having >>these explicit calls. > > > Here is a diff that should do this. > > I declared the function pay_from_container() as "static" since it > is called from nowhere else. In addition I removed the parameter > "object *op" since it is unused. > > The use of the magic value "last_weight==(uint32)-1" was necessary > to delay sending "upditem" commands until the player object has > been sent ("player" and "item" commands). > > To check (and document) implicit assumptions, I use assert() > statements. Since these statements are basically not used > elsewhere, I'm not sure if I should remove these statements. A few notes: common/item.c: is the get_weight() function really correct? I note that it does not factor in the number of objects. For example, if there are 30 arrows, get_weight returns the weight of just 1 arrow. I'm not sure if that is intentional, but would perhaps seem confusion. I do see it matches the WEIGHT() macro definition in socket/item.c, so maybe so, but now I'm curious why make that a function, compared to moving the macro to define.h or the like. server/login.c: I'm not sure if the addition of a esrv_update_item is really necessary, since it immediately follows the esvr_new_player, and weight shouldn't have changed between those two calls. The use of assert doesn't follow with the current coding style, and it's usage is questionable. For the few uses, the question is 'if the assert is false, is this a significant error'. If the answer is yes, then having it as an assert may do no good, because the asserts do nothing at all unless NDEBUG is defined, which currently doesn't happen anyplace. Thus also means that in normal running code, an error isn't even noted at such asserts. So the usefulness in debugging is pretty limited. The current methodoly used in the code is to check those expressions manually (if ... { .. }) and LOG() in all such cases, with the priority of the log message (llevDebug, llWarn, llevError) based on how critical the error is. And if it is a critical error, to the extend that trying to continue will just cause it to core dump in the next line or two, might as well call abort right then and there. Other than that, it looks fine. _______________________________________________ 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 Jun 7 02:01:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Charm monster exploit In-Reply-To: <40C1AE37.6030203@laposte.net> References: <40C1AE37.6030203@laposte.net> Message-ID: <40C412C0.2050205@sonic.net> Nicolas Weeger wrote: > Hello. > > Charm monster *always* works. > It seems monsters just get charmed, whatever their level. > I was level 10 and could charm Ancient Red Dragons, or dragonmen lol. > > Looking in the code, in spell_attack.c:mood_change (i think that's what > is called?), there's a > > if (did_make_save(head, head->level, at)) continue; > > but i think values aren't really correctly made. > > I don't know the best way to fix, so i'm asking others :) > I'd see something like singing for the chance to calm down, based on > respective levels. Well, for more context, the code is actually: if (best_at == -1) at=0; else { if (head->resist[best_at] == 100) continue; else at = head->resist[best_at] / 5; } at -= level / 5; if (did_make_save(head, head->level, at)) continue; (best_at is the attacktype against the spell in question that the monster has the best saving throw against) I don't see any fault in those calculations. Now it seems that charm doesn't have an actual attacktype, so in that case, the monster isn't getting any advantage based on resistances they have. Now at level 10, you should be imposing a -2 or so penalty on the creature, which isn't that big a deal. at monster level 10 or so, it appears the base save they need is around 11 or 12, and it goes down 1 point about every 5 levels or so. So it would seem that it more or less is doing a level comparison there. I'd think it may be necessary to add some debug statement above the did_make_save() line and see what values are getting passed in. I will note that many monstes may not have appropriate level values set for themselves, and thus are easier targets. However, one thing I notice is how the code resolves the head, eg: /* Only the head has meaningful data, so resolve to that */ if (tmp->head) head=tmp->head; else head=tmp; The problem here is that it finds each monster, or part thereof, within range of the caster. The effect of this is that say a 2x2 monster is completely within the range - that monster now needs to make _4_ saving throws against the charm effect. Larger monsters would have to make even more. If the monster normally has a 75% chance to make it, but has 4 parts, its overall chance is then reduced to 31%. What probably needs to be done is some work to make it so that such large monsters only need to make a single saving throw. I'm not sure the best way to do this. One thought is that since all multipart objects are rectangular, and the area of effect of the charm and that block of code is always square, then you know that if a piece of the monster if affected, then either the head or tail of the monster must be in the area of effect. Thus, in the code itself, you could have some logic like: if (head->more && !head->head) { this is the head object - see if the tail is in the area of effect (since we have the tail_x and tail_y, this is easy to do). If not, continue to process this object - if so, don't process as block below takes care of this. } else if (head->head && !head->more) { This is the tail object - always process because the block above won't process if this block will. } else if (head->head && head->more) { this is a middle part of the creature - just continue because one of those two blocks above will properly deal with this } Now for some effects, like fireball, or other area of effect spells, it perhaps makes sense that large monsters are more vulnerable simply because more of them are in the effect. But that logic doesn't really hold true for charm and the like. _______________________________________________ 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 Jun 7 02:10:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Map stuff - deities - inventory checking In-Reply-To: <1086442398.40c1cb9e1e650@webmail.montevideo.com.uy> References: <200406041628.17510.eracclists@bellsouth.net> <1086442398.40c1cb9e1e650@webmail.montevideo.com.uy> Message-ID: <40C414FA.9000601@sonic.net> Karla Stenger wrote: > hi all, > > iirc it is the race of the praying skill or it's name, dont have the game here > to check it out sorry :) Actually, it is the 'title' of the praying skill, which contains the gods name. However, with the current objects in the game, there is no way to prevent players of certain god from entering short of using a script. The inventory checkers, which are used for things like the gatepasses and letting dragons into the guild, typically check against the slaying field or name of the object in the inventory. So all different passes/cards/membership devices have different slaying fields. And the dragon has a special object that is used to record their focuses and whatnot, which is what the dragon guild can check against. Now it could be nice to extend the checker code to perhaps match against titles - in fact, adding code like (if trig->tile && trig->title == op->title) ... would probably work fine - it'd create oddness if the checker in question is visible (because the title used against checking would also be added to the name), but if the object is hidden (beneath a floor, invisible, whatever), I can't think of any side effects of doing that, unless there are checkers already in the game that have their title set, but that seems unlikely. _______________________________________________ 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 Jun 7 02:56:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Path: party gsay improvment In-Reply-To: <40C3EFF2.4030403@sonic.net> References: <40C2D14F.6090907@laposte.net> <20040606134544.GA22259@idefix2.dvlp.in-medias-res.com> <40C3EFF2.4030403@sonic.net> Message-ID: <40C41F93.4030004@laposte.net> > In fact, I have no idea what the code is trying to fix - my only guess > is that the color should be white, and whoever put that code in, didn't > realize the paramter passing. The code changed the displayed message, too: before, it was like another 'tell', ie '%s tells: %s' after, it's '[%s] %s tells: %s' with party name added, thus making it easier to see it's a gsay message. Nicolas _______________________________________________ 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 Jun 7 11:58:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Path: party gsay improvment In-Reply-To: <40C41F93.4030004@laposte.net> References: <40C2D14F.6090907@laposte.net> <20040606134544.GA22259@idefix2.dvlp.in-medias-res.com> <40C3EFF2.4030403@sonic.net> <40C41F93.4030004@laposte.net> Message-ID: <40C49EC9.6060405@sonic.net> Nicolas Weeger wrote: >> In fact, I have no idea what the code is trying to fix - my only >> guess is that the color should be white, and whoever put that code in, >> didn't realize the paramter passing. > > > The code changed the displayed message, too: > before, it was like another 'tell', ie '%s tells: %s' > after, it's '[%s] %s tells: %s' with party name added, thus making it > easier to see it's a gsay message. Yeah, I got that part. I meant it wasn't clear why calls to new_draw_info() were replaced with calls to new_draw_info_format(), since code further up is already doing a snprintf on the data that is being passed into the new_draw.. function. _______________________________________________ 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 Jun 7 14:18:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Path: party gsay improvment In-Reply-To: <40C49EC9.6060405@sonic.net> References: <40C2D14F.6090907@laposte.net> <20040606134544.GA22259@idefix2.dvlp.in-medias-res.com> <40C3EFF2.4030403@sonic.net> <40C41F93.4030004@laposte.net> <40C49EC9.6060405@sonic.net> Message-ID: <40C4BF9F.30609@laposte.net> > Yeah, I got that part. I meant it wasn't clear why calls to > new_draw_info() were replaced with calls to new_draw_info_format(), > since code further up is already doing a snprintf on the data that is > being passed into the new_draw.. function. that i don't know :) probably some mistake from Katia i stupidly didn't notice :) _______________________________________________ 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 Jun 7 17:39:55 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Alchemy hashes Message-ID: <40C4EEBB.2020106@laposte.net> Hello. Apparently, a player on cf.mf.net browsed alchemy code, and can now do a few formulea with food only (even if they aren't supposed to be done with that). Not really an exploit, as code specifically says that's possible. But still, maybe we'd need to make it harder to make items? Apparently it's just a matter of finding a good combination of elements that sum up the same as target recipe. Just asking for opinions around :) Nicolas _______________________________________________ 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 Jun 7 18:34:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Alchemy hashes In-Reply-To: <40C4EEBB.2020106@laposte.net> References: <40C4EEBB.2020106@laposte.net> Message-ID: <200406071834.54394.eracclists@bellsouth.net> On Monday 07 June 2004 17:39 Nicolas Weeger wrote: > Hello. > > Apparently, a player on cf.mf.net browsed alchemy code, and can now > do a few formulea with food only (even if they aren't supposed to > be done with that). > Not really an exploit, as code specifically says that's possible. > But still, maybe we'd need to make it harder to make items? > > Apparently it's just a matter of finding a good combination of > elements that sum up the same as target recipe. > > Just asking for opinions around :) > > Nicolas IMO it is working as intended. If someone wants to take the time to figure out alternative recipes then their reward is being able to use them. I've been working on figuring out alternative recipes as well so I obviously believe it should be left alone. :-) Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 18:32:38 up 100 days, 12:28, 15 users, load average: 0.41, 0.96, 0.96 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 8 02:23:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Alchemy hashes In-Reply-To: <200406071834.54394.eracclists@bellsouth.net> References: <40C4EEBB.2020106@laposte.net> <200406071834.54394.eracclists@bellsouth.net> Message-ID: <40C56989.20603@sonic.net> ERACC wrote: > On Monday 07 June 2004 17:39 > Nicolas Weeger wrote: > > >>Hello. >> >>Apparently, a player on cf.mf.net browsed alchemy code, and can now >>do a few formulea with food only (even if they aren't supposed to >>be done with that). >>Not really an exploit, as code specifically says that's possible. >>But still, maybe we'd need to make it harder to make items? >> >>Apparently it's just a matter of finding a good combination of >>elements that sum up the same as target recipe. >> >>Just asking for opinions around :) >> >>Nicolas > > > IMO it is working as intended. If someone wants to take the time to > figure out alternative recipes then their reward is being able to use > them. I've been working on figuring out alternative recipes as well > so I obviously believe it should be left alone. :-) Well, just because the code is written in such a way does not mean it is correct. Otherwise crossfire would be bug free. Now personally, I don't really have much a problem with random recipes. The problem as I see it is that the recipes do a very simple hash, and so I'd say it is more out of game experimentation (or perhaps writing a simple script) to find alternative ways to make recipes. And in fact, the hash is quite simple - I'd expect in an evening, I could write a script that could display all the possible recipe combinations out there. And to me, that doesn't seem quite right. Now there are various ways around that - one could add some setting value that each server can customize - this setting would be added/multiplied/whatever to the hash string when attempting to do the recipes - thus, unless you knew that setting, it would be very difficult to find recipes outside the game. The hash code would have to be redone a bit - probably really want something more like a proper hash, eg: if (val & 800000) highbit=1; val <<= 1; val += tolower(character value) + element from setting; if highbit val |=1; Or something - looking at the code of actual checksum programs could be useful here. But all that really does it make it harder, depending on the max element from the setting. Eg, if the max value is 100, that isn't all that hard for players to figure it out, and once they find that setting, it opens everything up - in a sense, that becomes more security through obscurity. The other thought I had, and perhaps a more clever thought, was to redo how the recipes are defined. Instead of having the formulae file, you could instead do treasurelists. For example, instead of: # # water of ruby Object ruby arch water diff 10 exp 5000 chance 35 skill alchemy cauldron cauldron ingred 3 ruby,water of the wise Something like: Object water title ruby randomitems recipe_water_ruby ... and then have treasure recipe_water_ruby arch ruby nrof 3 more arch water of the wise nrof 1 end So that allows for simple object comparision on recipes. But the more clever idea is you could have random recipes, like: treasure gem_encrusted_sword list swords more arch ruby chance 25 no arch diamond chance 25 no arch emerald end end end end So it grabs a weapon from the list of swords, and grabs one of those 3 gems, and generates a recipe, You only need a few items and selection of items to now get a very big selection list. For example, if the recipe has 3 items, but there are 10 different ones for each of those items, there is now 1000 combinations. Now my idea here is that as part of installation, or first run or whatever, the server generates those various lists and then write them out, so that they are static after that point. Other settings could dictate if these show up in books or if only available by experimentation. PRobably to do this, you'd need an object type RECIPE, and then perhaps even the formula file could go away. This has the advantage that it is now in game experimentation that may find these (and if you're a low level alchemist, you never really know if you had an invalid formula, or just failed on your roll). But is also means that the formula arguably make more sense - transposing some letters or having a sum of letters that come up the same recipes doesn't make a whole bunch of sense (I know, its magic - it doesn't have to make sense), but something like above makes some sense - the objects to make the final project tie in with the object. But that's just my $.02 _______________________________________________ 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 Jun 8 05:48:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <40C40C14.4010000@sonic.net> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> <40BC2790.60201@sonic.net> <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> <40BED0FA.8090704@sonic.net> <20040605161704.GA19176@idefix2.dvlp.in-medias-res.com> <40C40C14.4010000@sonic.net> Message-ID: <20040608104816.GA3872@idefix2.dvlp.in-medias-res.com> Mark Wedel wrote: > common/item.c: is the get_weight() function really correct? I > note that it does not factor in the number of objects. For > example, if there are 30 arrows, get_weight returns the weight > of just 1 arrow. I'm not sure if that is intentional, but would > perhaps seem confusion. I do see it matches the WEIGHT() macro > definition in socket/item.c, so maybe so, It is correct because the client needs both the weight of *one* item and the number of items. It calculates the total weight of all items itself. > but now I'm curious why make that a function, compared to moving > the macro to define.h or the like. OK, will declare it as a macro in define.h. The reason for using a function is that I generally tend to avoid macros: when calling a macro, you have to worry about side effects (due to possible multiple evaluations of parameters) and also do not get type-checking by the compiler. > server/login.c: I'm not sure if the addition of a > esrv_update_item is really necessary, since it immediately > follows the esvr_new_player, and weight shouldn't have changed > between those two calls. After checking the source, esrv_new_player indeed sends the weight. But it does not set the field last_weight. I'll add this assignment to last_weight, and remove the call to esrv_update_item. The reason for adding the call to esrv_update_item was to have only one place that sets last_weight. But I realized that esrv_new_player is called two times while creating a new character, so setting the field last_weight is indeed a good idea. > The use of assert doesn't follow with the current coding style, > and it's usage is questionable. > > For the few uses, the question is 'if the assert is false, is > this a significant error'. If the answer is yes, then having it > as an assert may do no good, because the asserts do nothing at > all unless NDEBUG is defined, which currently doesn't happen > anyplace. > > Thus also means that in normal running code, an error isn't even > noted at such asserts. So the usefulness in debugging is pretty > limited. Java exhibits this limited usefulness that you have to explicitly enable assertions (at runtime). The behavior of C assertions is exactly the opposite: the C standard says (in section 7.2): |If NDEBUG is defined as a macro name at the point in the source |file where is included, the assert macro is defined |simply as | |#define assert(ignore) ((void)0) That is, assert() does nothing *only if* NDEBUG ("no debug") is defined. Otherwise (i.e. if you do not explicitly disable the assertions by defining NDEBUG), the assertions are active. > The current methodoly used in the code is to check those > expressions manually (if ... { .. }) and LOG() in all such > cases, with the priority of the log message (llevDebug, llWarn, > llevError) based on how critical the error is. This seems right to me for problems that should not happen but may very well be possible. (I.e. can't read/write a file, a passed object has wrong type/flags/whatever, etc.) > And if it is a critical error, to the extend that trying to > continue will just cause it to core dump in the next line or > two, might as well call abort right then and there. These are the types of errors that should be checked with assert(): to detect an inconsistent internal state that should never be possible. Therefore assert() prints an error message to stderr and calls abort() if it fails. _______________________________________________ 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 Jun 8 09:10:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_Alchemy_hashes?= Message-ID: I like the idea of a server specific 'seed' but can guess it would be unpopular to some. Some people make a career out of abusing the existing hash system. As for the treasure lists - sounds good. It would make it easier to reuse parts of formulas as well. My only concern is that if you make it so the recipies become static after the first run then that might be a problem for adding/updating. I would rather have this as part of the collect build routine so new recipies could be added as easily as new arches. This also provides a place to generate book info. > Now personally, I don't really have much a problem with random recipes. The > problem as I see it is that the recipes do a very simple hash, and so I'd say it > is more out of game experimentation (or perhaps writing a simple script) to find > alternative ways to make recipes. And in fact, the hash is quite simple - I'd > expect in an evening, I could write a script that could display all the possible > recipe combinations out there. And to me, that doesn't seem quite right. > > Now there are various ways around that - one could add some setting value that > each server can customize - this setting would be added/multiplied/whatever to > the hash string when attempting to do the recipes - thus, unless you knew that > setting, it would be very difficult to find recipes outside the game. > > The hash code would have to be redone a bit - probably really want something > more like a proper hash, eg: > > if (val & 800000) highbit=1; > val <<= 1; > val += tolower(character value) + element from setting; > if highbit val |=1; > > Or something - looking at the code of actual checksum programs could be useful > here. > > But all that really does it make it harder, depending on the max element from > the setting. Eg, if the max value is 100, that isn't all that hard for players > to figure it out, and once they find that setting, it opens everything up - in a > sense, that becomes more security through obscurity. > > The other thought I had, and perhaps a more clever thought, was to redo how > the recipes are defined. Instead of having the formulae file, you could instead > do treasurelists. For example, instead of: > > # > # water of ruby > Object ruby > arch water > diff 10 > exp 5000 > chance 35 > skill alchemy > cauldron cauldron > ingred 3 ruby,water of the wise > > > Something like: > > Object water > title ruby > randomitems recipe_water_ruby > ... > > and then have > > treasure recipe_water_ruby > arch ruby > nrof 3 > more > arch water of the wise > nrof 1 > end > > So that allows for simple object comparision on recipes. But the more clever > idea is you could have random recipes, like: > > treasure gem_encrusted_sword > list swords > more > arch ruby > chance 25 > no > arch diamond > chance 25 > no > arch emerald > end > end > end > end > > So it grabs a weapon from the list of swords, and grabs one of those 3 gems, > and generates a recipe, You only need a few items and selection of items to now > get a very big selection list. For example, if the recipe has 3 items, but > there are 10 different ones for each of those items, there is now 1000 combinations. > > Now my idea here is that as part of installation, or first run or whatever, > the server generates those various lists and then write them out, so that they > are static after that point. Other settings could dictate if these show up in > books or if only available by experimentation. PRobably to do this, you'd need > an object type RECIPE, and then perhaps even the formula file could go away. > > This has the advantage that it is now in game experimentation that may find > these (and if you're a low level alchemist, you never really know if you had an > invalid formula, or just failed on your roll). But is also means that the > formula arguably make more sense - transposing some letters or having a sum of > letters that come up the same recipes doesn't make a whole bunch of sense (I > know, its magic - it doesn't have to make sense), but something like above makes > some sense - the objects to make the final project tie in with the object. > > But that's just my $.02 > _______________________________________________ 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 Jun 8 15:45:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Re: pup_land volcano maps - Too difficult References: Message-ID: <27299.1086727515@www62.gmx.net> In reply to an anonymous bug tracker report (#968638): > I know that white dragon scale male has been toned down > several times, and it's now impossible for a newbie to > obtain, but the road to obtaining it is too difficult, > period. By the time I created the volcano maps, I balanced them carefully against a level 110 player. A lot of things have changed in the meantime, and I haven't played CF for a while. I just tested the volcano maps once again, and I agree that some rebalancing and bug fixing is in order. Before diving into the details, I want to state that these maps are really meant to be a challenge - and I mean challenge - for top high level players. If they are almost impossible to survive, that is just fine. If they are *really* impossible to survive though, then it is not okay. > Players must endure a swarm of meteors, icestorms, > burning hands, and ball lightnings. These will kill a > level 112 player with at least +88 res to fire, elec, > and ice instantly, less than 0.3 seconds officially on > the metalforge.net server I'd like to refer to each of the obstacles in the volcano: o The gargoyle-shaped, comet-hurling "death machines" (firewalls): They have become far too deadly due to an immensely increased burn-radius (= range) of the comets. Their level 100 adds to this. I plan to rebalance this by reducing their level to 60 and inserting a customized comet version with a range of 3. This will also prevent the fire from covering the warning sign. o The ice and fire statues are quite okay IMO. With a 95% immunity potion for fire/ice they are passable. There is one important problem with the rooms however: The firewalls ("anti-magic force") in the hallways which connect the rooms, get pushed out of their position by the frost and fire spells casted by the statues. I don't know how to fix this, but the objects which get pushed are firewalls (type 62) and they have "no_pass 0" set. They should not get pushed, is that possible to achieve somehow? o The ball lightnings are survivable with a 90% elec resist potion, but unfortunately the lightnings are more persistent than they used to be. The counterspell effect doesn't quite get rid of them. I'll see what I can do about that. Reducing the spell duration seems like a suitable solution. o The cause wound spells don't work, that is another problem. The white statues are simply monsters with "stand_still 1" and cause heavy wound spell objects in their inventory. Anyone know what could be the problem? Maybe they need a praying skill assigned somehow? Or is it the lack of god? All I can say is that it used to work in former times. Greetings, AndreasV -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info _______________________________________________ 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 Jun 8 16:44:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:44 2005 Subject: [CF-Devel] Re: pup_land volcano maps - Too difficult References: <27299.1086727515@www62.gmx.net> Message-ID: <1334.1086731047@www62.gmx.net> > [...] > o The cause wound spells don't work, that is another problem. > The white statues are simply monsters with "stand_still 1" and > cause heavy wound spell objects in their inventory. Okay, I just figured out that I can use firewalls with cause wound spells to make it work. That's quite good. The only remaining problem then are the cancellation firewalls getting pushed by spell effects. Maybe it is possible to define in the pushing code simply never to push firewalls? AndreasV -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info _______________________________________________ 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 Jun 8 16:54:37 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:45 2005 Subject: [CF-Devel] Re: pup_land volcano maps - Too difficult In-Reply-To: <1334.1086731047@www62.gmx.net> References: <27299.1086727515@www62.gmx.net> <1334.1086731047@www62.gmx.net> Message-ID: <40C6359D.2070900@laposte.net> > The only remaining problem then are the cancellation firewalls > getting pushed by spell effects. Maybe it is possible to > define in the pushing code simply never to push firewalls? This side effect of spells has been discussed. I think Mark removed weights from some spells, thus making'em not push things anymore. May need to update archetypes or such :) > AndreasV Nicolas '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 Sun Jun 6 08:13:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:45 2005 Subject: [CF-Devel] DM - God Finger - bleah! In-Reply-To: References: <40BABAE1.7040704@sonic.net> Message-ID: <20040606231326.4e11bb7c.won_fang@yahoo.com.au> Skipped content of type multipart/signed-------------- 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 Jun 8 18:49:45 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:46 2005 Subject: [CF-Devel] button-link bug? Message-ID: <19093.1086738585@www36.gmx.net> In the process of map testing, I stumbled across a weird bug: Enter the map "treasure" (map is attached to this mail), then leave, wait till the map is saved out. You should see the following line: Saving map /pup_land/ancient/volcano/treasure Then re-enter the map. Re-loading of the map somehow fails (player is trapped, and surrounded by all-black squares. The server prints the following message: Tried to add button-link without map. Tried to add button-link without map. Tried to add button-link without map. ... I run latest CVS code and arches. Important: I'm using windows, so it could be related to a character/ascii/linefeed parsing problem. The bug happens every time I follow the steps described above. It appears on other maps as well, but it only seems to happen on maps with buttons. Button-free maps don't show any problem of this kind. Greetings, AndreasV -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info -------------- next part -------------- arch map name treasure msg Creator: Andreas Vogl Email: red.blaze@gmx.net Date: Tue Jun 6 22:51:57 2000 endmsg width 26 height 27 enter_x 1 enter_y 1 reset_timeout 7200 difficulty 13 end arch blocked end arch blocked y 1 end arch blocked y 2 end arch blocked y 3 end arch blocked y 4 end arch blocked y 5 end arch blocked y 6 end arch blocked y 7 end arch blocked y 8 end arch blocked y 9 end arch blocked y 10 end arch blocked y 11 end arch blocked y 12 end arch blocked y 13 end arch blocked y 14 end arch blocked y 15 end arch blocked y 16 end arch blocked y 17 end arch blocked y 18 end arch flagstone y 19 end arch cave24 y 19 end arch flagstone y 20 end arch cave3 y 20 end arch flagstone y 21 end arch cave3 y 21 end arch flagstone y 22 end arch cave3 y 22 end arch flagstone y 23 end arch cave23 y 23 end arch blocked y 24 end arch blocked y 25 end arch blocked y 26 end arch blocked x 1 end arch dungeon_magic x 1 y 1 end arch blocked x 1 y 1 end arch dungeon_magic x 1 y 2 end arch blocked x 1 y 2 end arch dungeon_magic x 1 y 3 end arch flagstone x 1 y 3 end arch cave24 x 1 y 3 end arch dungeon_magic x 1 y 4 end arch flagstone x 1 y 4 end arch cave3 x 1 y 4 end arch dungeon_magic x 1 y 5 end arch flagstone x 1 y 5 end arch cave3 x 1 y 5 end arch dungeon_magic x 1 y 6 end arch flagstone x 1 y 6 end arch cave3 x 1 y 6 end arch dungeon_magic x 1 y 7 end arch flagstone x 1 y 7 end arch cave3 x 1 y 7 end arch dungeon_magic x 1 y 8 end arch flagstone x 1 y 8 end arch cave3 x 1 y 8 end arch dungeon_magic x 1 y 9 end arch flagstone x 1 y 9 end arch cave3 x 1 y 9 end arch dungeon_magic x 1 y 10 end arch flagstone x 1 y 10 end arch cave3 x 1 y 10 end arch dungeon_magic x 1 y 11 end arch flagstone x 1 y 11 end arch cave3 x 1 y 11 end arch dungeon_magic x 1 y 12 end arch flagstone x 1 y 12 end arch cave3 x 1 y 12 end arch dungeon_magic x 1 y 13 end arch flagstone x 1 y 13 end arch cave3 x 1 y 13 end arch dungeon_magic x 1 y 14 end arch flagstone x 1 y 14 end arch cave3 x 1 y 14 end arch dungeon_magic x 1 y 15 end arch flagstone x 1 y 15 end arch cave3 x 1 y 15 end arch dungeon_magic x 1 y 16 end arch flagstone x 1 y 16 end arch cave3 x 1 y 16 end arch dungeon_magic x 1 y 17 end arch flagstone x 1 y 17 end arch cave3 x 1 y 17 end arch dungeon_magic x 1 y 18 end arch flagstone x 1 y 18 end arch cave3 x 1 y 18 end arch dungeon_magic x 1 y 19 end arch flagstone x 1 y 19 end arch cave9 x 1 y 19 end arch dungeon_magic x 1 y 20 end arch flagstone x 1 y 20 end arch pedestal name 20 resist_fire 30 resist_cold 30 connected 20 x 1 y 21 end arch dungeon_magic x 1 y 21 end arch flagstone x 1 y 21 end arch pedestal name 20 resist_fire 30 resist_cold 30 connected 20 x 1 y 22 end arch dungeon_magic x 1 y 22 end arch flagstone x 1 y 22 end arch dungeon_magic x 1 y 23 end arch flagstone x 1 y 23 end arch cave2 x 1 y 23 end arch dungeon_magic x 1 y 24 end arch blocked x 1 y 24 end arch dungeon_magic x 1 y 25 end arch blocked x 1 y 25 end arch blocked x 1 y 26 end arch flagstone x 2 end arch cave24 x 2 end arch dungeon_magic x 2 y 1 end arch flagstone x 2 y 1 end arch cave3 x 2 y 1 end arch dungeon_magic x 2 y 2 end arch flagstone x 2 y 2 end arch cave3 x 2 y 2 end arch dungeon_magic x 2 y 3 end arch flagstone x 2 y 3 end arch cave9 x 2 y 3 end arch dungeon_magic x 2 y 4 end arch flagstone x 2 y 4 end arch dungeon_magic x 2 y 5 end arch flagstone x 2 y 5 end arch statue name death machine face statue_gargoyle.111 type 62 blocksview 1 level 60 speed 0.1 sp 5 x 2 y 5 arch spell_comet range 3 duration_modifier 10 end end arch dungeon_magic x 2 y 6 end arch flagstone x 2 y 6 end arch dungeon_magic x 2 y 7 end arch flagstone x 2 y 7 end arch dungeon_magic x 2 y 8 end arch flagstone x 2 y 8 end arch dungeon_magic x 2 y 9 end arch flagstone x 2 y 9 end arch dungeon_magic x 2 y 10 end arch flagstone x 2 y 10 end arch dungeon_magic x 2 y 11 end arch flagstone x 2 y 11 end arch dungeon_magic x 2 y 12 end arch flagstone x 2 y 12 end arch dungeon_magic x 2 y 13 end arch flagstone x 2 y 13 end arch dungeon_magic x 2 y 14 end arch flagstone x 2 y 14 end arch dungeon_magic x 2 y 15 end arch flagstone x 2 y 15 end arch dungeon_magic x 2 y 16 end arch flagstone x 2 y 16 end arch dungeon_magic x 2 y 17 end arch flagstone x 2 y 17 end arch dungeon_magic x 2 y 18 end arch flagstone x 2 y 18 end arch dungeon_magic x 2 y 19 end arch flagstone x 2 y 19 end arch dungeon_magic x 2 y 20 end arch flagstone x 2 y 20 end arch dungeon_magic x 2 y 21 end arch flagstone x 2 y 21 end arch swall_1_4 x 2 y 21 end arch pedestal name 20 resist_fire 30 resist_cold 30 connected 20 x 2 y 22 end arch dungeon_magic x 2 y 22 end arch flagstone x 2 y 22 end arch dungeon_magic x 2 y 23 end arch flagstone x 2 y 23 end arch cave12 x 2 y 23 end arch dungeon_magic x 2 y 24 end arch flagstone x 2 y 24 end arch cave3 x 2 y 24 end arch dungeon_magic x 2 y 25 end arch flagstone x 2 y 25 end arch cave3 x 2 y 25 end arch flagstone x 2 y 26 end arch cave23 x 2 y 26 end arch flagstone x 3 end arch cave4 x 3 end arch dungeon_magic x 3 y 1 end arch flagstone x 3 y 1 end arch dungeon_magic x 3 y 2 end arch flagstone x 3 y 2 end arch dungeon_magic x 3 y 3 end arch flagstone x 3 y 3 end arch dungeon_magic x 3 y 4 end arch flagstone x 3 y 4 end arch dungeon_magic x 3 y 5 end arch flagstone x 3 y 5 end arch dungeon_magic x 3 y 6 end arch flagstone x 3 y 6 end arch dungeon_magic x 3 y 7 end arch flagstone type 41 hp 3 sp 5 activate_on_push 1 activate_on_release 1 connected 2 x 3 y 7 end arch statue name death machine face statue_gargoyle.111 type 62 blocksview 1 level 60 speed 0.1 sp 5 x 3 y 7 arch spell_comet range 3 duration_modifier 10 end end arch dungeon_magic x 3 y 8 end arch flagstone x 3 y 8 end arch dungeon_magic x 3 y 9 end arch flagstone x 3 y 9 end arch dungeon_magic x 3 y 10 end arch flagstone x 3 y 10 end arch dungeon_magic x 3 y 11 end arch flagstone x 3 y 11 end arch dungeon_magic x 3 y 12 end arch flagstone x 3 y 12 end arch dungeon_magic x 3 y 13 end arch flagstone x 3 y 13 end arch dungeon_magic x 3 y 14 end arch flagstone x 3 y 14 end arch dungeon_magic x 3 y 15 end arch flagstone x 3 y 15 end arch dungeon_magic x 3 y 16 end arch flagstone x 3 y 16 end arch dungeon_magic x 3 y 17 end arch flagstone x 3 y 17 end arch dungeon_magic x 3 y 18 end arch flagstone x 3 y 18 end arch dungeon_magic x 3 y 19 end arch flagstone x 3 y 19 end arch dungeon_magic x 3 y 20 end arch flagstone x 3 y 20 end arch dungeon_magic x 3 y 21 end arch flagstone x 3 y 21 end arch swall_2_1_2 x 3 y 21 end arch dungeon_magic x 3 y 22 end arch flagstone x 3 y 22 end arch dungeon_magic x 3 y 23 end arch flagstone x 3 y 23 end arch dungeon_magic x 3 y 24 end arch flagstone x 3 y 24 end arch dungeon_magic x 3 y 25 end arch flagstone x 3 y 25 end arch flagstone x 3 y 26 end arch cave2 x 3 y 26 end arch flagstone x 4 end arch cave4 x 4 end arch dungeon_magic x 4 y 1 end arch flagstone x 4 y 1 end arch dungeon_magic x 4 y 2 end arch flagstone x 4 y 2 end arch stair_down_2 slaying guardians hp 6 sp 2 x 4 y 2 end arch dungeon_magic x 4 y 3 end arch flagstone x 4 y 3 end arch dungeon_magic x 4 y 4 end arch flagstone x 4 y 4 end arch dungeon_magic x 4 y 5 end arch flagstone x 4 y 5 end arch statue name death machine face statue_gargoyle.111 type 62 blocksview 1 level 60 speed 0.1 sp 5 x 4 y 5 arch spell_comet range 3 duration_modifier 10 end end arch dungeon_magic x 4 y 6 end arch flagstone x 4 y 6 end arch dungeon_magic x 4 y 7 end arch flagstone x 4 y 7 end arch dungeon_magic x 4 y 8 end arch flagstone x 4 y 8 end arch dungeon_magic x 4 y 9 end arch flagstone x 4 y 9 end arch dungeon_magic x 4 y 10 end arch flagstone x 4 y 10 end arch dungeon_magic x 4 y 11 end arch flagstone x 4 y 11 end arch dungeon_magic x 4 y 12 end arch flagstone x 4 y 12 end arch dungeon_magic x 4 y 13 end arch flagstone x 4 y 13 end arch dungeon_magic x 4 y 14 end arch flagstone x 4 y 14 end arch dungeon_magic x 4 y 15 end arch flagstone x 4 y 15 end arch dungeon_magic x 4 y 16 end arch flagstone x 4 y 16 end arch dungeon_magic x 4 y 17 end arch flagstone x 4 y 17 end arch dungeon_magic x 4 y 18 end arch flagstone x 4 y 18 end arch dungeon_magic x 4 y 19 end arch flagstone x 4 y 19 end arch dungeon_magic x 4 y 20 end arch flagstone x 4 y 20 end arch dungeon_magic x 4 y 21 end arch flagstone x 4 y 21 end arch swall_2_1_2 x 4 y 21 end arch dungeon_magic x 4 y 22 end arch flagstone x 4 y 22 end arch monument name warning msg This path leads to Gothwolte's treasure hoard. Nobody is allowed to pass! Intruders will suffer horribly. (In other words: You - will - die!) endmsg x 4 y 22 end arch dungeon_magic x 4 y 23 end arch flagstone x 4 y 23 end arch dungeon_magic x 4 y 24 end arch flagstone x 4 y 24 end arch stair_up_2 slaying volcano.3 hp 7 sp 24 x 4 y 24 end arch dungeon_magic x 4 y 25 end arch flagstone x 4 y 25 end arch flagstone x 4 y 26 end arch cave2 x 4 y 26 end arch flagstone x 5 end arch cave4 x 5 end arch dungeon_magic x 5 y 1 end arch flagstone x 5 y 1 end arch dungeon_magic x 5 y 2 end arch flagstone x 5 y 2 end arch dungeon_magic x 5 y 3 end arch flagstone x 5 y 3 end arch dungeon_magic x 5 y 4 end arch flagstone x 5 y 4 end arch dungeon_magic x 5 y 5 end arch flagstone x 5 y 5 end arch dungeon_magic x 5 y 6 end arch flagstone x 5 y 6 end arch dungeon_magic x 5 y 7 end arch flagstone type 41 hp 5 sp 5 activate_on_push 1 activate_on_release 1 connected 2 x 5 y 7 end arch statue name death machine face statue_gargoyle.111 type 62 blocksview 1 level 60 speed 0.1 sp 5 x 5 y 7 arch spell_comet range 3 duration_modifier 10 end end arch dungeon_magic x 5 y 8 end arch flagstone x 5 y 8 end arch dungeon_magic x 5 y 9 end arch flagstone x 5 y 9 end arch dungeon_magic x 5 y 10 end arch flagstone x 5 y 10 end arch dungeon_magic x 5 y 11 end arch flagstone x 5 y 11 end arch dungeon_magic x 5 y 12 end arch flagstone x 5 y 12 end arch dungeon_magic x 5 y 13 end arch flagstone x 5 y 13 end arch dungeon_magic x 5 y 14 end arch flagstone x 5 y 14 end arch dungeon_magic x 5 y 15 end arch flagstone x 5 y 15 end arch dungeon_magic x 5 y 16 end arch flagstone x 5 y 16 end arch dungeon_magic x 5 y 17 end arch flagstone x 5 y 17 end arch dungeon_magic x 5 y 18 end arch flagstone x 5 y 18 end arch dungeon_magic x 5 y 19 end arch flagstone x 5 y 19 end arch dungeon_magic x 5 y 20 end arch flagstone x 5 y 20 end arch dungeon_magic x 5 y 21 end arch flagstone x 5 y 21 end arch swall_2_1_2 x 5 y 21 end arch dungeon_magic x 5 y 22 end arch flagstone x 5 y 22 end arch dungeon_magic x 5 y 23 end arch flagstone x 5 y 23 end arch dungeon_magic x 5 y 24 end arch flagstone x 5 y 24 end arch dungeon_magic x 5 y 25 end arch flagstone x 5 y 25 end arch flagstone x 5 y 26 end arch cave2 x 5 y 26 end arch flagstone x 6 end arch cave25 x 6 end arch dungeon_magic x 6 y 1 end arch flagstone x 6 y 1 end arch cave1 x 6 y 1 end arch dungeon_magic x 6 y 2 end arch flagstone x 6 y 2 end arch cave1 x 6 y 2 end arch dungeon_magic x 6 y 3 end arch flagstone x 6 y 3 end arch cave10 x 6 y 3 end arch dungeon_magic x 6 y 4 end arch flagstone x 6 y 4 end arch dungeon_magic x 6 y 5 end arch flagstone x 6 y 5 end arch statue name death machine face statue_gargoyle.111 type 62 blocksview 1 level 60 speed 0.1 sp 5 x 6 y 5 arch spell_comet range 3 duration_modifier 10 end end arch dungeon_magic x 6 y 6 end arch flagstone x 6 y 6 end arch dungeon_magic x 6 y 7 end arch flagstone x 6 y 7 end arch dungeon_magic x 6 y 8 end arch flagstone x 6 y 8 end arch dungeon_magic x 6 y 9 end arch flagstone x 6 y 9 end arch dungeon_magic x 6 y 10 end arch flagstone x 6 y 10 end arch dungeon_magic x 6 y 11 end arch flagstone x 6 y 11 end arch dungeon_magic x 6 y 12 end arch flagstone x 6 y 12 end arch dungeon_magic x 6 y 13 end arch flagstone x 6 y 13 end arch dungeon_magic x 6 y 14 end arch flagstone x 6 y 14 end arch dungeon_magic x 6 y 15 end arch flagstone x 6 y 15 end arch dungeon_magic x 6 y 16 end arch flagstone x 6 y 16 end arch dungeon_magic x 6 y 17 end arch flagstone x 6 y 17 end arch dungeon_magic x 6 y 18 end arch flagstone x 6 y 18 end arch dungeon_magic x 6 y 19 end arch flagstone x 6 y 19 end arch dungeon_magic x 6 y 20 end arch flagstone x 6 y 20 end arch dungeon_magic x 6 y 21 end arch flagstone x 6 y 21 end arch swall_1_3 x 6 y 21 end arch pedestal name 20 resist_fire 30 resist_cold 30 connected 20 x 6 y 22 end arch dungeon_magic x 6 y 22 end arch flagstone x 6 y 22 end arch dungeon_magic x 6 y 23 end arch flagstone x 6 y 23 end arch cave11 x 6 y 23 end arch dungeon_magic x 6 y 24 end arch flagstone x 6 y 24 end arch cave1 x 6 y 24 end arch dungeon_magic x 6 y 25 end arch flagstone x 6 y 25 end arch cave1 x 6 y 25 end arch flagstone x 6 y 26 end arch cave22 x 6 y 26 end arch blocked x 7 end arch dungeon_magic x 7 y 1 end arch blocked x 7 y 1 end arch dungeon_magic x 7 y 2 end arch blocked x 7 y 2 end arch dungeon_magic x 7 y 3 end arch flagstone x 7 y 3 end arch cave25 x 7 y 3 end arch dungeon_magic x 7 y 4 end arch flagstone x 7 y 4 end arch cave1 x 7 y 4 end arch dungeon_magic x 7 y 5 end arch flagstone x 7 y 5 end arch cave1 x 7 y 5 end arch dungeon_magic x 7 y 6 end arch flagstone x 7 y 6 end arch cave1 x 7 y 6 end arch dungeon_magic x 7 y 7 end arch flagstone x 7 y 7 end arch cave1 x 7 y 7 end arch dungeon_magic x 7 y 8 end arch flagstone x 7 y 8 end arch cave1 x 7 y 8 end arch dungeon_magic x 7 y 9 end arch flagstone x 7 y 9 end arch cave1 x 7 y 9 end arch dungeon_magic x 7 y 10 end arch flagstone x 7 y 10 end arch cave1 x 7 y 10 end arch dungeon_magic x 7 y 11 end arch flagstone x 7 y 11 end arch cave1 x 7 y 11 end arch dungeon_magic x 7 y 12 end arch flagstone x 7 y 12 end arch cave1 x 7 y 12 end arch dungeon_magic x 7 y 13 end arch flagstone x 7 y 13 end arch cave1 x 7 y 13 end arch dungeon_magic x 7 y 14 end arch flagstone x 7 y 14 end arch cave1 x 7 y 14 end arch dungeon_magic x 7 y 15 end arch flagstone x 7 y 15 end arch cave1 x 7 y 15 end arch dungeon_magic x 7 y 16 end arch flagstone x 7 y 16 end arch cave1 x 7 y 16 end arch dungeon_magic x 7 y 17 end arch flagstone x 7 y 17 end arch cave1 x 7 y 17 end arch dungeon_magic x 7 y 18 end arch flagstone x 7 y 18 end arch cave1 x 7 y 18 end arch dungeon_magic x 7 y 19 end arch flagstone x 7 y 19 end arch cave10 x 7 y 19 end arch dungeon_magic x 7 y 20 end arch flagstone x 7 y 20 end arch pedestal name 20 resist_fire 30 resist_cold 30 connected 20 x 7 y 21 end arch dungeon_magic x 7 y 21 end arch flagstone x 7 y 21 end arch pedestal name 20 resist_fire 30 resist_cold 30 connected 20 x 7 y 22 end arch dungeon_magic x 7 y 22 end arch flagstone x 7 y 22 end arch dungeon_magic x 7 y 23 end arch flagstone x 7 y 23 end arch cave2 x 7 y 23 end arch dungeon_magic x 7 y 24 end arch blocked x 7 y 24 end arch dungeon_magic x 7 y 25 end arch blocked x 7 y 25 end arch blocked x 7 y 26 end arch blocked x 8 end arch blocked x 8 y 1 end arch blocked x 8 y 2 end arch blocked x 8 y 3 end arch blocked x 8 y 4 end arch blocked x 8 y 5 end arch blocked x 8 y 6 end arch blocked x 8 y 7 end arch blocked x 8 y 8 end arch blocked x 8 y 9 end arch blocked x 8 y 10 end arch blocked x 8 y 11 end arch blocked x 8 y 12 end arch blocked x 8 y 13 end arch blocked x 8 y 14 end arch blocked x 8 y 15 end arch blocked x 8 y 16 end arch blocked x 8 y 17 end arch blocked x 8 y 18 end arch flagstone x 8 y 19 end arch cave25 x 8 y 19 end arch flagstone x 8 y 20 end arch cave1 x 8 y 20 end arch flagstone x 8 y 21 end arch cave1 x 8 y 21 end arch flagstone x 8 y 22 end arch cave1 x 8 y 22 end arch flagstone x 8 y 23 end arch cave22 x 8 y 23 end arch blocked x 8 y 24 end arch blocked x 8 y 25 end arch blocked x 8 y 26 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 9 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 9 y 1 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 9 y 2 end arch blocked x 9 y 3 end arch flagstone x 9 y 4 end arch cave24 x 9 y 4 end arch flagstone x 9 y 5 end arch cave3 x 9 y 5 end arch flagstone x 9 y 6 end arch cave3 x 9 y 6 end arch flagstone x 9 y 7 end arch cave3 x 9 y 7 end arch flagstone x 9 y 8 end arch cave3 x 9 y 8 end arch flagstone x 9 y 9 end arch cave3 x 9 y 9 end arch flagstone x 9 y 10 end arch cave3 x 9 y 10 end arch flagstone x 9 y 11 end arch cave3 x 9 y 11 end arch flagstone x 9 y 12 end arch cave3 x 9 y 12 end arch flagstone x 9 y 13 end arch cave3 x 9 y 13 end arch flagstone x 9 y 14 end arch cave3 x 9 y 14 end arch flagstone x 9 y 15 end arch cave3 x 9 y 15 end arch flagstone x 9 y 16 end arch cave3 x 9 y 16 end arch flagstone x 9 y 17 end arch cave3 x 9 y 17 end arch flagstone x 9 y 18 end arch cave3 x 9 y 18 end arch flagstone x 9 y 19 end arch cave3 x 9 y 19 end arch flagstone x 9 y 20 end arch cave23 x 9 y 20 end arch blocked x 9 y 21 end arch blocked x 9 y 22 end arch blocked x 9 y 23 end arch blocked x 9 y 24 end arch blocked x 9 y 25 end arch blocked x 9 y 26 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 10 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 10 y 1 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 10 y 2 end arch blocked x 10 y 3 end arch flagstone x 10 y 4 end arch cave4 x 10 y 4 end arch dungeon_magic x 10 y 5 end arch flagstone x 10 y 5 end arch random_gem x 10 y 5 end arch dungeon_magic x 10 y 6 end arch flagstone x 10 y 6 end arch random_wealth x 10 y 6 end arch dungeon_magic x 10 y 7 end arch flagstone x 10 y 7 end arch random_talisman x 10 y 7 end arch dungeon_magic x 10 y 8 end arch flagstone x 10 y 8 end arch random_wealth x 10 y 8 end arch dungeon_magic x 10 y 9 end arch flagstone x 10 y 9 end arch random_gem x 10 y 9 end arch dungeon_magic x 10 y 10 end arch flagstone x 10 y 10 end arch random_treasure x 10 y 10 end arch dungeon_magic x 10 y 11 end arch flagstone x 10 y 11 end arch random_gem x 10 y 11 end arch dungeon_magic x 10 y 12 end arch flagstone x 10 y 12 end arch random_scroll x 10 y 12 end arch dungeon_magic x 10 y 13 end arch flagstone x 10 y 13 end arch random_potion x 10 y 13 end arch dungeon_magic x 10 y 14 end arch flagstone x 10 y 14 end arch random_gem x 10 y 14 end arch dungeon_magic x 10 y 15 end arch flagstone x 10 y 15 end arch random_treasure x 10 y 15 end arch dungeon_magic x 10 y 16 end arch flagstone x 10 y 16 end arch random_talisman x 10 y 16 end arch dungeon_magic x 10 y 17 end arch flagstone x 10 y 17 end arch random_gem x 10 y 17 end arch dungeon_magic x 10 y 18 end arch flagstone x 10 y 18 end arch random_gem x 10 y 18 end arch dungeon_magic x 10 y 19 end arch flagstone x 10 y 19 end arch random_wealth x 10 y 19 end arch flagstone x 10 y 20 end arch cave2 x 10 y 20 end arch blocked x 10 y 21 end arch blocked x 10 y 22 end arch blocked x 10 y 23 end arch blocked x 10 y 24 end arch blocked x 10 y 25 end arch blocked x 10 y 26 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 11 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 11 y 1 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 11 y 2 end arch blocked x 11 y 3 end arch flagstone x 11 y 4 end arch cave4 x 11 y 4 end arch dungeon_magic x 11 y 5 end arch flagstone x 11 y 5 end arch random_wealth x 11 y 5 end arch dungeon_magic x 11 y 6 end arch flagstone x 11 y 6 end arch cwall_0 x 11 y 6 end arch dungeon_magic x 11 y 7 end arch flagstone x 11 y 7 end arch random_treasure x 11 y 7 end arch dungeon_magic x 11 y 8 end arch flagstone x 11 y 8 end arch random_gem x 11 y 8 end arch dungeon_magic x 11 y 9 end arch flagstone x 11 y 9 end arch cwall_0 x 11 y 9 end arch dungeon_magic x 11 y 10 end arch flagstone x 11 y 10 end arch random_gem x 11 y 10 end arch dungeon_magic x 11 y 11 end arch flagstone x 11 y 11 end arch random_scroll x 11 y 11 end arch dungeon_magic x 11 y 12 end arch flagstone x 11 y 12 end arch cwall_0 x 11 y 12 end arch dungeon_magic x 11 y 13 end arch flagstone x 11 y 13 end arch random_gem x 11 y 13 end arch dungeon_magic x 11 y 14 end arch flagstone x 11 y 14 end arch random_talisman x 11 y 14 end arch dungeon_magic x 11 y 15 end arch flagstone x 11 y 15 end arch cwall_0 x 11 y 15 end arch dungeon_magic x 11 y 16 end arch flagstone x 11 y 16 end arch random_gem x 11 y 16 end arch dungeon_magic x 11 y 17 end arch flagstone x 11 y 17 end arch random_treasure x 11 y 17 end arch dungeon_magic x 11 y 18 end arch flagstone x 11 y 18 end arch cwall_0 x 11 y 18 end arch dungeon_magic x 11 y 19 end arch flagstone x 11 y 19 end arch random_treasure x 11 y 19 end arch flagstone x 11 y 20 end arch cave2 x 11 y 20 end arch blocked x 11 y 21 end arch blocked x 11 y 22 end arch flagstone x 11 y 23 end arch teleporter hp 17 sp 12 speed 0.000000 resist_magic 30 resist_electricity 30 connected 10 x 11 y 23 end arch corpse name Zonk face imp.171 msg This Zonk is a symbol of bad luck. endmsg material 0 value 10000 weight 500 x 11 y 23 end arch blocked x 11 y 24 end arch blocked x 11 y 25 end arch blocked x 11 y 26 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 12 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 12 y 1 end arch demilich name blocked face blocked.111 randomitems none random_movement 0 x 12 y 2 end arch blocked x 12 y 3 end arch flagstone x 12 y 4 end arch cave4 x 12 y 4 end arch dungeon_magic x 12 y 5 end arch flagstone x 12 y 5 end arch random_treasure x 12 y 5 end arch dungeon_magic x 12 y 6 end arch flagstone x 12 y 6 end arch random_wealth x 12 y 6 end arch dungeon_magic x 12 y 7 end arch flagstone x 12 y 7 end arch random_potion x 12 y 7 end arch dungeon_magic x 12 y 8 end arch flagstone x 12 y 8 end arch random_food x 12 y 8 end arch dungeon_magic x 12 y 9 end arch flagstone x 12 y 9 end arch random_treasure x 12 y 9 end arch dungeon_magic x 12 y 10 end arch flagstone x 12 y 10 end arch random_treasure x 12 y 10 end arch dungeon_magic x 12 y 11 end arch flagstone x 12 y 11 end arch random_spells x 12 y 11 end arch dungeon_magic x 12 y 12 end arch flagstone x 12 y 12 end arch random_artifact x 12 y 12 end arch dungeon_magic x 12 y 13 end arch flagstone x 12 y 13 end arch random_wealth x 12 y 13 end arch dungeon_magic x 12 y 14 end arch flagstone x 12 y 14 end arch random_wealth x 12 y 14 end arch dungeon_magic x 12 y 15 end arch flagstone x 12 y 15 end arch random_potion x 12 y 15 end arch dungeon_magic x 12 y 16 end arch flagstone x 12 y 16 end arch random_wealth x 12 y 16 end arch dungeon_magic x 12 y 17 end arch flagstone x 12 y 17 end arch random_talisman x 12 y 17 end arch dungeon_magic x 12 y 18 end arch flagstone x 12 y 18 end arch random_wealth x 12 y 18 end arch dungeon_magic x 12 y 19 end arch flagstone x 12 y 19 end arch random_treasure x 12 y 19 end arch flagstone x 12 y 20 end arch cave2 x 12 y 20 end arch blocked x 12 y 21 end arch blocked x 12 y 22 end arch flagstone x 12 y 23 end arch teleporter hp 17 sp 12 speed 0.000000 resist_physical 30 resist_magic 30 resist_electricity 30 connected 11 x 12 y 23 end arch wdsm msg This famous armour grants permanent immunity to fire. Even the gods watch you with envy. Once you give it away, they will surely destroy it. endmsg resist_cold 60 last_sp 6 no_steal 0 x 12 y 23 end arch blocked x 12 y 24 end arch flagstone x 12 y 25 end arch magic_mouth name 2 msg Finally! You've reached Gothwolte's legendary treasure hoard. endmsg resist_magic 30 connected 2 x 12 y 25 end arch button_small name 2 resist_magic 30 weight 1000 connected 2 x 12 y 25 end arch creator name 1 other_arch small_shield resist_physical 30 connected 1 x 12 y 25 end arch blocked x 12 y 26 end arch blocked x 13 end arch blocked x 13 y 1 end arch blocked x 13 y 2 end arch blocked x 13 y 3 end arch flagstone x 13 y 4 end arch cave4 x 13 y 4 end arch dungeon_magic x 13 y 5 end arch flagstone x 13 y 5 end arch random_treasure x 13 y 5 end arch dungeon_magic x 13 y 6 end arch flagstone x 13 y 6 end arch random_gem x 13 y 6 end arch dungeon_magic x 13 y 7 end arch flagstone x 13 y 7 end arch gem face pretty_crystal.111 title of flawless beauty speed 0.000000 value 400000 weight 100 is_animated 0 x 13 y 7 end arch dungeon_magic x 13 y 8 end arch flagstone x 13 y 8 end arch random_spells x 13 y 8 end arch dungeon_magic x 13 y 9 end arch flagstone x 13 y 9 end arch random_gem x 13 y 9 end arch dungeon_magic x 13 y 10 end arch flagstone x 13 y 10 end arch random_shield x 13 y 10 end arch dungeon_magic x 13 y 11 end arch flagstone x 13 y 11 end arch random_treasure x 13 y 11 end arch dungeon_magic x 13 y 12 end arch flagstone x 13 y 12 end arch random_gem x 13 y 12 end arch dungeon_magic x 13 y 13 end arch flagstone x 13 y 13 end arch random_shield x 13 y 13 end arch dungeon_magic x 13 y 14 end arch flagstone x 13 y 14 end arch random_gem x 13 y 14 end arch dungeon_magic x 13 y 15 end arch flagstone x 13 y 15 end arch random_treasure x 13 y 15 end arch dungeon_magic x 13 y 16 end arch flagstone x 13 y 16 end arch random_wealth x 13 y 16 end arch dungeon_magic x 13 y 17 end arch flagstone x 13 y 17 end arch gem face pretty_crystal.111 title of flawless beauty speed 0.000000 value 400000 weight 100 is_animated 0 x 13 y 17 end arch dungeon_magic x 13 y 18 end arch flagstone x 13 y 18 end arch random_weapon x 13 y 18 end arch dungeon_magic x 13 y 19 end arch flagstone x 13 y 19 end arch random_potion x 13 y 19 end arch flagstone x 13 y 20 end arch cave2 x 13 y 20 end arch blocked x 13 y 21 end arch blocked x 13 y 22 end arch blocked x 13 y 23 end arch blocked x 13 y 24 end arch blocked x 13 y 25 end arch blocked x 13 y 26 end arch blocked x 14 end arch blocked x 14 y 1 end arch blocked x 14 y 2 end arch flagstone x 14 y 3 end arch cave24 x 14 y 3 end arch flagstone x 14 y 4 end arch cave9 x 14 y 4 end arch dungeon_magic x 14 y 5 end arch flagstone x 14 y 5 end arch random_talisman x 14 y 5 end arch dungeon_magic x 14 y 6 end arch flagstone x 14 y 6 end arch random_potion x 14 y 6 end arch dungeon_magic x 14 y 7 end arch flagstone x 14 y 7 end arch random_scroll x 14 y 7 end arch dungeon_magic x 14 y 8 end arch flagstone x 14 y 8 end arch random_treasure x 14 y 8 end arch dungeon_magic x 14 y 9 end arch flagstone x 14 y 9 end arch random_treasure x 14 y 9 end arch dungeon_magic x 14 y 10 end arch flagstone x 14 y 10 end arch random_gem x 14 y 10 end arch dungeon_magic x 14 y 11 end arch flagstone x 14 y 11 end arch random_gem x 14 y 11 end arch dungeon_magic x 14 y 12 end arch flagstone x 14 y 12 end arch random_treasure x 14 y 12 end arch dungeon_magic x 14 y 13 end arch flagstone x 14 y 13 end arch random_talisman x 14 y 13 end arch dungeon_magic x 14 y 14 end arch flagstone x 14 y 14 end arch random_treasure x 14 y 14 end arch dungeon_magic x 14 y 15 end arch flagstone x 14 y 15 end arch random_gem x 14 y 15 end arch dungeon_magic x 14 y 16 end arch flagstone x 14 y 16 end arch random_scroll x 14 y 16 end arch dungeon_magic x 14 y 17 end arch flagstone x 14 y 17 end arch random_gem x 14 y 17 end arch dungeon_magic x 14 y 18 end arch flagstone x 14 y 18 end arch random_gem x 14 y 18 end arch dungeon_magic x 14 y 19 end arch flagstone x 14 y 19 end arch random_talisman x 14 y 19 end arch flagstone x 14 y 20 end arch cave12 x 14 y 20 end arch flagstone x 14 y 21 end arch cave23 x 14 y 21 end arch blocked x 14 y 22 end arch blocked x 14 y 23 end arch blocked x 14 y 24 end arch blocked x 14 y 25 end arch blocked x 14 y 26 end arch flagstone x 15 end arch cave24 x 15 end arch flagstone x 15 y 1 end arch cave3 x 15 y 1 end arch flagstone x 15 y 2 end arch cave3 x 15 y 2 end arch flagstone x 15 y 3 end arch cave9 x 15 y 3 end arch dungeon_magic x 15 y 4 end arch flagstone x 15 y 4 end arch torch_1 food 0 material 0 no_pick 1 changing 0 x 15 y 4 end arch dungeon_magic x 15 y 5 end arch flagstone x 15 y 5 end arch random_food x 15 y 5 end arch dungeon_magic x 15 y 6 end arch flagstone x 15 y 6 end arch random_spells x 15 y 6 end arch dungeon_magic x 15 y 7 end arch flagstone x 15 y 7 end arch random_gem x 15 y 7 end arch dungeon_magic x 15 y 8 end arch flagstone x 15 y 8 end arch random_gem x 15 y 8 end arch dungeon_magic x 15 y 9 end arch flagstone x 15 y 9 end arch random_talisman x 15 y 9 end arch dungeon_magic x 15 y 10 end arch marble x 15 y 10 end arch slevel_2_2_2 no_pass 1 x 15 y 10 end arch dungeon_magic x 15 y 11 end arch marble x 15 y 11 end arch slevel_3_2 no_pass 1 x 15 y 11 end arch dungeon_magic x 15 y 12 end arch marble x 15 y 12 end arch slevel_3_2 no_pass 1 x 15 y 12 end arch dungeon_magic x 15 y 13 end arch marble x 15 y 13 end arch slevel_3_2 no_pass 1 x 15 y 13 end arch dungeon_magic x 15 y 14 end arch marble x 15 y 14 end arch slevel_2_2_1 no_pass 1 x 15 y 14 end arch dungeon_magic x 15 y 15 end arch flagstone x 15 y 15 end arch random_gem x 15 y 15 end arch dungeon_magic x 15 y 16 end arch flagstone x 15 y 16 end arch random_wealth x 15 y 16 end arch dungeon_magic x 15 y 17 end arch flagstone x 15 y 17 end arch random_gem x 15 y 17 end arch dungeon_magic x 15 y 18 end arch flagstone x 15 y 18 end arch random_treasure x 15 y 18 end arch dungeon_magic x 15 y 19 end arch flagstone x 15 y 19 end arch random_spells x 15 y 19 end arch dungeon_magic x 15 y 20 end arch flagstone x 15 y 20 end arch torch_1 food 0 material 0 no_pick 1 changing 0 x 15 y 20 end arch flagstone x 15 y 21 end arch cave12 x 15 y 21 end arch flagstone x 15 y 22 end arch cave3 x 15 y 22 end arch flagstone x 15 y 23 end arch cave3 x 15 y 23 end arch flagstone x 15 y 24 end arch cave3 x 15 y 24 end arch flagstone x 15 y 25 end arch cave23 x 15 y 25 end arch blocked x 15 y 26 end arch flagstone x 16 end arch cave4 x 16 end arch dungeon_magic x 16 y 1 end arch flagstone x 16 y 1 end arch dungeon_magic x 16 y 2 end arch flagstone x 16 y 2 end arch dungeon_magic x 16 y 3 end arch flagstone x 16 y 3 end arch dungeon_magic x 16 y 4 end arch flagstone x 16 y 4 end arch dungeon_magic x 16 y 5 end arch flagstone x 16 y 5 end arch random_gem x 16 y 5 end arch dungeon_magic x 16 y 6 end arch flagstone x 16 y 6 end arch random_treasure x 16 y 6 end arch dungeon_magic x 16 y 7 end arch flagstone x 16 y 7 end arch random_gem x 16 y 7 end arch dungeon_magic x 16 y 8 end arch flagstone x 16 y 8 end arch random_treasure x 16 y 8 end arch dungeon_magic x 16 y 9 end arch flagstone x 16 y 9 end arch random_treasure x 16 y 9 end arch dungeon_magic x 16 y 10 end arch marble x 16 y 10 end arch slevel_3_3 no_pass 1 x 16 y 10 end arch dungeon_magic x 16 y 11 end arch afloor_right x 16 y 11 end arch slevel_2_2_2 no_pass 1 x 16 y 11 end arch dungeon_magic x 16 y 12 end arch afloor_right x 16 y 12 end arch slevel_3_2 no_pass 1 x 16 y 12 end arch dungeon_magic x 16 y 13 end arch afloor_right x 16 y 13 end arch slevel_2_2_1 no_pass 1 x 16 y 13 end arch dungeon_magic x 16 y 14 end arch marble x 16 y 14 end arch slevel_3_1 no_pass 1 x 16 y 14 end arch dungeon_magic x 16 y 15 end arch flagstone x 16 y 15 end arch random_talisman x 16 y 15 end arch dungeon_magic x 16 y 16 end arch flagstone x 16 y 16 end arch random_food x 16 y 16 end arch dungeon_magic x 16 y 17 end arch flagstone x 16 y 17 end arch random_wealth x 16 y 17 end arch dungeon_magic x 16 y 18 end arch flagstone x 16 y 18 end arch random_potion x 16 y 18 end arch dungeon_magic x 16 y 19 end arch flagstone x 16 y 19 end arch random_shield x 16 y 19 end arch dungeon_magic x 16 y 20 end arch flagstone x 16 y 20 end arch dungeon_magic x 16 y 21 end arch flagstone x 16 y 21 end arch igate_closed_1 speed 0.500000 resist_physical 30 connected 1 x 16 y 21 end arch dungeon_magic x 16 y 22 end arch flagstone x 16 y 22 end arch dungeon_magic x 16 y 23 end arch flagstone x 16 y 23 end arch dungeon_magic x 16 y 24 end arch flagstone x 16 y 24 end arch flagstone x 16 y 25 end arch cave2 x 16 y 25 end arch blocked x 16 y 26 end arch flagstone x 17 end arch cave4 x 17 end arch dungeon_magic x 17 y 1 end arch flagstone x 17 y 1 end arch dungeon_magic x 17 y 2 end arch afloor_right x 17 y 2 end arch pentagram name exit type 66 slaying ../world hp 3 sp 23 x 17 y 2 end arch dungeon_magic x 17 y 3 end arch flagstone x 17 y 3 end arch dungeon_magic x 17 y 4 end arch flagstone x 17 y 4 end arch dungeon_magic x 17 y 5 end arch flagstone x 17 y 5 end arch random_talisman x 17 y 5 end arch dungeon_magic x 17 y 6 end arch flagstone x 17 y 6 end arch random_treasure x 17 y 6 end arch dungeon_magic x 17 y 7 end arch flagstone x 17 y 7 end arch random_artifact x 17 y 7 end arch dungeon_magic x 17 y 8 end arch flagstone x 17 y 8 end arch random_treasure x 17 y 8 end arch dungeon_magic x 17 y 9 end arch flagstone x 17 y 9 end arch random_treasure x 17 y 9 end arch dungeon_magic x 17 y 10 end arch marble x 17 y 10 end arch slevel_3_3 no_pass 1 x 17 y 10 end arch dungeon_magic x 17 y 11 end arch afloor_right x 17 y 11 end arch slevel_3_3 no_pass 1 x 17 y 11 end arch dungeon_magic x 17 y 12 end arch afloor_right x 17 y 12 end arch dungeon_magic x 17 y 13 end arch afloor_right x 17 y 13 end arch slevel_3_1 x 17 y 13 end arch a_bridge2 name stairway x 17 y 13 end arch dungeon_magic x 17 y 14 end arch marble x 17 y 14 end arch slevel_3_1 x 17 y 14 end arch a_bridge2 name stairway x 17 y 14 end arch dungeon_magic x 17 y 15 end arch flagstone x 17 y 15 end arch random_gem x 17 y 15 end arch dungeon_magic x 17 y 16 end arch flagstone x 17 y 16 end arch random_shield x 17 y 16 end arch dungeon_magic x 17 y 17 end arch flagstone x 17 y 17 end arch random_artifact x 17 y 17 end arch dungeon_magic x 17 y 18 end arch flagstone x 17 y 18 end arch random_treasure x 17 y 18 end arch dungeon_magic x 17 y 19 end arch flagstone x 17 y 19 end arch random_gem x 17 y 19 end arch dungeon_magic x 17 y 20 end arch flagstone x 17 y 20 end arch dungeon_magic x 17 y 21 end arch flagstone x 17 y 21 end arch igate_closed_1 speed 0.500000 resist_physical 30 connected 1 x 17 y 21 end arch dungeon_magic x 17 y 22 end arch flagstone x 17 y 22 end arch button_lever resist_physical 30 connected 1 x 17 y 22 end arch dungeon_magic x 17 y 23 end arch flagstone x 17 y 23 end arch stair_up_2 slaying guardians hp 23 sp 33 x 17 y 23 end arch dungeon_magic x 17 y 24 end arch flagstone x 17 y 24 end arch flagstone x 17 y 25 end arch cave2 x 17 y 25 end arch blocked x 17 y 26 end arch flagstone x 18 end arch cave4 x 18 end arch dungeon_magic x 18 y 1 end arch flagstone x 18 y 1 end arch dungeon_magic x 18 y 2 end arch flagstone x 18 y 2 end arch dungeon_magic x 18 y 3 end arch flagstone x 18 y 3 end arch dungeon_magic x 18 y 4 end arch flagstone x 18 y 4 end arch dungeon_magic x 18 y 5 end arch flagstone x 18 y 5 end arch random_treasure x 18 y 5 end arch dungeon_magic x 18 y 6 end arch flagstone x 18 y 6 end arch random_talisman x 18 y 6 end arch dungeon_magic x 18 y 7 end arch flagstone x 18 y 7 end arch random_gem x 18 y 7 end arch dungeon_magic x 18 y 8 end arch flagstone x 18 y 8 end arch random_shield x 18 y 8 end arch dungeon_magic x 18 y 9 end arch flagstone x 18 y 9 end arch random_talisman x 18 y 9 end arch dungeon_magic x 18 y 10 end arch marble x 18 y 10 end arch slevel_3_3 no_pass 1 x 18 y 10 end arch dungeon_magic x 18 y 11 end arch afloor_right x 18 y 11 end arch slevel_2_2_3 no_pass 1 x 18 y 11 end arch dungeon_magic x 18 y 12 end arch afloor_right x 18 y 12 end arch slevel_3_4 no_pass 1 x 18 y 12 end arch dungeon_magic x 18 y 13 end arch afloor_right x 18 y 13 end arch slevel_2_2_4 no_pass 1 x 18 y 13 end arch dungeon_magic x 18 y 14 end arch marble x 18 y 14 end arch slevel_3_1 no_pass 1 x 18 y 14 end arch dungeon_magic x 18 y 15 end arch flagstone x 18 y 15 end arch random_wealth x 18 y 15 end arch dungeon_magic x 18 y 16 end arch flagstone x 18 y 16 end arch random_wealth x 18 y 16 end arch dungeon_magic x 18 y 17 end arch flagstone x 18 y 17 end arch random_wealth x 18 y 17 end arch dungeon_magic x 18 y 18 end arch flagstone x 18 y 18 end arch random_treasure x 18 y 18 end arch dungeon_magic x 18 y 19 end arch flagstone x 18 y 19 end arch random_scroll x 18 y 19 end arch dungeon_magic x 18 y 20 end arch flagstone x 18 y 20 end arch dungeon_magic x 18 y 21 end arch flagstone x 18 y 21 end arch igate_closed_1 speed 0.500000 resist_physical 30 connected 1 x 18 y 21 end arch dungeon_magic x 18 y 22 end arch flagstone x 18 y 22 end arch dungeon_magic x 18 y 23 end arch flagstone x 18 y 23 end arch dungeon_magic x 18 y 24 end arch flagstone x 18 y 24 end arch flagstone x 18 y 25 end arch cave2 x 18 y 25 end arch blocked x 18 y 26 end arch flagstone x 19 end arch cave25 x 19 end arch flagstone x 19 y 1 end arch cave1 x 19 y 1 end arch flagstone x 19 y 2 end arch cave1 x 19 y 2 end arch flagstone x 19 y 3 end arch cave10 x 19 y 3 end arch dungeon_magic x 19 y 4 end arch flagstone x 19 y 4 end arch torch_1 food 0 material 0 no_pick 1 changing 0 x 19 y 4 end arch dungeon_magic x 19 y 5 end arch flagstone x 19 y 5 end arch random_gem x 19 y 5 end arch dungeon_magic x 19 y 6 end arch flagstone x 19 y 6 end arch random_treasure x 19 y 6 end arch dungeon_magic x 19 y 7 end arch flagstone x 19 y 7 end arch random_treasure x 19 y 7 end arch dungeon_magic x 19 y 8 end arch flagstone x 19 y 8 end arch random_scroll x 19 y 8 end arch dungeon_magic x 19 y 9 end arch flagstone x 19 y 9 end arch random_gem x 19 y 9 end arch dungeon_magic x 19 y 10 end arch marble x 19 y 10 end arch slevel_2_2_3 no_pass 1 x 19 y 10 end arch dungeon_magic x 19 y 11 end arch marble x 19 y 11 end arch slevel_3_4 no_pass 1 x 19 y 11 end arch dungeon_magic x 19 y 12 end arch marble x 19 y 12 end arch slevel_3_4 no_pass 1 x 19 y 12 end arch dungeon_magic x 19 y 13 end arch marble x 19 y 13 end arch slevel_3_4 no_pass 1 x 19 y 13 end arch dungeon_magic x 19 y 14 end arch marble x 19 y 14 end arch slevel_2_2_4 no_pass 1 x 19 y 14 end arch dungeon_magic x 19 y 15 end arch flagstone x 19 y 15 end arch random_wealth x 19 y 15 end arch dungeon_magic x 19 y 16 end arch flagstone x 19 y 16 end arch random_scroll x 19 y 16 end arch dungeon_magic x 19 y 17 end arch flagstone x 19 y 17 end arch random_talisman x 19 y 17 end arch dungeon_magic x 19 y 18 end arch flagstone x 19 y 18 end arch random_gem x 19 y 18 end arch dungeon_magic x 19 y 19 end arch flagstone x 19 y 19 end arch random_shield x 19 y 19 end arch dungeon_magic x 19 y 20 end arch flagstone x 19 y 20 end arch torch_1 food 0 material 0 no_pick 1 changing 0 x 19 y 20 end arch flagstone x 19 y 21 end arch cave11 x 19 y 21 end arch flagstone x 19 y 22 end arch cave1 x 19 y 22 end arch flagstone x 19 y 23 end arch cave1 x 19 y 23 end arch flagstone x 19 y 24 end arch cave1 x 19 y 24 end arch flagstone x 19 y 25 end arch cave22 x 19 y 25 end arch blocked x 19 y 26 end arch blocked x 20 end arch blocked x 20 y 1 end arch blocked x 20 y 2 end arch flagstone x 20 y 3 end arch cave25 x 20 y 3 end arch flagstone x 20 y 4 end arch cave10 x 20 y 4 end arch dungeon_magic x 20 y 5 end arch flagstone x 20 y 5 end arch random_wealth x 20 y 5 end arch dungeon_magic x 20 y 6 end arch flagstone x 20 y 6 end arch random_spells x 20 y 6 end arch dungeon_magic x 20 y 7 end arch flagstone x 20 y 7 end arch random_wealth x 20 y 7 end arch dungeon_magic x 20 y 8 end arch flagstone x 20 y 8 end arch random_gem x 20 y 8 end arch dungeon_magic x 20 y 9 end arch flagstone x 20 y 9 end arch random_potion x 20 y 9 end arch dungeon_magic x 20 y 10 end arch flagstone x 20 y 10 end arch random_gem x 20 y 10 end arch dungeon_magic x 20 y 11 end arch flagstone x 20 y 11 end arch random_wealth x 20 y 11 end arch dungeon_magic x 20 y 12 end arch flagstone x 20 y 12 end arch random_treasure x 20 y 12 end arch dungeon_magic x 20 y 13 end arch flagstone x 20 y 13 end arch random_talisman x 20 y 13 end arch dungeon_magic x 20 y 14 end arch flagstone x 20 y 14 end arch random_wealth x 20 y 14 end arch dungeon_magic x 20 y 15 end arch flagstone x 20 y 15 end arch random_potion x 20 y 15 end arch dungeon_magic x 20 y 16 end arch flagstone x 20 y 16 end arch random_treasure x 20 y 16 end arch dungeon_magic x 20 y 17 end arch flagstone x 20 y 17 end arch random_gem x 20 y 17 end arch dungeon_magic x 20 y 18 end arch flagstone x 20 y 18 end arch random_treasure x 20 y 18 end arch dungeon_magic x 20 y 19 end arch flagstone x 20 y 19 end arch random_gem x 20 y 19 end arch flagstone x 20 y 20 end arch cave11 x 20 y 20 end arch flagstone x 20 y 21 end arch cave22 x 20 y 21 end arch blocked x 20 y 22 end arch blocked x 20 y 23 end arch blocked x 20 y 24 end arch blocked x 20 y 25 end arch blocked x 20 y 26 end arch blocked x 21 end arch blocked x 21 y 1 end arch blocked x 21 y 2 end arch blocked x 21 y 3 end arch flagstone x 21 y 4 end arch cave4 x 21 y 4 end arch dungeon_magic x 21 y 5 end arch flagstone x 21 y 5 end arch random_potion x 21 y 5 end arch dungeon_magic x 21 y 6 end arch flagstone x 21 y 6 end arch random_talisman x 21 y 6 end arch dungeon_magic x 21 y 7 end arch flagstone x 21 y 7 end arch gem face pretty_crystal.111 title of flawless beauty speed 0.000000 value 400000 weight 100 is_animated 0 x 21 y 7 end arch dungeon_magic x 21 y 8 end arch flagstone x 21 y 8 end arch random_talisman x 21 y 8 end arch dungeon_magic x 21 y 9 end arch flagstone x 21 y 9 end arch random_treasure x 21 y 9 end arch dungeon_magic x 21 y 10 end arch flagstone x 21 y 10 end arch random_wealth x 21 y 10 end arch dungeon_magic x 21 y 11 end arch flagstone x 21 y 11 end arch random_wealth x 21 y 11 end arch dungeon_magic x 21 y 12 end arch flagstone x 21 y 12 end arch random_treasure x 21 y 12 end arch dungeon_magic x 21 y 13 end arch flagstone x 21 y 13 end arch random_wealth x 21 y 13 end arch dungeon_magic x 21 y 14 end arch flagstone x 21 y 14 end arch random_spells x 21 y 14 end arch dungeon_magic x 21 y 15 end arch flagstone x 21 y 15 end arch random_treasure x 21 y 15 end arch dungeon_magic x 21 y 16 end arch flagstone x 21 y 16 end arch random_gem x 21 y 16 end arch dungeon_magic x 21 y 17 end arch flagstone x 21 y 17 end arch gem face pretty_crystal.111 title of flawless beauty speed 0.000000 value 400000 weight 100 is_animated 0 x 21 y 17 end arch dungeon_magic x 21 y 18 end arch flagstone x 21 y 18 end arch random_treasure x 21 y 18 end arch dungeon_magic x 21 y 19 end arch flagstone x 21 y 19 end arch random_talisman x 21 y 19 end arch flagstone x 21 y 20 end arch cave2 x 21 y 20 end arch blocked x 21 y 21 end arch blocked x 21 y 22 end arch blocked x 21 y 23 end arch blocked x 21 y 24 end arch blocked x 21 y 25 end arch blocked x 21 y 26 end arch blocked x 22 end arch blocked x 22 y 1 end arch blocked x 22 y 2 end arch blocked x 22 y 3 end arch flagstone x 22 y 4 end arch cave4 x 22 y 4 end arch dungeon_magic x 22 y 5 end arch flagstone x 22 y 5 end arch random_treasure x 22 y 5 end arch dungeon_magic x 22 y 6 end arch flagstone x 22 y 6 end arch random_scroll x 22 y 6 end arch dungeon_magic x 22 y 7 end arch flagstone x 22 y 7 end arch random_treasure x 22 y 7 end arch dungeon_magic x 22 y 8 end arch flagstone x 22 y 8 end arch random_scroll x 22 y 8 end arch dungeon_magic x 22 y 9 end arch flagstone x 22 y 9 end arch random_spells x 22 y 9 end arch dungeon_magic x 22 y 10 end arch flagstone x 22 y 10 end arch random_shield x 22 y 10 end arch dungeon_magic x 22 y 11 end arch flagstone x 22 y 11 end arch random_gem x 22 y 11 end arch dungeon_magic x 22 y 12 end arch flagstone x 22 y 12 end arch random_artifact x 22 y 12 end arch dungeon_magic x 22 y 13 end arch flagstone x 22 y 13 end arch random_gem x 22 y 13 end arch dungeon_magic x 22 y 14 end arch flagstone x 22 y 14 end arch random_gem x 22 y 14 end arch dungeon_magic x 22 y 15 end arch flagstone x 22 y 15 end arch random_scroll x 22 y 15 end arch dungeon_magic x 22 y 16 end arch flagstone x 22 y 16 end arch random_talisman x 22 y 16 end arch dungeon_magic x 22 y 17 end arch flagstone x 22 y 17 end arch random_spells x 22 y 17 end arch dungeon_magic x 22 y 18 end arch flagstone x 22 y 18 end arch random_gem x 22 y 18 end arch dungeon_magic x 22 y 19 end arch flagstone x 22 y 19 end arch random_wealth x 22 y 19 end arch flagstone x 22 y 20 end arch cave2 x 22 y 20 end arch blocked x 22 y 21 end arch blocked x 22 y 22 end arch blocked x 22 y 23 end arch blocked x 22 y 24 end arch blocked x 22 y 25 end arch blocked x 22 y 26 end arch blocked x 23 end arch blocked x 23 y 1 end arch blocked x 23 y 2 end arch blocked x 23 y 3 end arch flagstone x 23 y 4 end arch cave4 x 23 y 4 end arch dungeon_magic x 23 y 5 end arch flagstone x 23 y 5 end arch random_gem x 23 y 5 end arch dungeon_magic x 23 y 6 end arch flagstone x 23 y 6 end arch cwall_0 x 23 y 6 end arch dungeon_magic x 23 y 7 end arch flagstone x 23 y 7 end arch random_wealth x 23 y 7 end arch dungeon_magic x 23 y 8 end arch flagstone x 23 y 8 end arch random_treasure x 23 y 8 end arch dungeon_magic x 23 y 9 end arch flagstone x 23 y 9 end arch cwall_0 x 23 y 9 end arch dungeon_magic x 23 y 10 end arch flagstone x 23 y 10 end arch random_treasure x 23 y 10 end arch dungeon_magic x 23 y 11 end arch flagstone x 23 y 11 end arch random_talisman x 23 y 11 end arch dungeon_magic x 23 y 12 end arch flagstone x 23 y 12 end arch cwall_0 x 23 y 12 end arch dungeon_magic x 23 y 13 end arch flagstone x 23 y 13 end arch random_weapon x 23 y 13 end arch dungeon_magic x 23 y 14 end arch flagstone x 23 y 14 end arch random_talisman x 23 y 14 end arch dungeon_magic x 23 y 15 end arch flagstone x 23 y 15 end arch cwall_0 x 23 y 15 end arch dungeon_magic x 23 y 16 end arch flagstone x 23 y 16 end arch random_treasure x 23 y 16 end arch dungeon_magic x 23 y 17 end arch flagstone x 23 y 17 end arch random_gem x 23 y 17 end arch dungeon_magic x 23 y 18 end arch flagstone x 23 y 18 end arch cwall_0 x 23 y 18 end arch dungeon_magic x 23 y 19 end arch flagstone x 23 y 19 end arch random_spells x 23 y 19 end arch flagstone x 23 y 20 end arch cave2 x 23 y 20 end arch blocked x 23 y 21 end arch blocked x 23 y 22 end arch blocked x 23 y 23 end arch flagstone x 23 y 24 end arch button_small name zonk resist_magic 30 resist_electricity 30 weight 1000 connected 10 x 23 y 24 end arch flagstone x 23 y 25 end arch button_small name zonk resist_magic 30 resist_electricity 30 weight 1000 connected 10 x 23 y 25 end arch flagstone x 23 y 26 end arch button_small name zonk resist_magic 30 resist_electricity 30 weight 1000 connected 10 x 23 y 26 end arch blocked x 24 end arch blocked x 24 y 1 end arch blocked x 24 y 2 end arch blocked x 24 y 3 end arch flagstone x 24 y 4 end arch cave4 x 24 y 4 end arch dungeon_magic x 24 y 5 end arch flagstone x 24 y 5 end arch random_food x 24 y 5 end arch dungeon_magic x 24 y 6 end arch flagstone x 24 y 6 end arch random_shield x 24 y 6 end arch dungeon_magic x 24 y 7 end arch flagstone x 24 y 7 end arch random_treasure x 24 y 7 end arch dungeon_magic x 24 y 8 end arch flagstone x 24 y 8 end arch random_food x 24 y 8 end arch dungeon_magic x 24 y 9 end arch flagstone x 24 y 9 end arch random_wealth x 24 y 9 end arch dungeon_magic x 24 y 10 end arch flagstone x 24 y 10 end arch random_spells x 24 y 10 end arch dungeon_magic x 24 y 11 end arch flagstone x 24 y 11 end arch random_wealth x 24 y 11 end arch dungeon_magic x 24 y 12 end arch flagstone x 24 y 12 end arch random_scroll x 24 y 12 end arch dungeon_magic x 24 y 13 end arch flagstone x 24 y 13 end arch random_gem x 24 y 13 end arch dungeon_magic x 24 y 14 end arch flagstone x 24 y 14 end arch random_treasure x 24 y 14 end arch dungeon_magic x 24 y 15 end arch flagstone x 24 y 15 end arch random_shield x 24 y 15 end arch dungeon_magic x 24 y 16 end arch flagstone x 24 y 16 end arch random_wealth x 24 y 16 end arch dungeon_magic x 24 y 17 end arch flagstone x 24 y 17 end arch random_scroll x 24 y 17 end arch dungeon_magic x 24 y 18 end arch flagstone x 24 y 18 end arch random_shield x 24 y 18 end arch dungeon_magic x 24 y 19 end arch flagstone x 24 y 19 end arch random_talisman x 24 y 19 end arch flagstone x 24 y 20 end arch cave2 x 24 y 20 end arch blocked x 24 y 21 end arch blocked x 24 y 22 end arch blocked x 24 y 23 end arch flagstone x 24 y 24 end arch button_small name zonk resist_magic 30 resist_electricity 30 weight 1000 connected 10 x 24 y 24 end arch flagstone x 24 y 25 end arch block_door_open name 2 speed 0.500000 resist_magic 30 value 1 connected 2 x 24 y 25 end arch creator name creator of chance other_arch boulder resist_fire 30 resist_cold 30 connected 20 x 24 y 25 end arch flagstone x 24 y 26 end arch button_small name zonk resist_magic 30 resist_electricity 30 weight 1000 connected 10 x 24 y 26 end arch blocked x 25 end arch blocked x 25 y 1 end arch blocked x 25 y 2 end arch blocked x 25 y 3 end arch flagstone x 25 y 4 end arch cave25 x 25 y 4 end arch flagstone x 25 y 5 end arch cave1 x 25 y 5 end arch flagstone x 25 y 6 end arch cave1 x 25 y 6 end arch flagstone x 25 y 7 end arch cave1 x 25 y 7 end arch flagstone x 25 y 8 end arch cave1 x 25 y 8 end arch flagstone x 25 y 9 end arch cave1 x 25 y 9 end arch flagstone x 25 y 10 end arch cave1 x 25 y 10 end arch flagstone x 25 y 11 end arch cave1 x 25 y 11 end arch flagstone x 25 y 12 end arch cave1 x 25 y 12 end arch flagstone x 25 y 13 end arch cave1 x 25 y 13 end arch flagstone x 25 y 14 end arch cave1 x 25 y 14 end arch flagstone x 25 y 15 end arch cave1 x 25 y 15 end arch flagstone x 25 y 16 end arch cave1 x 25 y 16 end arch flagstone x 25 y 17 end arch cave1 x 25 y 17 end arch flagstone x 25 y 18 end arch cave1 x 25 y 18 end arch flagstone x 25 y 19 end arch cave1 x 25 y 19 end arch flagstone x 25 y 20 end arch cave22 x 25 y 20 end arch blocked x 25 y 21 end arch blocked x 25 y 22 end arch blocked x 25 y 23 end arch flagstone x 25 y 24 end arch button_small name zonk resist_magic 30 resist_electricity 30 weight 1000 connected 10 x 25 y 24 end arch flagstone x 25 y 25 end arch button_small name zonk resist_magic 30 resist_electricity 30 weight 1000 connected 10 x 25 y 25 end arch flagstone x 25 y 26 end arch button_small name wdsm resist_physical 30 resist_magic 30 resist_electricity 30 weight 1000 connected 11 x 25 y 26 end -------------- 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 Sun Jun 6 08:27:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:46 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> <40BC2790.60201@sonic.net> <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> Message-ID: <20040606232702.0cc40e39.won_fang@yahoo.com.au> Skipped content of type multipart/signed-------------- 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 Jun 8 21:17:13 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] Re: pup_land volcano maps - Too difficult In-Reply-To: <40C6359D.2070900@laposte.net> References: <27299.1086727515@www62.gmx.net> <1334.1086731047@www62.gmx.net> <40C6359D.2070900@laposte.net> Message-ID: <1086747433.2945.4.camel@oberon.kameria> There are still some cone spells that do have weight and still push and I was looking into adding a check in the code so they either don't push walls and to add some weight to certain arches which should be heavier than they are. On Tue, 2004-06-08 at 17:54, Nicolas Weeger wrote: > > The only remaining problem then are the cancellation firewalls > > getting pushed by spell effects. Maybe it is possible to > > define in the pushing code simply never to push firewalls? > > This side effect of spells has been discussed. I think Mark removed > weights from some spells, thus making'em not push things anymore. > May need to update archetypes or such :) > > > AndreasV > > Nicolas '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 Jun 8 21:29:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] re: pup_land In-Reply-To: <1334.1086731047@www62.gmx.net> References: <27299.1086727515@www62.gmx.net> <1334.1086731047@www62.gmx.net> Message-ID: <1086748188.2945.17.camel@oberon.kameria> I have been slowly committing changes to the maps to remove the old multipart notation and am planning on doing pupland soon. I've tested it superficially course and that is why I am doing a few directories at a time so they can be tested but pupland is complicated. I am worried about stomping around the maps uninvited and I was waiting for Andi to surface before doing this. Also I want to remove a lot of the lake arches that have been used to smooth the coastlines in pupland (and other places) since smoothing is working out pretty well and these arches now wreck the effect - any concerns? _______________________________________________ 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 Jun 8 22:04:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] re: pup_land References: <1086748188.2945.17.camel@oberon.kameria> Message-ID: <9739.1086750292@www65.gmx.net> In reply to Todd Mitchell: > I have been slowly committing changes to the maps to remove the old > multipart notation and am planning on doing pupland soon. I've tested > it superficially course and that is why I am doing a few directories at > a time so they can be tested but pupland is complicated. > I am worried about stomping around the maps uninvited and I was waiting > for Andi to surface before doing this. What exactly are you planning to do? If it's just about re-saving maps with the JavaEditor and commiting, that shouldn't cause problems. If you want to fix suspected bugs for example, and get confused with the intended behaviour of certain mechanisms, you're welcome to ask me (Either on the list or personally, as you see fit). Generally, you're welcome to work on the pupland maps. Of course the pupland maps are a bit more difficult and more "touchy" than other maps, but I'm sure you have enough experience to handle it. Maybe the most difficult part about pupland is the balance, but even then, after a while one can get a feeling for that. > Also I want to remove a lot of the lake arches that have been used to > smooth the coastlines in pupland (and other places) since smoothing is > working out pretty well and these arches now wreck the effect - any > concerns? To be honest, I haven't played with a smoothing client yet. Nonetheless, I don't see a problem with that kind of change. Greetings, Andreas -- +++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++ GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl _______________________________________________ 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 Jun 8 22:54:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] re: pup_land In-Reply-To: <9739.1086750292@www65.gmx.net> References: <1086748188.2945.17.camel@oberon.kameria> <9739.1086750292@www65.gmx.net> Message-ID: <1086753279.2945.31.camel@oberon.kameria> > What exactly are you planning to do? If it's just about re-saving > maps with the JavaEditor and commiting, that shouldn't cause problems. > I have run a script that cleans up the multipart arch entries so that just the head is stored - it fixes some issues I have seen with certain maps and also makes the files a bit smaller and cleaner. It appears to be working fine so far and I have cleaned up about half the maps. I would rather do this when you are about than when you are not is all. Here's the details http://archives.real-time.com/pipermail/crossfire-devel/2004-March/005934.html here's the script I ran http://archives.real-time.com/pipermail/crossfire-devel/2004-March/005935.html P.S. I noticed that when you copy objects containing python scripts in the JavaEditor everything is copied properly except the parameter field (edit params). _______________________________________________ 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 Jun 8 23:25:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] Alchemy hashes In-Reply-To: References: Message-ID: <40C6913B.6080000@sonic.net> Todd Mitchell wrote: > I like the idea of a server specific 'seed' but can guess it would be unpopular to some. Some people make a career out of abusing the existing hash system. > As for the treasure lists - sounds good. It would make it easier to reuse parts of formulas as well. My only concern is that if you make it so the recipies become static after the first run then that might be a problem for adding/updating. I would rather have this as part of the collect build routine so new recipies could be added as easily as new arches. This also provides a place to generate book info. > > I haven't yet figured out a good way to deal with the generation of the recipes and updates. The problem with using collect is I don't know how many servers actually collect their own archetype & related data. Thus, either already collected versions get checked into CVS (and thus back to the same case, where everyone uses the same data) or recipes are missing. One thought is a special naming convention could perhaps be used - like 'random_recipe_...'. Then, when the server starts up, it parses the treasures file. It sees what 'random_recipe_...' entries it finds, and then compares them against the list of valid recipes, and adds (creates) new ones, or removes old ones or something. _______________________________________________ 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 Jun 9 07:01:19 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] re: pup_land References: <1086753279.2945.31.camel@oberon.kameria> Message-ID: <12633.1086782479@www51.gmx.net> Todd Mitchell wrote: > I have run a script that cleans up the multipart arch entries so that > just the head is stored - it fixes some issues I have seen with certain > maps and also makes the files a bit smaller and cleaner. > It appears to be working fine so far and I have cleaned up about half > the maps. I would rather do this when you are about than when you are > not is all. > > Here's the details [...] What your script does seems reasonable to me. I think it probably won't cause harm. The only fail case I could imagine is when some written text contains the lines: "More arch" And that is pretty unlikely to happen. > P.S. I noticed that when you copy objects containing python scripts in > the JavaEditor everything is copied properly except the parameter field > (edit params). Okay, I just fixed that. Greetings, AndreasV -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info _______________________________________________ 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 Jun 9 20:31:29 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] Possible problem with experience gained from Destruction spell Message-ID: As reported on cf.mf.net Experience gained from slaying monsters with the Destruction spell appears to go into the wrong skill. However, the 3 players that have tested this have all reported different skills; use magic item, throwing and total exp only. Has any one else encountered this? -- _______________________________________________ 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 Fri Jun 11 01:36:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] Possible problem with experience gained from Destruction spell In-Reply-To: References: Message-ID: <40C952FF.6050801@sonic.net> Rick Tanner wrote: > As reported on cf.mf.net > > Experience gained from slaying monsters with the Destruction spell appears > to go into the wrong skill. However, the 3 players that have tested this > have all reported different skills; use magic item, throwing and total exp > only. > > Has any one else encountered this? > There is a bug here - I've made a fix, will check into CVS. _______________________________________________ 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 Fri Jun 11 02:20:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <20040608104816.GA3872@idefix2.dvlp.in-medias-res.com> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> <40BC2790.60201@sonic.net> <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> <40BED0FA.8090704@sonic.net> <20040605161704.GA19176@idefix2.dvlp.in-medias-res.com> <40C40C14.4010000@sonic.net> <20040608104816.GA3872@idefix2.dvlp.in-medias-res.com> Message-ID: <40C95D37.5080501@sonic.net> Andreas Kirschbaum wrote: > > > OK, will declare it as a macro in define.h. > > The reason for using a function is that I generally tend to avoid > macros: when calling a macro, you have to worry about side effects > (due to possible multiple evaluations of parameters) and also do > not get type-checking by the compiler. I agree in principal. However, in this particular case, it is pretty clear there won't be any side effects (we aren't doing assignments). > > Java exhibits this limited usefulness that you have to explicitly > enable assertions (at runtime). The behavior of C assertions is > exactly the opposite: the C standard says (in section 7.2): > > |If NDEBUG is defined as a macro name at the point in the source > |file where is included, the assert macro is defined > |simply as > | > |#define assert(ignore) ((void)0) > > That is, assert() does nothing *only if* NDEBUG ("no debug") is > defined. Otherwise (i.e. if you do not explicitly disable the > assertions by defining NDEBUG), the assertions are active. Yeah, I see that - nice use of double negatives to make it more confusing. >>And if it is a critical error, to the extend that trying to >>continue will just cause it to core dump in the next line or >>two, might as well call abort right then and there. > > > These are the types of errors that should be checked with > assert(): to detect an inconsistent internal state that should > never be possible. Therefore assert() prints an error message to > stderr and calls abort() if it fails. I guess it's OK. The usefulness really depends on a few things: 1) Will the asserts reduce reliability (eg, cause aborts where without the assert, the code would still execute OK) 2) adversely effect performance - in this particular case, I don't see a problem, but one could see adding asserts in code that is caused really often not useful. 3) will it assist in debugging the code. Basically, does having them do more good than harm. Note however it may (depending on the function) be useful to have actual LOG messages that can print out lots of debugging info before actually crashing (ala the aborts in common/object.c) _______________________________________________ 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 Fri Jun 11 02:24:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] button-link bug? In-Reply-To: <19093.1086738585@www36.gmx.net> References: <19093.1086738585@www36.gmx.net> Message-ID: <40C95E29.7020406@sonic.net> Andreas Vogl wrote: > In the process of map testing, I stumbled across a weird bug: > Enter the map "treasure" (map is attached to this mail), > then leave, wait till the map is saved out. > You should see the following line: > > Saving map /pup_land/ancient/volcano/treasure > > Then re-enter the map. > Re-loading of the map somehow fails (player is trapped, and > surrounded by all-black squares. The server prints > the following message: > > Tried to add button-link without map. > Tried to add button-link without map. > Tried to add button-link without map. > ... > > I run latest CVS code and arches. Important: I'm using windows, > so it could be related to a character/ascii/linefeed parsing problem. > The bug happens every time I follow the steps described above. > It appears on other maps as well, but it only seems to happen on > maps with buttons. Button-free maps don't show any problem of this kind. Now fixed in CVS: common/loader.l, loader.c: Fix passed in size to get_ob_diff() - was one to long, causing string corruption. Actually, not a problem with the buttons - apparantly, this was the first map to set a duration_modifier value. _______________________________________________ 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 Fri Jun 11 13:38:44 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] Scorn Sale Shop - items end up under tables? Message-ID: <200406111338.44071.eracclists@bellsouth.net> Greetings Developers, Ok, so /scorn/shops/scorn.sale is on metalforge. There are "Charity Tables" in the entryway that are marked 'unique 1' and 'no_pick 1' so items dropped on them will survive a reset and the tables can't be "stolen". However, the items dropped on the tables end up -under- the tables when the map gets saved. This is not the desired result. Is this a known problem with unique items or is it something I can fix in the map editor? I'm at a loss how to fix it using the editor so pointers would be greatly appreciated. I want to keep the tables if possible. If not I can use floor tiles that are marked 'unique 1'. Thanks! Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 13:30:23 up 104 days, 7:26, 15 users, load average: 0.13, 0.18, 0.09 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Fri Jun 11 15:43:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_Scorn_Sale_Shop_-_items_end_up_under_tables=3F?= Message-ID: It would probably be better to make the floors unique instead of the tables as a general rule - it certainly makes it easier for others to examine the map and I am not sure if unique flag works the same way on items as it does on floors. IMHO however I would not make either the tables or floors unique and have the freebee tables vanish the items when the map resets. The items in the store will remain persistant so the idea is still there, I am not keen on having so much free stuff there on a unique map basis. If people can find everything for free then the economy suffers - having a place to drop givaway items is fine but let it get cleaned up with a reset. > Greetings Developers, > > Ok, so /scorn/shops/scorn.sale is on metalforge. There are "Charity > Tables" in the entryway that are marked 'unique 1' and 'no_pick 1' so > items dropped on them will survive a reset and the tables can't be > "stolen". However, the items dropped on the tables end up -under- the > tables when the map gets saved. This is not the desired result. > > Is this a known problem with unique items or is it something I can > fix in the map editor? I'm at a loss how to fix it using the editor > so pointers would be greatly appreciated. I want to keep the tables > if possible. If not I can use floor tiles that are marked 'unique 1'. > > Thanks! > Gene (poof|Galahad) > -- > Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 > 13:30:23 up 104 days, 7:26, 15 users, load average: 0.13, 0.18, 0.09 > ERA Computer Consulting - http://www.eracc.com/ > eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ 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 Fri Jun 11 17:33:13 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] Scorn Sale Shop - items end up under tables? In-Reply-To: References: Message-ID: <200406111733.13389.eracclists@bellsouth.net> I've subscribed to the maps list now for map discussions. I posted that original message to crossfire-devel because I was wondering about the items ending up under the tables being a server code thing. This message is also going to the maps list. Please reply on the maps list to discuss this further. TIA! On Friday 11 June 2004 15:43 Todd Mitchell wrote: > It would probably be better to make the floors unique instead of > the tables as a general rule - it certainly makes it easier for > others to examine the map and I am not sure if unique flag works > the same way on items as it does on floors. IMHO however I would > not make either the tables or floors unique and have the freebee > tables vanish the items when the map resets. The items in the > store will remain persistant so the idea is still there, I am not > keen on having so much free stuff there on a unique map basis. If > people can find everything for free then the economy suffers - > having a place to drop givaway items is fine but let it get cleaned > up with a reset. I understand about too much "free" stuff. Before I make changes lets allow the existing map to stay there for a week or so. If it looks like there is too much junk accumulating in the "charity" area I will change it to where the items are removed at a reset. However, I sat in there for an hour today wearing God Finger and watching. The stuff in the charity area seems to be turning over rather quickly. One player even grabbed everything that was there and then sold it. If I want to drop some nice rings for newbies to take for free I like the idea of having a place where I can drop them for free and they don't disappear in a couple of hours. That was my reason for creating the 10 unique tables. If your concern proves unfounded then I will replace the tables with unique floor tiles in an updated map. A thought - what if I used a floor tile but changed the face to a table? Is that workable? Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 16:51:10 up 104 days, 10:46, 15 users, load average: 0.00, 0.03, 0.05 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 12 00:43:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:47 2005 Subject: [CF-Devel] random map patch Message-ID: <1087018990.4021.63.camel@oberon.kameria> This patch adds a setting for random maps (put no_return_final_map 1 in the mesg text for the random map entrance) an override on putting a return exit on a final map. This is useful if you want different random maps to point to the same final map. The default behaviour is to place a return exit on the final map. This override setting should only be used on purpose and the final map must have an alternate exit! The patch also adds the map level to the random map sign for players to evaluate if they should be attempting the map. I know level is a loaded term when dealing with random maps but so much relies on the style maps and it is still a bit useful to post IMHO. Ideas for more work in this area - a way to have the map difficulty be based on the player level, this would make the random maps somewhat more reusable. -------------- next part -------------- A non-text attachment was scrubbed... Name: randommap.patch Type: text/x-patch Size: 7955 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040612/de64627a/randommap.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 Sat Jun 12 02:53:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] Scorn Sale Shop - items end up under tables? In-Reply-To: <200406111733.13389.eracclists@bellsouth.net> References: <200406111733.13389.eracclists@bellsouth.net> Message-ID: <40CAB665.9010509@sonic.net> Handling of unique is special. If the entire map is marked as unique - pretty simple, the entire map gets saved out. If the floor is marked as unique (FLAG_UNIQUE and FLAG_IS_FLOOR), then the floor and all objects above it are saved on the unique map. If just an object is marked as unique, then only that object is saved out. This is sort of necessary - otherwise, if a player had a unique object (say old apartment key), you don't want them dropping it someplace and now making that entier space unique. So the correct approach here is to make the floor space unique, and not the table, because that doesn't work. The reason the stacking 'changed' is the way the loading/saving happens. When unique objects are saved, they get saved to a different file. So when it comes to load the map, it loads all the original objects either from the temp map or original map. It then loads up the objects marked as unique. For floors, it does some extra processing and remove the old (original) objects on that space before loading the new ones. But for objects that are only marked as 'unique', those get loaded last and put on top of the other objects on the space. There only real possible fix to this is to add some information during save, like 'stacking order'. So when a space is saved it, it would number the stacking order 0, 1, 2, 3, ... When it goes to load them, it may load objects from the original maps at level 0, 1, 3. It then loads the object from the unique map, sees it order is 2, and inserts in the right place. However, thi is a lot of work for not a lot of gain - there aren't tons of unique objects in the game, and having them go to the top probably isn't that big a deal - when you drop objects, due to merging, the stacking order can change there anyways. _______________________________________________ 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 Jun 8 20:27:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] DM - God Finger - bleah! In-Reply-To: <20040606231326.4e11bb7c.won_fang@yahoo.com.au> Message-ID: On Sun, 6 Jun 2004, David Seikel wrote: > On Mon, 31 May 2004 11:15:47 +0200 (CEST) Palfy Tamas > wrote: > > > Personally I find it hard too. BUT, as for one reason - one that's not > > to be neglected - peepo hate to know they can be observed anytime. And > > _this_ fact they _really_ should know. (I mean - the fact that they > > _can_ be under surveillance anytime, without a warning.) > > When people go overboard on privacy issues like this I feel the need to point out some truths about how the Internet really works. Seems like you're completely unable to understand what I'm trying to talk about. A very joyful thing, peepo think they're smart as hell and very generous of them sharing their *unique* and *helpful* knowledge. Knowing lotsa truths "about how the Internet really works" has nothing to do about this. Just to state the strongest argument right at the start, I think it's obvious that when our system cannot make certain things work - and this not being our own fault - we still should have to try everything to make things work as best as they could. Ya ken tell me lotsa things why this is so pointless or why it is entirely superfluous to have rules about privacy issues on CF for example, I simply know the fact that something to work needs every of it's parts to work, and well a half-working thing is better than a complete useless one. So I just tell ya something maahn, start thinking like "I do my job - I hope others will do theirs as well" and ASAP forget things like "Why bother - they not doin' it - Hell I won't either!" And again - how the hell comes this here? Surveying policy on a MUD is - I think - a little different than internet security issues. Beides, CF have ordinary peepo with ordinary claims, nothing special, and privacy is one of 'em. If one thinks "The fact as a DM I can watch any players move shouldn't bother players - that's the way it is" and bullshit like that, then this not-a-big-deal fact should be clear to every player. Put in MOD or something like that. That's the fair way it is. As for me I would hate the to know somebody could watch me reading books while sitting on the toilet - while I never can be sure. Like internet. Da fact that the "information that flows from my computer to the server" could be observed by ad-lib entities doesn't mean they really do it, in fact it's most probable they _don't_. I wonder how many "new" things I have written down here, but I think _none_. Just like the one I answered with this letter. Two completely non-informative mails, I _like_ thing like this. Little bit funny. But more annoying. > > The Internet is a co-operative public medium. Information flows from your computer to the server and back via any number of computers, routers, switches, etc. The path through the world wide network can change from one instance to the next. The owners of the intervening systems can be anybody in the world. All these people, and anybody that has access to these systems, can snoop on whatever information is travelling through their hardware at any time. > > Some of the methods used to get information from one place to another are broadcast media, you don't need to be on the path to snoop, you could just be on the same section of the network. > > Server computers tend to log some of the information passing to and from their systems. Basic information about files and pages downloaded from the web and email's tend to get logged. Some games will log information. > > If you want privacy on the Internet, use strong encryption, but assume that everything else you do is public knowledge. > > To illustrate these points, a few years ago I was connecting to my bosses server in the same city on the east coast of Australia that I was in at the time, a distance of a few kilometres. Things seemed a little slower than I expected, so I investigated. There was a fault in my ISP's systems at the time, so my traffic was going all the way to the west coast and back again, several thousand kilometres. Since this was work related, involving sensitive commercial information, I was using strong encryption anyway. Only the delay was an issue. > > Crossfire does not encrypt it's protocol, so whatever "secrets" players may be telling one another using Crossfire have no guarantee to remain secret. > > People that own servers have every right to classify certain activities on the server as abuse of the services provided, and to use whatever tools are available to them to track down these abuses in an effort to stop them. DM's should be able to snoop on whatever information passes through the Crossfire protocol, it's part of their job. > > Crossfire is only a game... > > > [The information contained in this email is public domain, and can be used by anybody for any reason. Hi mum if you are snooping.] B-) > _______________________________________________ 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 Jun 12 18:19:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] python plugin drop patch Message-ID: <1087082397.2507.35.camel@oberon.kameria> This is a wild stab at fixing the problem with the python plugin not calling the apply hook when applied/worn items are directly droped instead of unworn/unapplied. Please look it over as it is still a bit of voodo to me and I really really want this bug fixed so I can finish my smugglers cove maps. It works for my wear disguise script anyway and I haven't seen any ill effects (yet). -------------- next part -------------- A non-text attachment was scrubbed... Name: plugindrop.patch Type: text/x-patch Size: 994 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040612/a1542557/plugindrop.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 Sun Jun 13 03:33:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] The 'name command Message-ID: <200406130333.53240.eracclists@bellsouth.net> Greets Developer Types, A player was asking if DMs could change his name. Is that the purpose of the 'name command? If so, does it also handle changing apartment location names or what? I don't know the answer to his questions so I ask here. The 'help name is useless: Help about 'name' Change players name. Also, how does one use this command? 'name' is not a valid command. TIA Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 03:30:19 up 105 days, 21:26, 15 users, load average: 0.00, 0.07, 0.08 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Sun Jun 13 12:37:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] Bug in stealing code In-Reply-To: <40C95D37.5080501@sonic.net> References: <20040528210251.GA13849@idefix2.dvlp.in-medias-res.com> <40BC2790.60201@sonic.net> <20040602164754.GA25304@idefix2.dvlp.in-medias-res.com> <40BED0FA.8090704@sonic.net> <20040605161704.GA19176@idefix2.dvlp.in-medias-res.com> <40C40C14.4010000@sonic.net> <20040608104816.GA3872@idefix2.dvlp.in-medias-res.com> <40C95D37.5080501@sonic.net> Message-ID: <20040613173701.GA23822@idefix2.dvlp.in-medias-res.com> Commited to CVS. (Converted call to assert() into LOG().) _______________________________________________ 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 Sun Jun 13 16:18:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] maps-bigworld/scorn/houses/jones bug Message-ID: <200406131618.23315.kbulgrien@worldnet.att.net> Jones house in Scorn has a bug. Two exit squares warp the player near to the city square instead of to the exterior of the house. Here is the diff for a fix. Perhaps someone can commit this change to CVS: $ diff -u maps-bigworld/scorn/houses/jones.old maps-bigworld/scorn/houses/jones --- maps-bigworld/scorn/houses/jones.old 2004-06-13 16:03:34.119723432 -0500 +++ maps-bigworld/scorn/houses/jones 2004-06-13 16:10:21.444800608 -0500 @@ -34,18 +34,18 @@ y 2 end arch exit -slaying /world/world_105_115 -hp 9 -sp 35 +slaying /world/world_105_116 +hp 2 +sp 8 y 3 end arch tree y 3 end arch exit -slaying /world/world_105_115 -hp 9 -sp 35 +slaying /world/world_105_116 +hp 2 +sp 8 y 4 end arch tree _______________________________________________ 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 Sun Jun 13 16:55:45 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] maps-bigworld/scorn/houses/jones bug In-Reply-To: <200406131618.23315.kbulgrien@worldnet.att.net> References: <200406131618.23315.kbulgrien@worldnet.att.net> Message-ID: <1087163745.2472.7.camel@oberon.kameria> Lately I have been having a lot more fun using the patch submission system on the sourceforge site to do these map updates/patches than keeping track of these sent to the mailing list. That system allows uploads of the patch to be to one location, tracking and comments to be made. I have a proposal - lets use the sourceforge patch sytem to track these sort of changes to maps (maybe even adding new maps too.) Just a suggestion - but it is more likely to get done faster (by me anyway) if I don't have to search through my mail to find all the map patches to test and commit. It helps since I will usually do things when I have time so if there are a few items I can tackle in the patcher (or bug tracker) then I will more likely do them. My suggestion - upload patch to sourceforge and send a message on the maps mailing list saying you did it. This might work well for code patches/dev list too. On Sun, 2004-06-13 at 17:18, Kevin R. Bulgrien wrote: > Jones house in Scorn has a bug. Two exit squares warp the > player near to the city square instead of to the exterior of > the house. > > Here is the diff for a fix. Perhaps someone can commit this > change to CVS: > > $ diff -u maps-bigworld/scorn/houses/jones.old > maps-bigworld/scorn/houses/jones > --- maps-bigworld/scorn/houses/jones.old 2004-06-13 16:03:34.119723432 > -0500 > +++ maps-bigworld/scorn/houses/jones 2004-06-13 16:10:21.444800608 -0500 > @@ -34,18 +34,18 @@ > y 2 > end > arch exit > -slaying /world/world_105_115 > -hp 9 > -sp 35 > +slaying /world/world_105_116 > +hp 2 > +sp 8 > y 3 > end > arch tree > y 3 > end > arch exit > -slaying /world/world_105_115 > -hp 9 > -sp 35 > +slaying /world/world_105_116 > +hp 2 > +sp 8 > y 4 > end > arch tree > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ 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 Sun Jun 13 17:12:31 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] maps-bigworld/scorn/houses/jones bug In-Reply-To: <1087163745.2472.7.camel@oberon.kameria> References: <200406131618.23315.kbulgrien@worldnet.att.net> <1087163745.2472.7.camel@oberon.kameria> Message-ID: <40CCD14F.9070905@laposte.net> Todd Mitchell a ?crit : > Lately I have been having a lot more fun using the patch submission > system on the sourceforge site to do these map updates/patches than > keeping track of these sent to the mailing list. That system allows > uploads of the patch to be to one location, tracking and comments to be > made. I like your idea. SF requires login a such for patch modification, so another hassle (maybe). On the other hand, it lets 1) us developers follow what patches have been committed or not 2) us know when a patch was submitted 3) other users get patches we don't want to commit in the 'official' crossfire sources but which still can be useful Nicolas 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 Sun Jun 13 17:45:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] maps-bigworld/scorn/houses/jones bug In-Reply-To: <200406131618.23315.kbulgrien@worldnet.att.net> References: <200406131618.23315.kbulgrien@worldnet.att.net> Message-ID: <1087166717.2479.0.camel@oberon.kameria> Fixed the exits in CVS. On Sun, 2004-06-13 at 17:18, Kevin R. Bulgrien wrote: > Jones house in Scorn has a bug. Two exit squares warp the > player near to the city square instead of to the exterior of > the house. > > Here is the diff for a fix. Perhaps someone can commit this > change to CVS: > > $ diff -u maps-bigworld/scorn/houses/jones.old > maps-bigworld/scorn/houses/jones > --- maps-bigworld/scorn/houses/jones.old 2004-06-13 16:03:34.119723432 > -0500 > +++ maps-bigworld/scorn/houses/jones 2004-06-13 16:10:21.444800608 -0500 > @@ -34,18 +34,18 @@ > y 2 > end > arch exit > -slaying /world/world_105_115 > -hp 9 > -sp 35 > +slaying /world/world_105_116 > +hp 2 > +sp 8 > y 3 > end > arch tree > y 3 > end > arch exit > -slaying /world/world_105_115 > -hp 9 > -sp 35 > +slaying /world/world_105_116 > +hp 2 > +sp 8 > y 4 > end > arch tree > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel _______________________________________________ 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 Sun Jun 13 17:45:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] Scorn east wall warning Message-ID: <40CCD90F.3050400@laposte.net> A player just successfully casted spells in Scorn itself. It's easy to do: exit Scorn from east side, fire west => your spell crosses guard house & goes into the main town. The reason is simple: the 2 wall tiles are NOT no_pass, since they are exits linking to guard house. A spell will simply cross that without getting teleported (for obvious reason). And since outside of Scorn is not no_magic, you can cast (as spells ignore the 'no_magic' when propagating) This allows players to cast spells, and kill others (imagine meteor storm there, baaaaaaaad O.o) So what are ways against that? I see 2 obvious: 1) put something like counterspell on the tiles, to block spell 2) expand guard house to be 3 tiles, and make the middle one blocking - prolly the easiest & best way. Opinions? Nicolas 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 Sun Jun 13 19:17:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] Scorn east wall warning In-Reply-To: <40CCD90F.3050400@laposte.net> References: <40CCD90F.3050400@laposte.net> Message-ID: <1087172273.2479.3.camel@oberon.kameria> On Sun, 2004-06-13 at 18:45, Nicolas Weeger wrote: > A player just successfully casted spells in > Scorn itself. [...] 2) expand guard house to be 3 tiles, and make the middle one blocking > - prolly the easiest & best way. > I like #2 - I also tweeked the guardhouse a bit. Commited to CVS. _______________________________________________ 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 Sun Jun 13 20:16:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] maps-bigworld/scorn/houses/jones bug In-Reply-To: <40CCD14F.9070905@laposte.net> References: <200406131618.23315.kbulgrien@worldnet.att.net> <1087163745.2472.7.camel@oberon.kameria> <40CCD14F.9070905@laposte.net> Message-ID: <40CCFC79.8080502@sonic.net> Nicolas Weeger wrote: > Todd Mitchell a ?crit : > >> Lately I have been having a lot more fun using the patch submission >> system on the sourceforge site to do these map updates/patches than >> keeping track of these sent to the mailing list. That system allows >> uploads of the patch to be to one location, tracking and comments to be >> made. > > > > I like your idea. > SF requires login a such for patch modification, so another hassle (maybe). > On the other hand, it lets > 1) us developers follow what patches have been committed or not > 2) us know when a patch was submitted > 3) other users get patches we don't want to commit in the 'official' > crossfire sources but which still can be useful Just to carry this point, I'd much rather see all bug reports be done on sourceforge also, and not sent to any of the mailing lists. The rationale is quite simple - there is no tracking on the mailing lists - if everyone on them deletes the message (someone else will fix it, accidental deletion, whatever), the bug report is effectively lost. In addition, it makes it much easier to see all open bugs. so when new developers show up, it is very easy to see what bugs are outstanding, instead of having to search the mailing lists. _______________________________________________ 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 Sun Jun 13 22:21:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] maps-bigworld/scorn/houses/jones bug In-Reply-To: <1087163745.2472.7.camel@oberon.kameria> References: <200406131618.23315.kbulgrien@worldnet.att.net> <1087163745.2472.7.camel@oberon.kameria> Message-ID: <200406132221.40738.kbulgrien@worldnet.att.net> On Sunday 13 June 2004 16:55, Todd Mitchell wrote: > I have a proposal - lets use the sourceforge patch sytem to track these > sort of changes to maps (maybe even adding new maps too.) > Just a suggestion - but it is more likely to get done faster (by me > anyway) if I don't have to search through my mail to find all the map > patches to test and commit. It helps since I will usually do things > when I have time so if there are a few items I can tackle in the patcher > (or bug tracker) then I will more likely do them. > My suggestion - upload patch to sourceforge and send a message on the > maps mailing list saying you did it. > > This might work well for code patches/dev list too. Works for me... It sort of slipped my mind that there was a SF site for some reason. I have a SF account... I agree completely about being able to track changes. I use GForge heavily where I work - for the very same reasons. Thanks for the reminder. _______________________________________________ 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 Jun 14 00:22:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:48 2005 Subject: [CF-Devel] The 'name command In-Reply-To: <200406130333.53240.eracclists@bellsouth.net> References: <200406130333.53240.eracclists@bellsouth.net> Message-ID: <40CD3619.3040103@sonic.net> ERACC wrote: > Greets Developer Types, > > A player was asking if DMs could change his name. Is that the purpose > of the 'name command? If so, does it also handle changing apartment > location names or what? I don't know the answer to his questions so I > ask here. The 'help name is useless: > > Help about 'name' > Change players name. > > Also, how does one use this command? > > 'name' is not a valid command. > There is no such thing as a 'name command, hence the error messages presented. there is a 'rename' command, but that is to give custom names to objects in your inventory (eg, marks cool sword). Probably more useful for objects that have the same name but you want to differentiate (sacks and other containers come to mind). There is no in game way at current time to rename players. _______________________________________________ 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 Jun 14 01:09:00 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] The 'name command In-Reply-To: <40CD3619.3040103@sonic.net> References: <200406130333.53240.eracclists@bellsouth.net> <40CD3619.3040103@sonic.net> Message-ID: <200406140109.00550.eracclists@bellsouth.net> On Monday 14 June 2004 00:22 Mark Wedel wrote: > ERACC wrote: > > Greets Developer Types, > > > > A player was asking if DMs could change his name. Is that the > > purpose of the 'name command? If so, does it also handle changing > > apartment location names or what? I don't know the answer to his > > questions so I ask here. The 'help name is useless: > > > > Help about 'name' > > Change players name. > > > > Also, how does one use this command? > > > > 'name' is not a valid command. > > There is no such thing as a 'name command, hence the error > messages presented. Then why is there "help" about a command 'name? That is very odd don't you agree? Try it - 'help name. > there is a 'rename' command, but that is to give custom names to > objects in your inventory (eg, marks cool sword). Probably more > useful for objects that have the same name but you want to > differentiate (sacks and other containers come to mind). Yes, I have used 'rename many times. > There is no in game way at current time to rename players. Ok. But it is strange that there is a response to 'help name that states it changes players name if there is no such thing. Thanks for the reply. Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 01:05:32 up 106 days, 19:01, 10 users, load average: 0.04, 0.40, 0.72 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Jun 14 02:33:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] Scorn east wall warning In-Reply-To: <1087172273.2479.3.camel@oberon.kameria> References: <40CCD90F.3050400@laposte.net> <1087172273.2479.3.camel@oberon.kameria> Message-ID: <40CD54CE.5010700@laposte.net> > I like #2 - I also tweeked the guardhouse a bit. Commited to CVS. now that's what i call quick fixing - thanks Todd! Nicolas _______________________________________________ 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 Jun 14 23:14:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] The 'name command In-Reply-To: <200406140109.00550.eracclists@bellsouth.net> References: <200406130333.53240.eracclists@bellsouth.net> <40CD3619.3040103@sonic.net> <200406140109.00550.eracclists@bellsouth.net> Message-ID: <40CE779D.8040402@sonic.net> ERACC wrote: > On Monday 14 June 2004 00:22 > Mark Wedel wrote: > > >>ERACC wrote: >> >>>Greets Developer Types, >>> >>>A player was asking if DMs could change his name. Is that the >>>purpose of the 'name command? If so, does it also handle changing >>>apartment location names or what? I don't know the answer to his >>>questions so I ask here. The 'help name is useless: >>> >>> Help about 'name' >>> Change players name. >>> >>>Also, how does one use this command? >>> >>> 'name' is not a valid command. >> >> There is no such thing as a 'name command, hence the error >>messages presented. > > > Then why is there "help" about a command 'name? That is very odd > don't you agree? Try it - 'help name. Left over help file from way back when. That file has existed (unchanged) since when crossfire was first put into CVS. I'll remove it from CVS. _______________________________________________ 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 Jun 15 02:19:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] python plugin drop patch In-Reply-To: <1087082397.2507.35.camel@oberon.kameria> References: <1087082397.2507.35.camel@oberon.kameria> Message-ID: <40CEA314.2090000@sonic.net> Todd Mitchell wrote: > This is a wild stab at fixing the problem with the python plugin not > calling the apply hook when applied/worn items are directly droped > instead of unworn/unapplied. Please look it over as it is still a bit > of voodo to me and I really really want this bug fixed so I can finish > my smugglers cove maps. It works for my wear disguise script anyway and > I haven't seen any ill effects (yet). One effect that I think will happen is that when a player manually unapplies the object, the apply event script will be run twice - once from manual_apply, and once from unapply_special. I'm not sure if this will have any bad effects, but I could certainly see the possibility of that happening. Also looking at the code in general, it seems this has to get to the script to figure if the object is being applied/unapplied. So that's just something that the script has to be aware of. One solution to this problem is to move the suggested code change into apply_special. And then change manual_apply to not call the scripting if it knows apply special will take care of it (basically just move a switch statement for checking for those objects to near the top of the manual_apply function, and if it passes those checks, call the event stuff for all the other objects manual_apply deal with. _______________________________________________ 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 Jun 15 02:25:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] random map patch In-Reply-To: <1087018990.4021.63.camel@oberon.kameria> References: <1087018990.4021.63.camel@oberon.kameria> Message-ID: <40CEA46F.5030806@sonic.net> Todd Mitchell wrote: > This patch adds a setting for random maps (put no_return_final_map 1 in > the mesg text for the random map entrance) an override on putting a > return exit on a final map. This is useful if you want different random > maps to point to the same final map. The default behaviour is to place a > return exit on the final map. This override setting should only be used > on purpose and the final map must have an alternate exit! > The patch also adds the map level to the random map sign for players to > evaluate if they should be attempting the map. I know level is a loaded > term when dealing with random maps but so much relies on the style maps > and it is still a bit useful to post IMHO. > > Ideas for more work in this area > - a way to have the map difficulty be based on the player level, this > would make the random maps somewhat more reusable. That patch fundamentally looks ok. But as a stylistic point, I generally don't like variable names to be in negative notation (no_...) I'd prefer the positive form be used (return_final_map), and as necessary, have that default to 1, and only if the map has something like 'return_final_map 0' turn it off. This just makes the code a littler when you see things like if (!no_return_final_map) It also makes it easier to reuse variables (if for example at some point, someone had the idea to have other meanings, the meaning still remains clear for more than just true/false values. _______________________________________________ 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 Jun 15 02:47:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-maps] Re: [CF-Devel] Scorn Sale Shop - items end up under tables? In-Reply-To: <40CEA872.7090505@sonic.net> References: <200406111733.13389.eracclists@bellsouth.net> <1087057358.2483.17.camel@oberon.kameria> <40CB5132.4070700@sonic.net> <1087071577.2507.29.camel@oberon.kameria> <40CEA872.7090505@sonic.net> Message-ID: <40CEA995.2040308@laposte.net> > 2) various skills could be associated with the different gods (not > necessarily a 1:1 mapping - multiple skills may be sponsored by > different gods, and any one god many also sponsor multiple skills). > Thus for example, followers of god X may only be able to sacrifice items > to get exp in a few skills, whiel a follower of god Y can get the exp in > other skills (I'd think that in all cases, you could always get the exp > in praying). This adds another dynamic to the gods. I'd agree for skills one can gain levels by fighting monsters, or not too difficulty. But, if sacrificing items were to give exp, i'd sure want to gain exp in inscription definitely, bargaining maybe, alchemy/bowyer/... probably, and so on. So i'd say: split combat skills (one/two handed weapons, magic, ...) between gods, but let'em all give exp in misc skills. Just my 2 cents of euro :) Nicolas _______________________________________________ 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 Jun 15 08:49:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_python_plugin_drop_patch?= Message-ID: I think the intended effect is to run the script twice - if an object is worn/applied it is run, if it is unworn/unapplied it is run - that was the current situation, the apply hook was called on apply and unapply. I am only addressing a loophole that when an applied object is dropped it does not call unapply. This brings the behaviour in line with existing behaviour. It should be noted in the plugin docs however that apply is also called on unapply. Now granted the hook may be in the wrong place - but IMHO the behaviour seems to be correct. Mark said: > One effect that I think will happen is that when a player manually unapplies > the object, the apply event script will be run twice - once from manual_apply, > and once from unapply_special. I'm not sure if this will have any bad effects, > but I could certainly see the possibility of that happening. > _______________________________________________ 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 Jun 16 01:28:29 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] python plugin drop patch In-Reply-To: References: Message-ID: <40CFE88D.6090401@sonic.net> Todd Mitchell wrote: > I think the intended effect is to run the script twice - if an object is > worn/applied it is run, if it is unworn/unapplied it is run - that was the > current situation, the apply hook was called on apply and unapply. I am > only addressing a loophole that when an applied object is dropped it does not > call unapply. This brings the behaviour in line with existing behaviour. It > should be noted in the plugin docs however that apply is also called on > unapply. Now granted the hook may be in the wrong place - but IMHO the > behaviour seems to be correct. Having the script called for the apply once and unapply once is fine. My point was that if a player unequips an item, with the code that you submitted, the script will be called _twice_ when a player unequips the item. I don't know if that will cause any problems, but is something that script writes may not expect. > > Mark said: > >> One effect that I think will happen is that when a player manually >> unapplies the object, the apply event script will be run twice - once from >> manual_apply, and once from unapply_special. I'm not sure if this will >> have any bad effects, but I could certainly see the possibility of that >> happening. >> _______________________________________________ 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 Jun 16 08:17:39 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_python_plugin_drop_patch?= Message-ID: > Having the script called for the apply once and unapply once is fine. > > My point was that if a player unequips an item, with the code that you > submitted, the script will be called _twice_ when a player unequips the item. > > I don't know if that will cause any problems, but is something that script > writes may not expect. > Ah, ok, I didn't understand. Yes now I notice it does call the script twice. It didn't have any impact on my script so I missed it before. You are correct that is sloppy so it should be fixed. _______________________________________________ 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 Fri Jun 18 01:51:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] Random things & bugs :) In-Reply-To: <40BF84D3.2050306@laposte.net> References: <40BF84D3.2050306@laposte.net> Message-ID: <40D290F2.5060904@sonic.net> Nicolas Weeger wrote: > Hello. > > First, a player reported (and i tested) a bug concerning writing > glyphes/runes/... > If you do 'invoke sigil cancellation', you get the message 'you can't > cast protection from cancellation with sigil!'. > The code gets the first matching spell, 'protection from cancellation', > instead of the best match 'cancellation'. I'll fix that up. > > On the message board, some players suggested reducing death penalty for > non combat skill (literacy, alchemy, inscription, jewelery, ...). > The main reason is that you need a *lot* of time to level in those > compared to combat skills like one handed weapons & such. > What do you think? I'd almost rather take the other approach, and just make it easier to go up in exp for those skills - increase the reward players get. Otherwise, the only way to balance this is for each skill to have something like a 'death loss percentage'. OTherwise, I'm sure it will eventually lead to something like 'literacy is harder than oratory, so you should lose less in literacy, etc'. OTOH, death should also be painful, despite what players may think :) Now a question of how hard/easy is a matter of opinion, and perhaps the current loss is too much. _______________________________________________ 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 Fri Jun 18 01:56:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] Post subject: Godly retribution kills... In-Reply-To: References: <200406021313.40254.eracclists@bellsouth.net> <40BEC951.5010201@sonic.net> Message-ID: <40D29201.308@sonic.net> Rick Tanner wrote: > Somebdy mentioned on IRC .. that spell failure effects (sh?)could check > and see if the square is damned, if it is then the godly retribution or > mana backlash stops. Perhaps, but there is no easy way to abstract. One could make it so that all spells behave that way, but that probably isn't desired. Since the retribution/mana backlash are just spells, there is no easy way to check them right now. I'm not sure if they have magic set or not. If they do, then this could get fixed to some extend by just putting a counterwall/counterspell type object on the space. In the longer term, the fix is to extend the no_pass attributes, and include blocking flags that would step spell effects. Then, the space could just be appropriately set. _______________________________________________ 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 Fri Jun 18 02:35:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] Random things & bugs :) In-Reply-To: <40D290F2.5060904@sonic.net> References: <40BF84D3.2050306@laposte.net> <40D290F2.5060904@sonic.net> Message-ID: <40D29B59.3000609@laposte.net> > I'd almost rather take the other approach, and just make it easier to > go up in exp for those skills - increase the reward players get. Yeah, i had suggested increasing xp for inscription, for instance - haven't actually tweaked that, as usual... > OTOH, death should also be painful, despite what players may think :) > Now a question of how hard/easy is a matter of opinion, and perhaps the > current loss is too much. Exactly the point, i think. Non combat skills, specially inscription/bowery/... are way too hard to level into. Nicolas _______________________________________________ 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 Fri Jun 18 08:41:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] Random things & bugs :) In-Reply-To: <40D290F2.5060904@sonic.net> References: <40BF84D3.2050306@laposte.net> <40D290F2.5060904@sonic.net> Message-ID: <1087566094.19088.0.camel@d5110227.lss.emc.com> On Fri, 2004-06-18 at 02:51, Mark Wedel wrote: > I'd almost rather take the other approach, and just make it easier to go up in > exp for those skills - increase the reward players get. Could lockpicking be rewarded based on the map difficulty? --PC _______________________________________________ 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 Fri Jun 18 10:59:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] Random things & bugs :) In-Reply-To: <40D290F2.5060904@sonic.net> Message-ID: > Nicolas Weeger wrote: > > Hello. > > > > First, a player reported (and i tested) a bug concerning writing > > glyphes/runes/... > > If you do 'invoke sigil cancellation', you get the message 'you can't > > cast protection from cancellation with sigil!'. > > The code gets the first matching spell, 'protection from cancellation', > > instead of the best match 'cancellation'. > > I'll fix that up. > > > > > On the message board, some players suggested reducing death penalty for > > non combat skill (literacy, alchemy, inscription, jewelery, ...). > > The main reason is that you need a *lot* of time to level in those > > compared to combat skills like one handed weapons & such. > > What do you think? Well, literacy is a tickler. As for me, I could get -*thinking* what was it, can't remember for sure, but let's say about- lvl 10-15 via reading almost ALL available spell books in ALL schools. You once have succeeded in learning a spell you won't be able to read that particular spellbook again (and get xp for it). Lvl 10-15, and I died once or maybe twice! Well, one could say "Maybe yore right, fella, but what's the deal, you know all spells, so what?" Yeah, sure there are skills that aren't necessery (or even good) to be high lvl at all. Literacy is good only for learning spell, almost. Well, first, it's good for reading other books as well, and that's not to be considered needless. (Recipes for example, or info books etc.) Second, there are peepo who die more frequently. The situation when somebody can't learn any more new (some powerful) spells for the fact that his literacy is _low_, (and can't train his literacy 'cause he already knows every lower-lvl spells) is not absolutely impossible. There's some problem with literacy, I think... Xp-source is limited. As for the other skills I dunno, fact, that killing monsta is still not that boring than training alchemy for example. The difference is not that big tho. The higher the skill, the more boring training it requires to get back. Maybe alchemy and co. is more time-consuming. Well, I always thought these skills to be unbelievably useless. (Face it, really powerfull items are unforgeable. Not to mention, the time you spend to train that nasty alchemy skill, you could get lotsa goodies via dungeoning. One meele skill and praying is all ya need, and some minor knowledge in the 4 wizard schools, for like Town Portal, Earth Wall 'n' stuff. Ah well, but this yet sounds like a little "strategy guide", so I stop here.) Bact to the topic, well some _do_ like these skills, and making them ( I mean the skills :-P ) harder to train back than meele and praying(?) would only lead to slicer-dicer sonsofbithes who know nothing else. (Like me :-) Hehh, even I hope we don't want _that_! > > I'd almost rather take the other approach, and just make it easier to go up in > exp for those skills - increase the reward players get. > > Otherwise, the only way to balance this is for each skill to have something > like a 'death loss percentage'. OTherwise, I'm sure it will eventually lead to > something like 'literacy is harder than oratory, so you should lose less in > literacy, etc'. > > OTOH, death should also be painful, despite what players may think :) Now a > question of how hard/easy is a matter of opinion, and perhaps the current loss > is too much. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ 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 Fri Jun 18 11:27:19 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] Random things & bugs :) In-Reply-To: <1087566094.19088.0.camel@d5110227.lss.emc.com> Message-ID: Ah, yes, lockpicking. Even worse than disarm trap. Those skills never were on the top of the list, but with this xp-system - they are just funny. (The only place I could _really_ use disarm trap for example was in a no-magic zone with a trap that deals 500 dam, but that time I had 40 disarm trap skill -via old system; what was it, mental, perhaps- and blew the trap 3 times on av. before I could disarm it. How on EARTH will someone have any near to lvl 40 in disarming trap with this new skill system?) Umm, just ask _any_ player (except someone, but I won't tell his name) if it's worth even to _think_ about bothering with lockpicking or disarm trap... (Just to think about it? C'mon I too did think about it... Yet again, it didn't worth it... :-P ) So I just wanted to say - you dev peepo are gonne be a _hard_ time if you are considering turning these skills from "inqualifyable" to just "entirely useless". (Ok, I too have used disarm trap on those more-than-20-traps treasure chests, but let's admit it, usually those chests turn up opened prematurely - by a fireball or somethin' like that. If I have cared about the items inside, I'd just have used the spell... But ok, I admit, disarm trap is even now as much as an "entirely uselss" skill. But lockpicking - no. Hell no. That's waaay below that...) And NO, making more deadly traps on doors and chests would NOT be the solution... > On Fri, 2004-06-18 at 02:51, Mark Wedel wrote: > > I'd almost rather take the other approach, and just make it easier to go up in > > exp for those skills - increase the reward players get. > > Could lockpicking be rewarded based on the map difficulty? > > --PC > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________________________ 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 Fri Jun 18 22:48:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:49 2005 Subject: [CF-Devel] Random things & bugs :) In-Reply-To: References: Message-ID: <40D3B7A1.6000607@sonic.net> Well, pick lock should give more exp - it seems that the attempt_pick_lock function does factor in the map difficulty in determining chances, but the exp reward does not The fact that literacy is limited in sources is a bit of a problem. I always thought it'd be nice to add in cursed spellbooks that could cause you to forget spells. Then you could re-learn them. Of course, you can use the literacy skill to identify all those spellbooks you find, to still give you some exp Perhaps the issue is really more fundamental - there are bunches of skills out there, without any clear requirement that the player be high level in the skill. And this of course means that there isn't any clear way to get high level in the skill. The simplest solution right now is to just bump up the exp reward for the skills. Perhaps one solution to this is random objects that give exp bonuses. Eg, a book that 'teaches' the player some skill, which effectively translates into exp for a particular skill. These should still be fairly rare, but these could actually be a somewhat coveted treasure I'd think. _______________________________________________ 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 Jun 19 05:38:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] does expmul work correctly with the 'skills command? Message-ID: <200406191138.41451.b.t.lally@warwick.ac.uk> hello all, Following on from the 'drop the death penalty' thread on the metalforge messageboard I started playing around with the expmul value in the archetypes for the lockpicking skill. Then I got pointed here. The aim is to make it give some modicum of xp without being the preferred way to level up a character. By changing exp to 100 and expmul to 0.1 I was able to make it so that lockpicking gives 200 xp per lock in lockpicking and 20 xp overall. However it appears that this breaks the level breaks or the skills command. Leveling up in lockpicking is made to occur at 200, 400, 800 xp instead of 2000, 4000 etc. The skills command displays the level breaks as normal meaning that the output can read things like: lockpicking.............................lvl: 3 (xp:400/8000) I found the definition of expmul in crossfire/doc/Developers/skills and it doesn't seem to suggest it should act this way, saying nothing about level breaks. However the comment for expmul in include/object.h says /* needed experience = (calc_exp*expmul) - means some */ /* races/classes can need less/more exp to gain levels */ So it looks like there are two conflicting definitions of this value, one altering rate at which xp goes to skill vs overall, and one where it determines the xp for level breaks. If both are correct behavior (as they are currently) then expmul is currently acting like expmul squared and the skills command is misbehaving. If it is incorrect behaviour then the rest of this post probably doesn't apply... From grepping the code it seems like level_exp returns expmul * the level break xp, which suggests it is probably the value passed to it that is odd. This is AFAICT level_exp(pl->level+1, pl->expmul) in server/c_misc.c to do the skills command and level_exp(tmp->level+1, op->expmul) in server/skill_util.c doing something else. There is also ADD_EXP(op->stats.exp, (float) exp_to_add * (skill_obj? skill_obj->expmul:1)) in common/living.c which /looks/ like it is the bit doing the experience adding, if so will mangling the other two lines to read level_exp(pl->level+1, pl->expmul*(skill_obj? skill_obj->expmul:1)) make it consistant? I have tried compiling a server with those changes and it complains about undeclared skill_obj. Unfortunately I can't find a .h file with any mentions of it to #include only a give_skill_by_name() in common/living.c and I don't know how to use this. I have tried following this through the source code further, but there is only so far I can get with grep and I don't really know how to use doxygen properly. _______________________________________________ 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 Jun 19 22:32:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] NEW Scorn Sale shop Message-ID: <200406192232.21908.eracclists@bellsouth.net> Hello all, This is sent to both the developer list and the maps list to get the broadest coverage. The Sale Shop has become a dumping ground for newbies entering Scorn from the TC to sell their junk. These items were ending up on the unique map squares and experienced players were complaining about it. This fixed map has a "two floor" shop to mitigate the problem. Please see the details here: http://makeashorterlink.com/?L32F21B98 If someone would be so kind as to check this into CVS I would be grateful. TIA Gene (poof|Galahad) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 22:26:43 up 112 days, 16:22, 14 users, load average: 0.00, 0.00, 0.03 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ 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 Sun Jun 20 20:10:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] Post subject: Godly retribution kills... In-Reply-To: <40D29201.308@sonic.net> References: <200406021313.40254.eracclists@bellsouth.net> <40BEC951.5010201@sonic.net> <40D29201.308@sonic.net> Message-ID: <200406202128812.SM01020@localhost> On Thu, 17 Jun 2004 23:56:01 -0700, Mark Wedel wrote: >Rick Tanner wrote: >> Somebdy mentioned on IRC .. that spell failure effects (sh?)could check >> and see if the square is damned, if it is then the godly retribution or >> mana backlash stops. > > Perhaps, but there is no easy way to abstract. One could make it so that all >spells behave that way, but that probably isn't desired. Since the >retribution/mana backlash are just spells, there is no easy way to check them >right now. > > I'm not sure if they have magic set or not. If they do, then this could get >fixed to some extend by just putting a counterwall/counterspell type object on >the space. > > In the longer term, the fix is to extend the no_pass attributes, and include >blocking flags that would step spell effects. Then, the space could just be >appropriately set. The problem lies in "cast daylight;fire;north" or somesuch. The spell daylight draws a large amount of grace, so it's possible to drain your grace to -500 rather quickly, or whatever your minimum happens to be. And then, Gaea would kill you rather quickly with godly retribution on whatever map you happened to be. The problem is that then the player may press north or whatever, restarting the fire command on cast daylight. This would cause the godly retribution to trigger again on your savebed map. And you would die many many many times. OTOH, perhaps a permanent counterwall where the savebed is wouldn't be a bad idea. Although it may get abused, ie. opening chests on a savebed, so that the spell effect won't reach the chest. -Philip _______________________________________________ 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 Jun 21 17:41:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] Poison cloud runes? Message-ID: <200406211741.34576.kbulgrien@worldnet.att.net> When a door is trapped with poison cloud, I did not see a poison cloud created when I triggered the rune instead of disarming it. I did not appear to take any damage either - though I did have some Gnarg stuff on so had a small poison resistance. Perhaps there is a bug? I'm running (almost current) CVS. _______________________________________________ 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 Jun 22 00:53:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] Poison cloud runes? In-Reply-To: <200406211741.34576.kbulgrien@worldnet.att.net> References: <200406211741.34576.kbulgrien@worldnet.att.net> Message-ID: <40D7C94C.4020309@sonic.net> Kevin R. Bulgrien wrote: > When a door is trapped with poison cloud, I did not > see a poison cloud created when I triggered the rune > instead of disarming it. I did not appear to take any > damage either - though I did have some Gnarg stuff > on so had a small poison resistance. > > Perhaps there is a bug? It sounds like a bug. Please open a bug on sourceforge. _______________________________________________ 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 Jun 22 01:02:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] Post subject: Godly retribution kills... In-Reply-To: <200406202128812.SM01020@localhost> References: <200406021313.40254.eracclists@bellsouth.net> <40BEC951.5010201@sonic.net> <40D29201.308@sonic.net> <200406202128812.SM01020@localhost> Message-ID: <40D7CB7B.10703@sonic.net> Somebody wrote: > > The problem lies in "cast daylight;fire;north" or somesuch. The spell > daylight draws a large amount of grace, so it's possible to drain your > grace to -500 rather quickly, or whatever your minimum happens to be. > And then, Gaea would kill you rather quickly with godly retribution on > whatever map you happened to be. The problem is that then the player > may press north or whatever, restarting the fire command on cast > daylight. This would cause the godly retribution to trigger again on > your savebed map. And you would die many many many times. That is certainly possible. but as said, there is no real way to prevent all these possible ways to die. the savebed spaces are already no magic, so the player would have to move off the space to cast the spell. > > OTOH, perhaps a permanent counterwall where the savebed is wouldn't be > a bad idea. Although it may get abused, ie. opening chests on a > savebed, so that the spell effect won't reach the chest. That's the basic problem - any method that comes up with to prevent accidental player death is likely open to some abuses also. But it seems a bit unlikely that people would bother to carry back chests. Plus, that still doesn't help out if the trap is something like a poison needle and not a spell. _______________________________________________ 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 Jun 22 02:04:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] does expmul work correctly with the 'skills command? In-Reply-To: <200406191138.41451.b.t.lally@warwick.ac.uk> References: <200406191138.41451.b.t.lally@warwick.ac.uk> Message-ID: <40D7D9FB.7040604@sonic.net> Bren wrote: > hello all, > > > I found the definition of expmul in crossfire/doc/Developers/skills and it > doesn't seem to suggest it should act this way, saying nothing about level > breaks. Correct. > > However the comment for expmul in include/object.h says > /* needed experience = (calc_exp*expmul) - means some */ > /* races/classes can need less/more exp to gain levels */ That is also correct. > > So it looks like there are two conflicting definitions of this value, one > altering rate at which xp goes to skill vs overall, and one where it > determines the xp for level breaks. > > If both are correct behavior (as they are currently) then expmul is currently > acting like expmul squared and the skills command is misbehaving. That is incorrect. I think the fix is this: Index: common/living.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/living.c,v retrieving revision 1.63 diff -c -w -r1.63 living.c *** common/living.c 10 Apr 2004 07:27:56 -0000 1.63 --- common/living.c 22 Jun 2004 06:51:11 -0000 *************** *** 1528,1534 **** if(!op) /* when rolling stats */ op = who; ! if(op->level < settings.max_level && op->stats.exp >= level_exp(op->level+1,op->expmul)) { op->level++; if (op != NULL && op == who && op->stats.exp > 1 && is_dragon_pl(who)) --- 1528,1534 ---- if(!op) /* when rolling stats */ op = who; ! if(op->level < settings.max_level && op->stats.exp >= level_exp(op->level+1,who->expmul)) { op->level++; if (op != NULL && op == who && op->stats.exp > 1 && is_dragon_pl(who)) *************** *** 1549,1555 **** if(who) (*draw_info_func)(NDI_UNIQUE|NDI_RED, 0, who,buf); } player_lvl_adj(who,op); /* To increase more levels */ ! } else if (op->level>1 && op->stats.explevel,op->expmul)) { op->level--; if(who) fix_player(who); if(op->type!=PLAYER) { --- 1549,1555 ---- if(who) (*draw_info_func)(NDI_UNIQUE|NDI_RED, 0, who,buf); } player_lvl_adj(who,op); /* To increase more levels */ ! } else if (op->level>1 && op->stats.explevel,who->expmul)) { op->level--; if(who) fix_player(who); if(op->type!=PLAYER) { Basically, always use the players expmul value for figuring this out - this is what the functions that show the level requirements do. This means for example that if a player has .50 as their expmul value, it means they gain levels in skills twice as fast also. I think this is the correct thing to do, but I haven't had a chance to properly test the above change. _______________________________________________ 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 Jun 22 21:15:00 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] Random things & bugs :) In-Reply-To: <40D290F2.5060904@sonic.net> References: <40BF84D3.2050306@laposte.net> <40D290F2.5060904@sonic.net> Message-ID: <20040623121500.24e3ecf7.won_fang@yahoo.com.au> Skipped content of type multipart/signed-------------- 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 Jun 22 23:46:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] bugs In-Reply-To: <1085498274.13959.5.camel@myth.crowcastle.com> References: <1085328158.24277.8.camel@myth.crowcastle.com> <40B2EB43.6080801@sonic.net> <1085498274.13959.5.camel@myth.crowcastle.com> Message-ID: <40D90B10.6060106@sonic.net> Preston Crow wrote: > On Tue, 2004-05-25 at 02:44, Mark Wedel wrote: > >>>When I use the "skills" command, for each skill it lists the current xp, >>>xp for the next level, and a percentage. The percentage is always 0%. >>>I thought it was supposed to be the percentage of the way through the >>>current level (e.g., at 1000xp, you are 50% of the way to 2nd level). >> >> I believe that percentage is what % of the exp is permantent exp. It may be >>that for simplicity, that is still displayed even on systems not using the >>permanent exp code. > > > If that's something that is turned off, should the display of the > percentage be turned off, too? Finally got a chance to look at this. The display code was broken - it was using the old value (last_heal) that used to be used to hold permanent exp. I've updated the code to use the proper values, so the percentages should no longer always be zero. But it is as I thought - this is the ratio that is your permanent exp. _______________________________________________ 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 Jun 22 23:58:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] throwing bombs... In-Reply-To: <20040523232522.186d2504.scachi@gmx.de> References: <20040523052213.0e5e99bd.kstenger@montevideo.com.uy> <20040523232522.186d2504.scachi@gmx.de> Message-ID: <40D90E0B.5070405@sonic.net> ScaChi wrote: > On Sun, 23 May 2004 05:22:13 -0300 > Karla Stenger wrote: > > >>hi all, >> som players just reported to me and showed me some bombs they had just thrown >>away right after casting them, the strange thing was they wouldnt blow up like >>they should. Examining them and comparing to a fresh newly casted bomb's dump i >>found out differences that appear to be added by the throwing items code. > > > I 've thrown some bombs too. > The bombs always exploded, but the bomb image remains where it exploded. > When the bomb is thrown at an enemy (only tested it with Goblins) > the enemy picks it up. It's funny. You see them pick it up, walk a bit and ... *kaboom. I'll fix this. This is a basic problem in the way the throw code works - when you throw something, another object is created with the same face/animation of the object you are throwing, and the actual object you are throwing is put inside this other object. This works pretty good, but the problem is that in this case, the bomb explodes, leaving the thrown_obj without inventory. And the code was such that in that case, it just did nothing, hence leaving a face on the map of the thrown object. _______________________________________________ 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 Jun 23 00:08:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] Firing spells from ranged weapons In-Reply-To: References: Message-ID: <40D91059.8040300@sonic.net> ToxicFrog wrote: > I've been wanting to make explosive arrows, but couldn't get them to > work. After mucking about in the code a bit, I found that it's because > only spell-bullets (102) get checked for detonation and suchlike, but if > you change the type 13 archs to 102, they aren't ammo any more and you > can't fire them in the first place. A looked at the submitted patch, and it looks pretty good. A few quick notes: I generally prefer context diffs to review patches - it makes it easier to just look at the patch without having to apply it and see differences. On the aarch - it's generally good practice to have the face match something in the animation. Perhaps not strictly required, but probably is safe practice. Given the code, I don't think there is in fact any need for the arch in question to have an animation of firebullet, since creating the new arch will set up the animation. Checking the return value of arch_to_object would be a good, but not actually sure if necessary - I think that other_arch is verified/set at load time - since it is a pointer to an archetype, I don't believe it can ever be non null and yet not point at something valid. In terms of firing other spells - instead of calling move_bullet(), you shoudl call move_spell_effect() - this covers all the spell effects that do move (bolts, cones, bullets, etc). So if you use that, you already have everything set up to firing any spell you want to. _______________________________________________ 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 Jun 23 22:00:37 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] crossfire -detach command-line option Message-ID: <200406232200.38208.kbulgrien@worldnet.att.net> I am having a very hard time getting the crossfire to run as a service with a non-permissioned user while using the -detach option. The server runs when I do this: # su -l games $ /home/games/crossfire -d -log /home/games/var/log/crossfire.log >>/home/games/var/log/crossfire 2>&1 This fails: # su -l games $ /home/games/crossfire -d -detach -log /home/games/var/log/crossfire.log >>/home/games/var/log/crossfire 2>&1 Has something changed? Does anyone else have trouble with this? The goal is to have an rc script start the server as as a daemon. Is there a prescribed method for doing so? I am certain that -detach used to work. _______________________________________________ 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 Jun 23 22:26:58 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] crossfire -detach command-line option In-Reply-To: <200406232200.38208.kbulgrien@worldnet.att.net> References: <200406232200.38208.kbulgrien@worldnet.att.net> Message-ID: <200406232226.58517.kbulgrien@worldnet.att.net> Well, ok, the redirects and -log are redundant, but make no difference... except that -log doesn't trap some python messages. On Wednesday 23 June 2004 22:00, Kevin R. Bulgrien wrote: > I am having a very hard time getting the crossfire to > run as a service with a non-permissioned user while > using the -detach option. > > The server runs when I do this: > > # su -l games > $ /home/games/crossfire -d -log /home/games/var/log/crossfire.log > > >>/home/games/var/log/crossfire 2>&1 > > This fails: > > # su -l games > $ /home/games/crossfire -d -detach -log /home/games/var/log/crossfire.log > > >>/home/games/var/log/crossfire 2>&1 > _______________________________________________ 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 Jun 23 23:19:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:50 2005 Subject: [CF-Devel] crossfire -detach command-line option In-Reply-To: <200406232200.38208.kbulgrien@worldnet.att.net> References: <200406232200.38208.kbulgrien@worldnet.att.net> Message-ID: <40DA5656.40809@sonic.net> Kevin R. Bulgrien wrote: > I am having a very hard time getting the crossfire to > run as a service with a non-permissioned user while > using the -detach option. > > The server runs when I do this: > > # su -l games > $ /home/games/crossfire -d -log /home/games/var/log/crossfire.log > >>>/home/games/var/log/crossfire 2>&1 > > > This fails: > > # su -l games > $ /home/games/crossfire -d -detach -log /home/games/var/log/crossfire.log > >>>/home/games/var/log/crossfire 2>&1 > > > Has something changed? Does anyone else have > trouble with this? > > The goal is to have an rc script start the server as as a > daemon. Is there a prescribed method for doing so? > I am certain that -detach used to work. > Any log messages containing output? Probably no one uses the -detach option. I think most servers (metalforge among them) use one of the crossloop scripts. These will restart the server if it goes down (crash, whatever). There does seem some bug in using it, but I have to say that it would be a very low priority bug (given easy workarounds), and the fix would probably be to remove the -detach and related code. _______________________________________________ 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 Jun 26 21:20:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] crossfire -detach command-line option In-Reply-To: <40DA5656.40809@sonic.net> References: <200406232200.38208.kbulgrien@worldnet.att.net> <40DA5656.40809@sonic.net> Message-ID: <200406262120.47638.kbulgrien@worldnet.att.net> On Wednesday 23 June 2004 23:19, Mark Wedel wrote: > Kevin R. Bulgrien wrote: > > I am having a very hard time getting the crossfire to > > run as a service with a non-permissioned user while > > using the -detach option. > > Any log messages containing output? No clues in the log at all. ======================== Begin New Server Session ======================== Reading bmaps from /home/games/share/crossfire/bmaps...done (got 4394/4395/4395) Reading faces from /home/games/share/crossfire/faces...done Reading smooth from /home/games/share/crossfire/smooth...done (got 77 smooth entries) Reading animations from /home/games/share/crossfire/animations...done. got (870) Reading archetypes from /home/games/share/crossfire/archetypes... arch-pass 1... Adding friendly object Evil Master, Bonehead. done Setting up archetable...done loading treasure... done arch-pass 2... done done Reading attack messages from /home/games/share/crossfire/attackmess...got 260 messages in 19 categories. Reading clockdata from /home/games/var/crossfire/clockdata...todtick=74294720 Emergency mappath reset to /world/world_105_115 (5, 37) Reading material type data from /home/games/share/crossfire/materials...Done. Welcome to CrossFire, v1.6.0 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. > Probably no one uses the -detach option. I think most servers > (metalforge among them) use one of the crossloop scripts. These will > restart the server if it goes down (crash, whatever). Ok. Did not even know about them. crossloop does not seem to handle stuff like "service crossloop stop". Is there any issue with a server going down too fast so that crossfire would not go down cleanly? Not having enough time to do it's save when it gets killed? > There does seem some bug in using it, but I have to say that it would be > a very low priority bug (given easy workarounds), and the fix would > probably be to remove the -detach and related code. (Shrug) Ok. -detach was nice because it was easy to plainly set up a script to do simple start/stop/status type stuff on a local homebrew server that isn't necessarily run 24/7. I used to do this with crossfire a year and a half or so ago. From what I can see, the crossloop scripts are pretty basic except that they do handle restarts/cores, nicely. Maybe I can work one of them over and get what I was looking for. _______________________________________________ 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 Sun Jun 27 15:07:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:51 2005 Subject: [CF-Devel] Post subject: Godly retribution kills... In-Reply-To: <40D7CB7B.10703@sonic.net> References: <200406021313.40254.eracclists@bellsouth.net> <40BEC951.5010201@sonic.net> <40D29201.308@sonic.net> <200406202128812.SM01020@localhost> <40D7CB7B.10703@sonic.net> Message-ID: <200406271624958.SM01020@mr-smith> On Mon, 21 Jun 2004 23:02:35 -0700, Mark Wedel wrote: >Somebody wrote: > >> >> The problem lies in "cast daylight;fire;north" or somesuch. The spell >> daylight draws a large amount of grace, so it's possible to drain your >> grace to -500 rather quickly, or whatever your minimum happens to be. >> And then, Gaea would kill you rather quickly with godly retribution on >> whatever map you happened to be. The problem is that then the player >> may press north or whatever, restarting the fire command on cast >> daylight. This would cause the godly retribution to trigger again on >> your savebed map. And you would die many many many times. > > That is certainly possible. but as said, there is no real way to prevent all >these possible ways to die. > > the savebed spaces are already no magic, so the player would have to move off >the space to cast the spell. That's just the thing. Godly retribution can be "cast", even when the space is no_magic/damned. Just had a player die a hundred times or so on metalforge due to the same thing. -Philip _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel