From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 17:53:20 2005 Subject: No subject Message-ID: > may have a disease. Modify infect_object() to not allow a creature to > have more than one instance of the same disease. Has any work been done on the fact that diseases can skip from inside a battleground to outside? Namely, if a player uses diseases in arena combat, then that player may catch the disease again after he dies in the duel, and die again for real. This was reported some time ago, but I'm not sure if anybody took note of it at the time. -Philip _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 17:53:44 2005 Subject: No subject Message-ID: > may have a disease. Modify infect_object() to not allow a creature to > have more than one instance of the same disease. Has any work been done on the fact that diseases can skip from inside a battleground to outside? Namely, if a player uses diseases in arena combat, then that player may catch the disease again after he dies in the duel, and die again for real. This was reported some time ago, but I'm not sure if anybody took note of it at the time. -Philip _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 17:54:33 2005 Subject: No subject Message-ID: for.. only the art needs to catch up now. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 17:54:42 2005 Subject: No subject Message-ID: ban_file called 'banish_file' (to avoid confusion), in var. The main reason for this is for respecting filesystem standards but it would also be useful in that the server admin can easily clean these entries up (with a cron script or whatever) or so that more functionality can be added (like DM's being able to lift the ban...). If the server admin reading the logs or whatever decides to set up more permenent IP bans they can use the ban_file in etc. _______________________________________________ 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 Jan 2 18:15:51 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] immunity force applied after death & godpower(?) In-Reply-To: References: Message-ID: <41D88EB7.9050807@sonic.net> Rick Tanner wrote: > The following change was made to the Crossfire server code: > > server/player.c: > Insert force into the player when they die making them immune to any > spells on the space they reappear on - this prevents multiple deaths if > there is large spell effect going on in the savebed location. Duration of > force should be long enough for most spells to run their course, but no so > long that the player can use it for much of an advantage (plus, killing > yourself to get such an advantage seems odd, and the force only makes the > player immune to the attacktypes currently on the space) > > Assuming this is in place on the crossfire.metalforge.net server, I saw > today a player die 3 times to godly retribution. > > They died the first time out in a dungeon, and then 2 more times while > back in their apartment and on their save bed. > > What attack type is godly retribution? Is it godpower? > > Is immunity to godpower granted by this force? > > Or is it another issue or problem that allowed this to happen? Various thoughts: If they died in the dungeon, and then died in the apartment, this suggest that they get 'retributed' while in the apartment. Probably because they were still casting the spell. Don't necessarily have a good solution - perhaps give the player max sp/grace after death also, to reduce that from happening (we give them full hp after all) Second, the immunity force inserted into the player only covers those spell effects that are active on the space the player is about to be re-inserted. Thus, if the player dies but his savebed location is 'safe', no force will be inserted, so that if they then cause something to blow up there, they will get damaged by that. So that could pretty easily explain the first death in their apartment. Third, the force only lasts a limited amount of time - it is possible the time I made it for is not long enough for retribution to die out (especially if the player causes it again). Now, the force can certainly be changed to make the player immune to everything for a longer time period - my main concern is that this could open up more abuses (eg, have town portal from big nasty monster to your savebed - if you do die, you know you have X time to get through that portal and beat on that monster, completely immune to any of its effects). The idea of only making the player immune to spells at the time was one way to reduce this abuse, as well as trying to make the time short enough that it would be difficult for the player to get much of an advantage) > _______________________________________________ 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 Jan 2 18:47:43 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] immunity force applied after death & godpower(?) In-Reply-To: <41D88EB7.9050807@sonic.net> References: <41D88EB7.9050807@sonic.net> Message-ID: <41D8962F.5070003@sonic.net> Just tried this out on my server. My notes from my previous message were correct: The code to protect you from damage of retribution does work. If you fail by a whole bunch, retribution can certainly last longer than the protection force. My fixes are as follows: Put a cap on how long retribution (which is also used for some other failures, like alchemy) can last - it won't last longer than the protection force that is inserted. Give player maxsp/grace (if better than their current total) on death. This should reduce the likelihood of causing retribution from buffered key strokes after you die. This is a bit of a boon, but probably not a great one. And this won't completely fix the problem - I believe there are cases where a spell costs so much grace that if a character doesn't have a lot of grace points (poor pow/wis) they could still fumble it even at full grace. And if you have 5 casts queued up, you can pretty quickly go through a lot of grace points also. But the hope is that this should reduce the problem a bit, without opening up any real abuses for the 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 Tue Jan 4 12:03:56 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20050104180356.GB13424@idefix2.dvlp.in-medias-res.com> > Index: crossfire/server/time.c [...] > + if (get_map_flags(m, &m, nx, ny, &nx, &ny) == P_OUT_OF_MAP) { This change does not look right to me. At least, it is inconsistent with other checks of the P_OUT_OF_MAP flag: all other checks are done like "if(get_map_flags() & P_OUT_OF_MAP)". (That is, treating P_OUT_OF_MAP as a bit in the result 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 Tue Jan 4 11:59:19 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20050104175919.GA13424@idefix2.dvlp.in-medias-res.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Index: crossfire/server/main.c [...] >! if (!(QUERY_FLAG(pl->ob,FLAG_WIZ) && pl->ob->contr->hidden) && >! (pl!=NULL && draw_exit)) new_draw_info(NDI_UNIQUE | NDI_ALL | NDI_DK_ORANGE, 5, NULL, buf); This code seems rather "wrong" to me: all statements within the function leave() (which is the enclosing function of this code fragment) check "pl != NULL" before accessing pl. Therefore this statement will crash if a NULL value would be passed. (On the other hand, I did not find any caller that could possibly pass such a NULL 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 Tue Jan 4 12:07:40 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20050104180740.GC13424@idefix2.dvlp.in-medias-res.com> > Index: crossfire/common/re-cmp.c [...] > + else if (str+1 != 0) > + return re_cmp(str+1, regexp); IMHO, this check can't be correct: str is a string (declared as "char *str"). Therefore "str+1 != 0" is always true. _______________________________________________ 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 Jan 4 13:07:08 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20050104175919.GA13424@idefix2.dvlp.in-medias-res.com> References: <20050104175919.GA13424@idefix2.dvlp.in-medias-res.com> Message-ID: <398dd1ee05010411074dd16499@mail.gmail.com> On Tue, 4 Jan 2005 18:59:19 +0100, Andreas Kirschbaum wrote: > > Index: crossfire/server/main.c > [...] > >! if (!(QUERY_FLAG(pl->ob,FLAG_WIZ) && pl->ob->contr->hidden) && > >! (pl!=NULL && draw_exit)) new_draw_info(NDI_UNIQUE | NDI_ALL | NDI_DK_ORANGE, 5, NULL, buf); > This code seems rather "wrong" to me: all statements within the function > leave() (which is the enclosing function of this code fragment) check > "pl != NULL" before accessing pl. Therefore this statement will crash if > a NULL value would be passed. (On the other hand, I did not find any > caller that could possibly pass such a NULL value...) There probably was or still is a reson for pl != NULL checks, maybe the code should be something like: if (pl!=NULL && draw_exit) { if !(QUERY_FLAG(pl->ob,FLAG_WIZ) && pl->ob->contr->hidden) new_draw_info(NDI_UNIQUE | NDI_ALL | NDI_DK_ORANGE, 5, NULL, buf); } -------------- next part -------------- A non-text attachment was scrubbed... Name: main.c.diff.gz Type: application/x-perl Size: 403 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050104/b4096fa0/main.c.diff.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 Tue Jan 4 14:57:19 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <398dd1ee05010411074dd16499@mail.gmail.com> References: <20050104175919.GA13424@idefix2.dvlp.in-medias-res.com> <398dd1ee05010411074dd16499@mail.gmail.com> Message-ID: <20050104205718.GA14079@idefix2.dvlp.in-medias-res.com> Salathar wrote: > There probably was or still is a reson for pl != NULL checks, maybe > the code should be something like: > > if (pl!=NULL && draw_exit) { > if !(QUERY_FLAG(pl->ob,FLAG_WIZ) && pl->ob->contr->hidden) > new_draw_info(NDI_UNIQUE | NDI_ALL | NDI_DK_ORANGE, 5, > NULL, buf); > } I'd rather merge this statement into the previous if(pl!=NULL) block: if (pl!=NULL) { [...] if (draw_exit) { if (!QUERY_FLAG(pl->ob, FLAG_WIZ) || !pl->ob->contr->hidden) { new_draw_info(NDI_UNIQUE|NDI_ALL|NDI_DK_ORANGE, 5, NULL, buf); } } } _______________________________________________ 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 Jan 5 01:59:26 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20050104180356.GB13424@idefix2.dvlp.in-medias-res.com> References: <20050104180356.GB13424@idefix2.dvlp.in-medias-res.com> Message-ID: <41DB9E5E.1050501@sonic.net> Andreas Kirschbaum wrote: >>Index: crossfire/server/time.c > > [...] > >>+ if (get_map_flags(m, &m, nx, ny, &nx, &ny) == P_OUT_OF_MAP) { > > > This change does not look right to me. At least, it is inconsistent with > other checks of the P_OUT_OF_MAP flag: all other checks are done like > "if(get_map_flags() & P_OUT_OF_MAP)". (That is, treating P_OUT_OF_MAP as > a bit in the result value.) I'll change it. fundamentally, it is correct - if the coordinate is out of the map, the function will return P_OUT_OF_MAP without it being bitmasked with any other values. other returns from get_map_flags() can be bitmasked (eg, P_BLOCKED | P_MAGIC or the like). But certainly good to be consistent. _______________________________________________ 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 Jan 5 01:57:02 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20050104205718.GA14079@idefix2.dvlp.in-medias-res.com> References: <20050104175919.GA13424@idefix2.dvlp.in-medias-res.com> <398dd1ee05010411074dd16499@mail.gmail.com> <20050104205718.GA14079@idefix2.dvlp.in-medias-res.com> Message-ID: <41DB9DCE.6020208@sonic.net> Andreas Kirschbaum wrote: > Salathar wrote: > >>There probably was or still is a reson for pl != NULL checks, maybe >>the code should be something like: >> >> if (pl!=NULL && draw_exit) { >> if !(QUERY_FLAG(pl->ob,FLAG_WIZ) && pl->ob->contr->hidden) >> new_draw_info(NDI_UNIQUE | NDI_ALL | NDI_DK_ORANGE, 5, >>NULL, buf); >> } > > > I'd rather merge this statement into the previous if(pl!=NULL) block: > > if (pl!=NULL) { > > [...] > > if (draw_exit) { > if (!QUERY_FLAG(pl->ob, FLAG_WIZ) || !pl->ob->contr->hidden) { > new_draw_info(NDI_UNIQUE|NDI_ALL|NDI_DK_ORANGE, 5, NULL, buf); > } > } > } Yes - that makes more sense. Whether to have two if statements is more an issue of styl - I don't see any reason that couldn't just be one if statement, since the code isn't doing anything else if draw_exit is 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 Wed Jan 5 02:02:50 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:20 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20050104180740.GC13424@idefix2.dvlp.in-medias-res.com> References: <20050104180740.GC13424@idefix2.dvlp.in-medias-res.com> Message-ID: <41DB9F2A.5080203@sonic.net> Andreas Kirschbaum wrote: >>Index: crossfire/common/re-cmp.c > > [...] > >>+ else if (str+1 != 0) >>+ return re_cmp(str+1, regexp); > > > IMHO, this check can't be correct: str is a string (declared as > "char *str"). Therefore "str+1 != 0" is always true. Correct - I'll fix that. I'll have to double check that all that match logic still does work expected, since I did test it before making the commit and that is where I found some of the errors. Can't see it making that much a difference, but never know. _______________________________________________ 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 Jan 6 17:20:44 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Uninitialized variable Message-ID: <41DDC7CC.6020006@laposte.net> Hello. In server/player.c around line 1385: for (attacknum=0; attacknum < NROFATTACKS; attacknum++, attacktype = 1<attacktype & attacktype) if (target->arch->clone.resist[attacknum] < 0) with 'attacktype' not initialized beforehand. Compiler reports use of attacktype without initialization, which is quite plausible as its value is set only after the first loop execution. Not sure what to put as initial value, though. 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 Jan 7 02:40:24 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Uninitialized variable In-Reply-To: <41DDC7CC.6020006@laposte.net> References: <41DDC7CC.6020006@laposte.net> Message-ID: <200501070940.24511.tchize@myrealbox.com> Looking at code part you gave, seems it checks all attacktype (0->NROFATTACKS) look if corresponding byte in arrow attacktype is activated and check if target has resit on it. so, logical behaviour of attacktype looks like 00000010 (equals 1 << (attacknum=1)) 00000100 (equals 1 << (attacknum=2)) 00001000 (equals 1 << (attacknum=3)) 00010000 (equals 1 << (attacknum=4)) 00100000 (equals 1 << (attacknum=5)) and so on I'll say initial value should be attacktype= 1; (equals 1<< (attacknum=0)) Le Vendredi 7 Janvier 2005 00:20, Nicolas Weeger a ?crit : > Hello. > > In server/player.c around line 1385: > > for (attacknum=0; attacknum < NROFATTACKS; > attacknum++, attacktype = 1< if (arrow->attacktype & attacktype) > if (target->arch->clone.resist[attacknum] < 0) > > with 'attacktype' not initialized beforehand. > Compiler reports use of attacktype without initialization, which is > quite plausible as its value is set only after the first loop execution. > > Not sure what to put as initial value, though. > > Nicolas > > _______________________________________________ > 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 Jan 7 15:12:24 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Mlab maps Message-ID: <41DEFB38.9080603@laposte.net> Hi. According to https://sourceforge.net/tracker/index.php?func=detail&aid=1065538&group_id=13833&atid=313833 we could now commit Mlab maps to CVS as they have subdirectories. Did anyone test the new version, with paths, to make sure everything works? 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 Jan 7 17:30:38 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Python questions Message-ID: <41DF1B9E.7000909@laposte.net> Hello. From plugin_python.c:6716: static PyObject* CFPayAmount(PyObject* self, PyObject* args) { long whoptr; uint64 to_pay; int val; CFParm* CFR; --> if (!PyArg_ParseTuple(args,"lL",&whoptr,&to_pay)) return NULL; I get an 'internal error' on that. Is my Python version too old (using 2.1) to handle the "lL" ? ----------------- Also, under Windows, there's a big issue, which was already raised some months ago, but is still there: the 'settings' variable is NOT available from the plugin module - it has default values, not the ones loaded from server itself. And i fear all other variables are in the same case... I guess the best fix would be to use callbacks for all those variables? 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 Jan 7 21:44:54 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Re: [CF-maps] Mlab maps In-Reply-To: <41DEFB38.9080603@laposte.net> References: <41DEFB38.9080603@laposte.net> Message-ID: <1105155894.4814.0.camel@lilwoo> Salathar did some testing on localhost as he indicated on tracker - I wont have time to look at them this weekend, but I can try to take a look Monday at some of them. On Fri, 2005-01-07 at 16:12, Nicolas Weeger wrote: > Hi. > > According to > https://sourceforge.net/tracker/index.php?func=detail&aid=1065538&group_id=13833&atid=313833 > we could now commit Mlab maps to CVS as they have subdirectories. > > Did anyone test the new version, with paths, to make sure everything > works? > > Nicolas "Ryo" > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Crossfire-maps mailing list > Crossfire-maps@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-maps _______________________________________________ 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 Jan 8 15:26:47 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Windows client release Message-ID: <41E05017.60506@laposte.net> Hello. Just released a Windows GTK client snapshot version. Fixes a few bugs here & there :) (server one coming soon) Enjoy. 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 Jan 9 06:03:38 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Python questions In-Reply-To: <41DF1B9E.7000909@laposte.net> References: <41DF1B9E.7000909@laposte.net> Message-ID: <20050109120338.GA25897@idefix2.dvlp.in-medias-res.com> Nicolas Weeger wrote: > --> if (!PyArg_ParseTuple(args,"lL",&whoptr,&to_pay)) > return NULL; > > I get an 'internal error' on that. Is my Python version too old (using > 2.1) to handle the "lL" ? Sorry, didn't think of older Python versions. The "L" format specifier seems to be available since Python 2.2 only. I need 64 bit variables to hold money and experience values. Therefore I can't see a sensible way to support Python versions before 2.2 any longer. I'll try to add a check to the configure script to reject unusable Python versions. _______________________________________________ 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 Jan 9 14:43:57 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Python questions In-Reply-To: <20050109120338.GA25897@idefix2.dvlp.in-medias-res.com> References: <41DF1B9E.7000909@laposte.net> <20050109120338.GA25897@idefix2.dvlp.in-medias-res.com> Message-ID: <1105303437.3593.10.camel@oberon.kameria> Well 2.1 was what I always am pushing because of Debian. If we stop supporting python 2.1 we stop python support in CF for woody - this impacts CF servers for the mainstream debian crowd. Although many folks use testing or unstable for desktop (including me), I think many folks might still use woody for public servers (including me). Sarge uses Python 2.3 however so hopefully one day soon this will be resolved. On Sun, 2005-09-01 at 13:03 +0100, Andreas Kirschbaum wrote: > Nicolas Weeger wrote: > > --> if (!PyArg_ParseTuple(args,"lL",&whoptr,&to_pay)) > > return NULL; > > > > I get an 'internal error' on that. Is my Python version too old (using > > 2.1) to handle the "lL" ? > > Sorry, didn't think of older Python versions. The "L" format specifier > seems to be available since Python 2.2 only. > > I need 64 bit variables to hold money and experience values. Therefore I > can't see a sensible way to support Python versions before 2.2 any > longer. I'll try to add a check to the configure script to reject > unusable Python versions. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- Todd Mitchell _______________________________________________ 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 Jan 9 16:12:27 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] CFJavaEditor add-on Message-ID: <200501092312.33895.tchize@myrealbox.com> 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 Sun Jan 9 16:44:17 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Python questions In-Reply-To: <1105303437.3593.10.camel@oberon.kameria> References: <41DF1B9E.7000909@laposte.net> <20050109120338.GA25897@idefix2.dvlp.in-medias-res.com> <1105303437.3593.10.camel@oberon.kameria> Message-ID: <41E1B3C1.3080808@sonic.net> Todd Mitchell wrote: > Well 2.1 was what I always am pushing because of Debian. If we stop > supporting python 2.1 we stop python support in CF for woody - this > impacts CF servers for the mainstream debian crowd. Although many folks > use testing or unstable for desktop (including me), I think many folks > might still use woody for public servers (including me). Sarge uses > Python 2.3 however so hopefully one day soon this will be resolved. Well, it seems there are really two choices: a) Support python 2.1, but then have things that need 64 bit values be broken (exp, money, etc). b) Support only version 2.2 and newer, which may lose support of older platforms for the python plugin (rest of crossfire would still work fine). I think 'b' is the way to go - no reason to try to support older technology software that may not work really well. Also, if it is important for those still using that older software, they could always install a newer version of python someplace else just for crossfire to use. The real problem, of course, is precompiled packages - either you do the precompiled package with python support, which may have issues with debian, or you don't, which means people running the latest version have issues (or you two distributions). But I don't even know if anyone is doing precompiled debian packages anyways, so may not be an issue. _______________________________________________ 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 Jan 9 22:33:36 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Uninitialized variable In-Reply-To: <200501070940.24511.tchize@myrealbox.com> References: <41DDC7CC.6020006@laposte.net> <200501070940.24511.tchize@myrealbox.com> Message-ID: <41E205A0.10108@sonic.net> tchize wrote: > Looking at code part you gave, seems it checks all attacktype (0->NROFATTACKS) > look if corresponding byte in arrow attacktype is activated and check if > target has resit on it. so, logical behaviour of attacktype looks like > > > 00000010 (equals 1 << (attacknum=1)) > 00000100 (equals 1 << (attacknum=2)) > 00001000 (equals 1 << (attacknum=3)) > 00010000 (equals 1 << (attacknum=4)) > 00100000 (equals 1 << (attacknum=5)) > and so on > > I'll say initial value should be > > attacktype= 1; (equals 1<< (attacknum=0)) Actually, the logic there is fine - it is just the presumption by the code author was that that the attacktype = 1< References: <41DF1B9E.7000909@laposte.net> <20050109120338.GA25897@idefix2.dvlp.in-medias-res.com> <1105303437.3593.10.camel@oberon.kameria> <41E1B3C1.3080808@sonic.net> Message-ID: <41E2A587.5000601@sympatico.ca> Mark Wedel wrote: > Todd Mitchell wrote: > >> Well 2.1 was what I always am pushing because of Debian. If we stop >> supporting python 2.1 we stop python support in CF for woody - this >> impacts CF servers for the mainstream debian crowd. Although many folks >> use testing or unstable for desktop (including me), I think many folks >> might still use woody for public servers (including me). Sarge uses >> Python 2.3 however so hopefully one day soon this will be resolved. > > > Well, it seems there are really two choices: > > a) Support python 2.1, but then have things that need 64 bit values be > broken (exp, money, etc). > > b) Support only version 2.2 and newer, which may lose support of older > platforms for the python plugin (rest of crossfire would still work > fine). > > I think 'b' is the way to go - no reason to try to support older > technology software that may not work really well. Also, if it is > important for those still using that older software, they could always > install a newer version of python someplace else just for crossfire to > use. > > The real problem, of course, is precompiled packages - either you do > the precompiled package with python support, which may have issues > with debian, or you don't, which means people running the latest > version have issues (or you two distributions). > > But I don't even know if anyone is doing precompiled debian packages > anyways, so may not be an issue. > I'd go along with this - the deb version of CF server in Woody is not even close to current. I just mentioned it as something to keep in mind - maybe some sort of howto or notification on how to build Crossfire with a alternate python path is in order. (I believe it is configure -- pythonsomething=). Also I would in this case suggest we jump over 2.2 and make 2.3 (or even 2.4?) the new 'test target' for crossfire python. This will give us a longer period of stability again and there are some nice things in there we can benefit from (like universal line ending and dictionary iteration in 2.3). Also I believe that real-time is moving from redhat to debian so this issue may be more salient as this goes on. _______________________________________________ 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 Jan 11 02:32:35 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Python questions In-Reply-To: <41E2A587.5000601@sympatico.ca> References: <41DF1B9E.7000909@laposte.net> <20050109120338.GA25897@idefix2.dvlp.in-medias-res.com> <1105303437.3593.10.camel@oberon.kameria> <41E1B3C1.3080808@sonic.net> <41E2A587.5000601@sympatico.ca> Message-ID: <41E38F23.7030004@sonic.net> Todd Mitchell wrote: > I'd go along with this - the deb version of CF server in Woody is not > even close to current. I just mentioned it as something to keep in mind > - maybe some sort of howto or notification on how to build Crossfire > with a alternate python path is in order. (I believe it is configure -- > pythonsomething=). Also I would in this case suggest we jump over > 2.2 and make 2.3 (or even 2.4?) the new 'test target' for crossfire > python. This will give us a longer period of stability again and there > are some nice things in there we can benefit from (like universal line > ending and dictionary iteration in 2.3). > Also I believe that real-time is moving from redhat to debian so this > issue may be more salient as this goes on. I'd be inclined not to make a specific version a requirement until features that require that version are put in place. It shouldn't be hard to just put in basic version checking - to some extent, the config program already does this just by searching for python. Perhaps life could be made easier by putting something like 'MIN_PYTHON_VERSION' as a define or the like to make it easier to update. The real problem of requiring later version when it isn't needed is that someone doesn't have that later version and figures out how to fool the config scripts or whatever to use the older version, and then poses the question 'why do you require version XYZ if you don't need it', of which there isn't a great answer. In terms of requiring 2.4, that seems quite bleeding edge - I have a feeling if that is required, 90% of the people would need to download it special (won't be included by default in what they are running). So there is a fine line between requiring what is needed matched against what people are actually using. > > > _______________________________________________ > 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 Jan 11 02:36:46 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:21 2005 Subject: [CF-Devel] Planned crossfire release, approx Jan 22-23 Message-ID: <41E3901E.8070608@sonic.net> As Ryo suggested, giving some people some advanced notice of when I plan to make a new release is probably a good idea, to commit those changes. My plan is to make a release sometime on the weekend of the 22-23rd. I propose the following schedule: This week: Commit any minor changes, bug fixes, or other modest changes (IMO, it is a bit later for 'major changes' at this time). Next week (17-22) - only commit critical bug fixes. The real idea is so that I can update metalforge around the 17-18th and give it several days of run time with what will really ship as the official release. _______________________________________________ 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 Jan 11 06:31:34 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Planned crossfire release, approx Jan 22-23 In-Reply-To: <41E3901E.8070608@sonic.net> References: <41E3901E.8070608@sonic.net> Message-ID: <200501111331.34959.tchize@myrealbox.com> Agree. Any list if TODO's for those 2 deadlines? If think it could be a good idea to schedule some discussion about the major changes crossfire need after the release. Le Mardi 11 Janvier 2005 09:36, Mark Wedel a ?crit : > As Ryo suggested, giving some people some advanced notice of when I plan > to make a new release is probably a good idea, to commit those changes. > > My plan is to make a release sometime on the weekend of the 22-23rd. > > I propose the following schedule: > > This week: > Commit any minor changes, bug fixes, or other modest changes (IMO, it is a > bit later for 'major changes' at this time). > Next week (17-22) - only commit critical bug fixes. > > The real idea is so that I can update metalforge around the 17-18th and > give it several days of run time with what will really ship as the official > release. > > > > _______________________________________________ > 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 Jan 11 07:07:18 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Planned crossfire release, approx Jan 22-23 In-Reply-To: <200501111331.34959.tchize@myrealbox.com> References: <41E3901E.8070608@sonic.net> <200501111331.34959.tchize@myrealbox.com> Message-ID: <41E3CF86.8090208@laposte.net> tchize a ?crit : > Agree. Any list if TODO's for those 2 deadlines? > > If think it could be a good idea to schedule some discussion about the major > changes crossfire need after the release. In the same topic, i was thinking of having a short list of: * corrected bugs / known issues * major changes between releases The full changelog sure helps, but is maybe too detailed for a rough change file :) Something like: * fix: bug #aze where yielding a sword would crash * new: literacy skill * known bug: if your char name starts with 'r' the game will crash 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 Jan 11 09:30:53 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Post-release development Message-ID: <1105457453.16732.15.camel@d5110227.lss.emc.com> Unless I missed it, we still don't have a bitmap for floors indicating what can pass over them. Something like: bit feature 1 allow walk 2 allow jump 3 allow dimension door 4 allow levitate 5 allow missiles (including magic projectiles) 6 allow spell area effects (turn off for counterwall effect) 7 allow view One example use would be an arrow slit. Set only bits 5 and 7, and put a director on the same square, with some dark elves behind it. Another example is avoiding anti-magic zones when all you need is to block dimension door. If someone creates real transportation, such as boats, that would be another bit. --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 Tue Jan 11 16:19:24 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Python questions In-Reply-To: <41E38F23.7030004@sonic.net> References: <41DF1B9E.7000909@laposte.net> <20050109120338.GA25897@idefix2.dvlp.in-medias-res.com> <1105303437.3593.10.camel@oberon.kameria> <41E1B3C1.3080808@sonic.net> <41E2A587.5000601@sympatico.ca> <41E38F23.7030004@sonic.net> Message-ID: <41E450EC.9050609@sympatico.ca> Well by 'test target' I just meant the generally agreed on version that python scripts should be tested out on for inclusion to CVS, not a required version of Python for the server. Local and in-house scripts naturally don't need to worry about this and should be able to use whatever version of python they want/require. However I think it's a good idea for the 'official' scripts to be tested against an agreed on version. As an example I currently test against 2.1 for crossfire and can't say that the player log or slotmachines would work in 2.0 or 1.5 or whatever but they will very likely work with 2.2 or 2.3, however when python scripts submitted for Guild system were tested on 2.3 there were cases of them not working on metalforge. Basically I was just looking for an agreement something like the 'rules' we use for maps. This will make it easier when people have problems as well - you have a version number to give them. I would rather test scripts against 2.3 than 2.2 as it is more current (so longer shelf-life) has some big improvements and I think more likely to be installed on someone's system than 2.2. I also didn't mean to imply that a check needs to be done on the server for a specific python version requirement, I just meant putting a nice notice in the INSTALL doc on how to use the configure script to build against a specific installation of python if your default system python does not work or if you want to keep it seperate. Mark Wedel wrote: > I'd be inclined not to make a specific version a requirement until > features that require that version are put in place. > > It shouldn't be hard to just put in basic version checking - to some > extent, the config program already does this just by searching for > python. Perhaps life could be made easier by putting something like > 'MIN_PYTHON_VERSION' as a define or the like to make it easier to update. > > The real problem of requiring later version when it isn't needed is > that someone doesn't have that later version and figures out how to > fool the config scripts or whatever to use the older version, and then > poses the question 'why do you require version XYZ if you don't need > it', of which there isn't a great answer. > > In terms of requiring 2.4, that seems quite bleeding edge - I have a > feeling if that is required, 90% of the people would need to download > it special (won't be included by default in what they are running). > So there is a fine line between requiring what is needed matched > against what people are actually using. > _______________________________________________ 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 Jan 11 19:23:18 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Post-release development In-Reply-To: <1105457453.16732.15.camel@d5110227.lss.emc.com> References: <1105457453.16732.15.camel@d5110227.lss.emc.com> Message-ID: <1105492998.6215.10.camel@oberon.kameria> This is still a long standing wish of mine to see this. There is I think, a lot of discussion in the dev archives about it. I still thing it would be not too diffucult to do (I playing with it a while ago - making some a changes in arch_blocked() and get_map_flag() but I ran out of brains) but maybe more difficult than I think. The portion you didn't mention is that blocking bitmasks have to be matched up the object movement type flags and there needs to be some overlap (flying/swimming). It is in the order of a rather big change in the game however unless new arches were made and the old arches phased out since it would break a lot of maps. It would also really impact gameplay. It would make a lot more neat fun things possible however :) On Tue, 2005-11-01 at 10:30 -0500, Preston Crow wrote: > Unless I missed it, we still don't have a bitmap for floors indicating > what can pass over them. Something like: > bit feature > 1 allow walk > 2 allow jump > 3 allow dimension door > 4 allow levitate > 5 allow missiles (including magic projectiles) > 6 allow spell area effects (turn off for counterwall effect) > 7 allow view > > One example use would be an arrow slit. Set only bits 5 and 7, and put > a director on the same square, with some dark elves behind it. > > Another example is avoiding anti-magic zones when all you need is to > block dimension door. > > If someone creates real transportation, such as boats, that would be > another bit. > > --PC > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- Todd Mitchell _______________________________________________ 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 Jan 12 01:45:42 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Post-release development In-Reply-To: <1105492998.6215.10.camel@oberon.kameria> References: <1105457453.16732.15.camel@d5110227.lss.emc.com> <1105492998.6215.10.camel@oberon.kameria> Message-ID: <41E4D5A6.7000907@sonic.net> Todd Mitchell wrote: > This is still a long standing wish of mine to see this. There is I > think, a lot of discussion in the dev archives about it. I still thing > it would be not too diffucult to do (I playing with it a while ago - > making some a changes in arch_blocked() and get_map_flag() but I ran out > of brains) but maybe more difficult than I think. The portion you > didn't mention is that blocking bitmasks have to be matched up the > object movement type flags and there needs to be some overlap > (flying/swimming). It is in the order of a rather big change in the > game however unless new arches were made and the old arches phased out > since it would break a lot of maps. It would also really impact > gameplay. It would make a lot more neat fun things possible however :) Right - you really don't want to hardcode values in that are explicity checked in the code (I think this is a spell, so see if spells are allowed). By allowing the bitmasks to be matched up with movement types in objects, this makes the system much more extensible - want to add a new movement type, it just means updating some archs. From the list below, I do think it perhaps need to be generalized some. For example, jump should either be considered walking or flying (probably the later) - it probably doesn't need to be its own movement type. The real problemw ith this is that this is reverse logic from what we have right now - right now, by default, all movement is allowed unless otherwise specified - reversing to the 'nothing allowed unless specified' means pretty radical changes to most any archs (or having implicit defaults, which usually causes problems later on). Scripts could certainly be be written to update all the archs. And I don't really like the idea of negative values (no_fly, no_magic, etc). The problem with negative values like that also mean that adding new movement types isn't as easy, as in a sense, by default all objects don't need that specialized new movement. so probably the easiest thing is to make the default that everything be allowed (0xffffffff), with certain historic keywords negating it (no magic clears flags, no_pass sets that to zero, etc). The other complication is for the objects that move - presumably there move type, for lack of better term, represents all the movements that they are capable of, not all they are actually using (eg, a dragon for example might have fly|walk, representing it can fly or walk, not that it needs to do both). I'm just trying to think if there are any cases where these values would in fact have to be ANDed together (eg, the object question needs to be able to do both type X and Y on a space). I'd also, through some method, also like to incorporte the slow_move stuff into such a bitmask, but that is probably a seperate bitmask (move_modifier or something), which can then get matched up against items/skills that help negate the penalty. > > On Tue, 2005-11-01 at 10:30 -0500, Preston Crow wrote: > >>Unless I missed it, we still don't have a bitmap for floors indicating >>what can pass over them. Something like: >> bit feature >> 1 allow walk >> 2 allow jump >> 3 allow dimension door >> 4 allow levitate >> 5 allow missiles (including magic projectiles) >> 6 allow spell area effects (turn off for counterwall effect) >> 7 allow view >> >>One example use would be an arrow slit. Set only bits 5 and 7, and put >>a director on the same square, with some dark elves behind it. >> >>Another example is avoiding anti-magic zones when all you need is to >>block dimension door. >> >>If someone creates real transportation, such as boats, that would be >>another bit. >> >>--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 Wed Jan 12 01:53:17 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Python questions In-Reply-To: <41E450EC.9050609@sympatico.ca> References: <41DF1B9E.7000909@laposte.net> <20050109120338.GA25897@idefix2.dvlp.in-medias-res.com> <1105303437.3593.10.camel@oberon.kameria> <41E1B3C1.3080808@sonic.net> <41E2A587.5000601@sympatico.ca> <41E38F23.7030004@sonic.net> <41E450EC.9050609@sympatico.ca> Message-ID: <41E4D76D.3060102@sonic.net> Todd Mitchell wrote: > Well by 'test target' I just meant the generally agreed on version that > python scripts should be tested out on for inclusion to CVS, not a > required version of Python for the server. Local and in-house scripts > naturally don't need to worry about this and should be able to use > whatever version of python they want/require. However I think it's a > good idea for the 'official' scripts to be tested against an agreed on > version. As an example I currently test against 2.1 for crossfire and > can't say that the player log or slotmachines would work in 2.0 or 1.5 > or whatever but they will very likely work with 2.2 or 2.3, however when > python scripts submitted for Guild system were tested on 2.3 there were > cases of them not working on metalforge. Basically I was just looking > for an agreement something like the 'rules' we use for maps. This will > make it easier when people have problems as well - you have a version > number to give them. I would rather test scripts against 2.3 than 2.2 > as it is more current (so longer shelf-life) has some big improvements > and I think more likely to be installed on someone's system than 2.2. > I also didn't mean to imply that a check needs to be done on the server > for a specific python version requirement, I just meant putting a nice > notice in the INSTALL doc on how to use the configure script to build > against a specific installation of python if your default system python > does not work or if you want to keep it seperate. Ah ok. That makes more sense. For testers of scripts, it probably really comes down to 'don't use a version later than x.y'. If everyone tests against 2.3 or earlier, it makes it fairly safe to say that if you have pythong 2.3 or later, you should be good (I'm presuming python is not going to make incompatible changes). However, if we put in such a testing scheme, which IMO we should, it should also be clearly spelled out in the docs. Eg, something like 'The python plugin scripts have been tested against version 2.3 or python. If you plan to use the python plugin scripts, we recommend you have at least this version. Using older version may work, but is not supported'. _______________________________________________ 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 Jan 12 01:49:17 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] Planned crossfire release, approx Jan 22-23 In-Reply-To: <41E3CF86.8090208@laposte.net> References: <41E3901E.8070608@sonic.net> <200501111331.34959.tchize@myrealbox.com> <41E3CF86.8090208@laposte.net> Message-ID: <41E4D67D.9010603@sonic.net> Nicolas Weeger wrote: > tchize a ?crit : > >> Agree. Any list if TODO's for those 2 deadlines? I'd personally think looking at the bugs and patches at http://sourceforge.net/projects/crossfire/ - for patches, see if any are really ready for integration. For bugs, see if there are any easy to fix or present significant issues (I think the answers to both of those is sort or no, but not 100% sure). >> >> If think it could be a good idea to schedule some discussion about the >> major changes crossfire need after the release. Certainly - a discussion of needed new features or desired changes is always welcome. > > > In the same topic, i was thinking of having a short list of: > * corrected bugs / known issues > * major changes between releases > > The full changelog sure helps, but is maybe too detailed for a rough > change file :) At least the changelog can be reviewed and the more relevant stuff pulled out. It's been a lot longer between releases than the ideal case. _______________________________________________ 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 Jan 12 15:31:03 2005 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:57:22 2005 Subject: [CF-Devel] CFJavaEditor: memory fix Message-ID: <200501122231.08120.tchize@myrealbox.com> 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 bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 17:59:22 2005 Subject: No subject Message-ID: Well, if a skull near you cast, he produce this as spell sounds. But instead of sound numbers, he triggers also some effect sounds when he cast, so its a ugly noisy sound he produce. SOUND: Playing sound 7 (type 1), offset 2, -3 SOUND: Playing sound 55 (type 1), offset 2, -3 SOUND: Playing sound 4 (type 1), offset 2, -3 SOUND: Playing sound 4 (type 1), offset 2, -3 SOUND: Playing sound 66 (type 1), offset 2, -3 SOUND: Playing sound 55 (type 1), offset 2, -3 SOUND: Playing sound 20 (type 1), offset 2, -3 SOUND: Playing sound 64 (type 1), offset 2, -3 SOUND: Playing sound 55 (type 1), offset 2, -3 SOUND: Playing sound 66 (type 1), offset 2, -3 SOUND: Playing sound 7 (type 1), offset 2, -3 SOUND: Playing sound 0 (type 1), offset 2, -3 SOUND: Playing sound 55 (type 1), offset 2, -3 SOUND: Playing sound 20 (type 1), offset 2, -3 SOUND: Playing sound 4 (type 1), offset 2, -3 SOUND: Playing sound 0 (type 1), offset 2, -3 SOUND: Playing sound 20 (type 1), offset 1, -2 SOUND: Playing sound 4 (type 1), offset 2, -3 SOUND: Playing sound 55 (type 1), offset 2, -3 SOUND: Playing sound 55 (type 1), offset 2, -3 SOUND: Playing sound 7 (type 1), offset 2, -3 Most times, he cast speedball, lighting, slow, bullet, etc. We need some work here. What about this: a signed short16 as sound ID. If it >=0, its a effect like hit, dead, etc. If it <0, its a sound spell. MichToen From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 17:59:48 2005 Subject: No subject Message-ID: Price \Price\ (?), n. [OE. pris, OF. pris, F. prix, L. pretium; cf. Gr. &?; I sell &?; to buy, Skr. pa&?; to buy, OI. renim I sell. Cf. Appreciate, Depreciate, Interpret, Praise, n. & v., Precious, Prize.] ... 3. Reward; recompense; as, the price of industry. 'T is the price of toil, The knave deserves it when he tills the soil. --Pope. -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 17:59:54 2005 Subject: No subject Message-ID: are favored in the artifact selection over items at the bottom. Is this true? Or is the observation just a result of chance? Regards, PeterM From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:00:11 2005 Subject: No subject Message-ID: From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:00:19 2005 Subject: No subject Message-ID: and not worry about wandering through the doorway into the monsters. While in brace mode, experience gained for kills is reduced. > No help availble on 'disarm' If the skill system is used (which is probably on on all servers), this basically just uses the remove trap skill. If the skill system is not used, this is the only way to disarm traps without a spell. > No help availble on 'dm' Lets the player become the game wizard. The player needs to know the dm password. Note that the game wizard in crossfire has many more powers the wizards in most MUDS, and is not something typically given out to players. > No help availble on 'drop' drops an object. If a name is given, it will find its best match for that name and drop that object. > No help availble on 'dropall' drops all objects. Locked items, money, food, gems, keys, and containers are not dropped. dropall will take the optional parameter 'weapons', 'armor', or 'misc'. armor drops armor, shields, and helmets, but not gloves, gauntlets, or cloaks. misc drops other items - rings, scrolls, scrolls, etc. From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:00:31 2005 Subject: No subject Message-ID: to memory corruption. PeterM > Now, the easiest fix would be to change "llevError" to "llevDebug" > for the "Internal error in update_button (...)."-message. > But that is somehow a dirty fix. Maybe someone can track the bug > to it's roots? From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:00:39 2005 Subject: No subject Message-ID: Instead, it's a diabolical plot on the part of the pupland creators to kill players sometimes. Yes, that's right, sometimes. Sometimes the bombs get teleported, sometimes it's YOU. PeterM > Just the facts...:) > > Since then he's replicated it a third time. It's nice to have players > willing to suicide.:) > > > In nurnberg. In /Dick/bomb1 (I think that's how it's listed, it's the > "hard house") there is a spot to drop bombs on a teleporter and a lever > to teleport the bombs through into a room. > > I dropped bombs onto the teleporter, took a step away, pulled the lever, > took another step AWAY from the teleporter, and was instantly put into > the room full of nasties. They of course killed me instantly. I was > also immediately booted off the server rather than respawning like I > should have. > > I tried to recreate, but the second time it worked fine. Just like it > was supposed to. I proceeded to the next "stop" where a similar > mechanism is in place. A similar thing happened, but I'm much less sure > what happened this time because I was more relaxed and not paying as > much attention as I had been before. Again, though, it appears as if I > was teleported for no reason. > > Another payer witnessed the first incident and saw the spontaneous > teleport, the second time - I was alone. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:00:41 2005 Subject: No subject Message-ID: I expect they've already been seen and corrected in CVS, but just in case: 1)The change in animation code means switches and doors under player don't update in the floor display. Presumably seen weeks ago. 2)Entering maps and being blocked from entrance by monsters (because they're standing where you're supposed to enter): One case in navar where the little houses are all one map, so vikings had already moved (and killed my low level character, I hadn't expected them), this would be a map issue; BUT OTHER CASE, AFAIK, was a random map! Either way, I hadn't been on that map before, and found myself surrounded by creatures, incl. an ogre standing on the exit. That is surely a big foobar. In long term, it would be nice if you could set "no monster" flags on exits to stop this (actually, checkinv can just about do this right now). 3)Strange button setting: One of my maps has the spike+boulder machinery, but with *two* buttons under some of the spikes, to take boulders along a line. When put a character in the map, it messed up. When I reloaded it in crossedit, it had set many buttons to be pushed already. Looking at the map source, none of them were so (it is decided by "value", isn't it?). I figure both the server and crossedit are using the same methods to calculate this. Mucking about with weight value of *some* of the buttons sorted it, I suppose it was assuming *all* things with weight value applied that weight to buttons below. Fairly sure this wasn't a problem in the older crossedit (from 0.95). 4)Strange button/pedestal updating: map mentioned in 3 mainly works now, but there seems to be a problem with getting a button/pedestal/ gate combo to recognise when the gate has pushed an object off: The gate is up and the object gone, but the button is still pushed (having the effect here of locking player in, which is very wrong). I'll try to tidy up my mapset tomorrow afternoon and upload it to the ftp site. It's at the point that there's almost stuff worth going there for, and it'll help illustrate points 3 and 4. Tomble (Tom Barnes-LawrencE) _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:01:04 2005 Subject: No subject Message-ID: are detailed in the file, which is common to both the client and server. The flags of relevance to this command are the CS_QUERY flags. are sent in plaintext form. The client is free to ignore the flags. However, if the server just wants a single character as a reply, that is all it uses, even if the client sends a long string (Server will use the first character.) [text] is the question/prompt that should be printed. Right now, it is typically just a ':'. Client should display it no matter what is is, however. Text is an optional field. Note - as of 0.94.2, text may be multi line, delimited by newlines. Client should handle this appropriately. So yes, the query can include extra text (ie, the question to ask). The reason it doesn't always is more based in history. The first client was basically the X11 (not gtk) client, which only had the one draw info window with no popups. And for that, it worked fine. Note the gtk client actually will present popups, a feature I find really annoying. But I did add and option to the gtk client which does not use popups. Note that text by itself is not perfect. The gtk client, for example, tries to do some extra work to present a nicer form when swapping stats (buttons to press). IT basically does this by examining the set of text (or last set of drawinfos). Right now, there are not actually a lot of places in the server that take input. And realistically, not all the queries have been updated on the server side to include a text message. There could certainly be further enhacnements done. Let the client deal with this more - for example, we know for a fact that when you connect to a new server, at minimum a name and password is needed. Client could take care of both of those and send it to the server as something like LOGIN . Likewise, for stat swapping, the client could send the two swapped values in one response, and not one at a time. This actually simplifies server code, and should make the interface better on the client (the reason the client would even ened to send the swapped stats at all and not just a final result is so the player can see what raising is str does to damage for example). I would file this under one of the improvements for client/server communication. There was a lot of stuff done in the original server/client implementation that as we look back it is, isn't the optimum solution. It worked for the given client (x11), but doesn't do a very good job now. From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:01:32 2005 Subject: No subject Message-ID: ---------------------------------- oad_original_map: /peterm/FireTemple/ThirdFloor (0) Warning: Tried to insert object wrong part of multipart object. Warning: Tried to insert object wrong part of multipart object. Warning: Tried to insert object wrong part of multipart object. Warning: Tried to insert object wrong part of multipart object. Warning: Tried to insert object wrong part of multipart object. Warning: Tried to insert object wrong part of multipart object. Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/peterm/FireTemple/FourthFloor . load_original_map: /peterm/FireTemple/FourthFloor (0) Saving map /world/world_b4 Saving map /world/world_c4 Trying to load map /home/unitel/cf/crossfire/share/crossfire/maps/eeur/tower1.3. load_original_map: /eeur/tower1.3 (0) Saving map /peterm/FireTemple/Entrance Saving map /peterm/FireTemple/LavaChamber remove_ob: GET_MAP_OB does not return object to be removed even though it appears to be on the bottom? arch pentagram_111 name pentagram face pentagram.111 hp 12 sp 17 x 9 y 26 type 41 path_attuned 14 connected 14 no_pick 1 end arch imp name imp race demon face imp.171 animation imp Str 24 Con 1 Wis 3 Pow 1 hp 5 maxhp 5 sp 5 maxsp 5 exp 150 dam 2 wc 4 ac 4 x 9 y 26 speed 0.250000 speed_left 0.150000 attack_movement 5 level 1 direction 2 attacktype 5 resist_physical 20 resist_magic 30 resist_fire 100 weight 200000 randomitems imp run_away 15 alive 1 no_pick 1 is_animated 1 flying 1 monster 1 see_invisible 1 can_cast_spell 1 can_see_in_dark 1 end free_all_objects: Link error, bailing out. remove_ob: GET_MAP_OB does not return object to be removed even though it appears to be on the bottom? arch imp name imp race demon face imp.131 animation imp Str 24 Con 1 Wis 3 Pow 1 hp 5 maxhp 5 sp 5 maxsp 5 exp 150 dam 2 wc 4 ac 4 x 7 y 3 speed 0.250000 speed_left 0.150000 attack_movement 5 level 1 direction 8 attacktype 5 resist_physical 20 resist_magic 30 resist_fire 100 weight 200000 randomitems imp run_away 15 alive 1 no_pick 1 is_animated 1 flying 1 monster 1 see_invisible 1 can_cast_spell 1 can_see_in_dark 1 end arch pentagram_111 face pentagram.111 hp 12 sp 17 x 9 y 26 type 41 path_attuned 14 no_pick 1 end free_all_objects: Link error, bailing out. remove_ob: GET_MAP_OB does not return object to be removed even though it appears to be on the bottom? arch pentagram_111 name pentagram face pentagram.111 hp 23 sp 17 x 25 y 25 type 41 path_attuned 10 connected 10 no_pick 1 end arch imp name imp race demon face imp.171 animation imp Str 24 Con 1 Wis 3 Pow 1 hp 5 maxhp 5 sp 5 maxsp 5 exp 150 dam 2 wc 4 ac 4 x 25 y 25 speed 0.250000 speed_left 0.150000 attack_movement 5 level 1 direction 2 attacktype 5 resist_physical 20 resist_magic 30 resist_fire 100 weight 200000 randomitems imp run_away 15 alive 1 no_pick 1 is_animated 1 flying 1 monster 1 see_invisible 1 can_cast_spell 1 can_see_in_dark 1 end free_all_objects: Link error, bailing out. remove_ob: GET_MAP_OB does not return object to be removed even though it appears to be on the bottom? arch pentagram_111 name pentagram face pentagram.111 hp 16 sp 3 x 26 y 1 type 41 path_attuned 12 connected 12 no_pick 1 end [NULL pointer] Trying to remove removed object. arch pentagram_111 face pentagram.111 hp 16 sp 3 x 26 y 1 type 41 path_attuned 12 no_pick 1 end From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:01:38 2005 Subject: No subject Message-ID: htm "no_pass 1": If set, only players meeting the match criteria can pass through that space. If "no_pass 0": (default), then the inv. checker acts like a trigger/button. What it does: You can't pass through a check inv with "no_pass 1" wether you have the item or not. The problem is the logic in common/map.c blocked_two(). A patch is append, cu Maurice --==_Exmh_21058014690 Content-Type: text/plain ; name="map.c.diff"; charset=us-ascii Content-Description: map.c.diff Content-Disposition: attachment; filename="map.c.diff" --- map.c-orig Mon Sep 17 19:32:07 2001 +++ map.c Sun Sep 16 18:34:09 2001 @@ -381,12 +381,16 @@ if (tmp->last_sp) { if (check_inv_recursive(op,tmp)==NULL) return 1; + else + continue; } else { /* In this case, the player must not have the object - * if they do, they can't pass through. */ if (check_inv_recursive(op,tmp)!=NULL) /* player has object */ return 1; + else + continue; } } /* if check_inv */ --==_Exmh_21058014690-- From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:01:39 2005 Subject: No subject In-Reply-To: References: Message-ID: <20010919075237.B5979@mids.student.utwente.nl> On Sat, Aug 25, 2001 at 11:24:36AM -0500, Don Grey wrote: > I found a bug that makes MIDS go down for good. I did it last night but > thought it was a coincidence because 2 or 3 people had joined before it > crashed. Please report bugs to crossfire-devel@lists.real-time.com, (you don't have to do it with this email anymore because I reply to crossfire-devel) > Anyway, anyone who plays on MIDS is used to the constant crashing but it > comes back up in a minute or so usually. > > WELL, this bug causes it to die and NOT come back up. As far as I know this is NOT true, there was no permanent crash according to my logfiles > Anyway to reproduce it: > > Stand on a building or near a building and read "Summon Pet Monster" > scrolls. > > I did it last night and again today. I think it has to be more than 1 for it > > to die. > > Anyway.. When it dies it nevercomes back :( The corefiles for the last crashes of mids.student.utwente.nl are on: http://mids.student.utwente.nl/~crossfire/cores/ > So please bring MiDS up and disable summon pet monster until its fixed!! I am not going to disable options to prevent the server from crashing. I AM going to post a warning on the Fido messageboard that asks people not to use it. Please don't exploit this bug to gain advantages Thanks for your bugreport! Joris Bontje / mids _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:01:55 2005 Subject: No subject Message-ID: maps, and I'm not suggesting otherwise. But it is reasonable to assume that different DMs will want to build worlds with a different feel to them. I might want to recreate Tolkien's world, or Greyhawk for example, and I don't anticipate everyone else wanting to do the same. > > But I am thinking of changing the way to do cities - I'm now leaning to giving > the city its own 50x50 tile, and updating the links in the adjoining world maps > to use this tile, and putting a note in the 'missing' tile that in fact this > tile is /scorn/city or the like. This at least makes it a little easier to move > things around, and I think will also make it a bit easier to know how maps are > related to each other (eg, everything in /scorn would go back to /scorn/city, > and not /world/world_110_124 for example). > This approach shares much of the value of what I was trying to suggest, so I won't try to argue you out of it, but I do think you should consider whether it is feasible to put every city on a mod 50 boundary. Cheers, -kls -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:02:13 2005 Subject: No subject Message-ID: something like (if spell->owner == victim) do_no_damage? That is certainly a reasonable approach - it means monsters won't hurt themselves. However, it also seems to mean that the monsters could immolate itself and by safe. Now in AD&D, I've played with some DM's that say your immune to your own magic (damage wise) - the above described approach seems to be doing that - no big deal. It will probably be advantagous to the players in the end (they can wander into a room full of monsters, wait for the monsters to surround them, and cast large fireball on themselves). As AV said, this doesn't really help out cases where there are bunches of monsters - I'm sure many of the spellcasters when in groups will still come their friends. So it doesn't completely fix the problem (there will now be at least 1 spellcaster remaining instead of none, but the room still could have started with 10). > What you describe above is true, but a seperate issue. > Currently, mapmakers must ensure that special monsters > don't get any equipment to apply. That works. > (Set "randomitems none", "pick_up 0", etc) > This could be fixed by storing "special" resistances in > a force and applying that to the monster at loading-time. > Unfortunately this is hard to realize, because it would > need to be implemented into the Crossfire object-loader > which is a great pile of sh... eh... *complicated stuff*. ;) Actually, that should all work - the only thing that may be slightly suspect is it calling fix_player on loaded monsters. but if it doesn't, it then means it is using the values as saved. So if you did something like put 'resist_fire 100' in the monster, and then an applied force object of 'resist_fire 100' in the inventory, the right thing would happen - monster starts with 100 resistance. IF it then applies something, fix_player is called then, and it will find the applied force object which has that value, and then use it. The problem with this is that it is more work to set up. And you still have cases where you don't want the monster to kill itself, but you want players to be able to kill it. Think of the conjurers, which may have any of a variety of spells - you don't want them to kill them, but it would be pretty unfair to make them immune to every attacktype they might ever cast. > What I intend to fix is the problem that many boss-monsters > suck because they either self-destruct due to low resistances, > or they're too hard due to immunities. > The patch is designed to help map-designers to create > special monsters of a more balanced kind. I don't see any real problem with it. I would think it should be a pretty minor mod, so would also be easy to adjust or remove later if it just doesn't work for some reason. If further refinement is needed, something like a FLAG_IMMUNE_OWN_SPELLS could be added to control it to a finer degree. You could also make rings/amulets with that properlty as some bonus for players. From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:02:35 2005 Subject: No subject Message-ID: The problem is, that in a 1028x768 screen (thats the maximum for 17' monitors) the room is far to small to do it. If you open the arch panel to a size you need, you will not see much from the map windows - and visa verse. One problem is that we need a really small font in this panel. The normal font is to big. But i have not the coding knowledge to put a useful small font in it and override the normal one. Every time we tried, some functions (comboboxes, menues) use the old one. The final goal is to put all of AVs setting windows in this panel - and make it possible to edit in it on the fly. Fact is that we have the same problem as you. On this stage of coding, you really should have same experience about how this all is working. I don't think you can grap this from books or examples - you need to have done it before and try out (well, thats whats a experienced coder is). And java is on this stage really not trivial. So, we really need a coder who contribute time and work to migrate the map arch info in this panel. Until this, the panel will be "under construction". Michael > > Mark Wedel wrote: > > > > One request that I've made before would be for the map windows to be > > their own top level windows managed by the OS instead of > subpanes within > > the editor. Alternatively, if the layout could be a bit different so > > that the selected object information on the map was all done in > a second > > column to the right of the one that is used for selecting stuff to > > insert in the map. > > > > The odd geometry of my system (3200x1200) means that even if I > maximize > > the window size of the editor, I effectively lose a lot of editing > > space, as the pane for selecte object spans the entire width of the > > screen, which isn't very useful. > > I actually did some quick hacks, and at least have my first > point working > (individual top level managed for each map). > > I need to hack around some more - the layout of the main window > is now less > optimal, because the pane area that used to be used for that > information is > completely unused. I need to poke around some more and see about > moving over > the map information to that pane - then I could have a 400x1000 > (or thereabouts) > window for that, and devote the rest of my screen for the map stuff. > > The problem with this is I'm not sure how to deal with this as > a configuration > option. I'm a pretty java newbie, and the change I basically did > was change the > map stuff from inheriting from the JinternalFrame to JFrame. I > have no idea how > that could get done as a runtime option (maybe inheriting from > both, and using > the correct constructors depending on the desired behaviour)? > > There is also what is perhaps some other behaviour I haven't > figured out - > using the close (delete) feature of the window manager on these > new map panes is > ignored - I'm sure there must be some setting someplace to handle > what to do on > a requested close event. > > The close from the editor menu does close the window. I'm not > sure how it > figures out which one would get closed - I'm guessing the one > last selected. > > The easiest solution may be to just include the diffs within the editor > distribution and have people just apply the diffs if they want > this different > behaviour. I suppose for a 'binary' distribution, both versions > could be supplied. > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:02:35 2005 Subject: No subject Message-ID: configure:5652: checking Python.h usability configure:5661: gcc -c -g -O2 conftest.c >&5 configure:5690:20: Python.h: No such file or directory configure:5664: $? = 1 configure: failed program was: #line 5655 "configure" #include "confdefs.h" #include #if HAVE_SYS_TYPES_H # include #endif #if HAVE_SYS_STAT_H # include #endif From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:02:46 2005 Subject: No subject Message-ID: > In addition to all the passed > compile options, each compiled file now takes numerous lines, eg: [...] This is very usefull for many developers. And lack of those messages would be esspeccialy anoying to developers used to autoconf/automake projects (there are more and more of them). > I personally find the old method greatly preferable - with the elimination > of all those extra lines, it is much easier to see any possible warnings or > errors that may happen during compilation. Its very easy to just one or > two line errors/warnings to get lost with the automake setup. configure CFLAGS=-Werror And make will stop on first compilation error/warnig. Greets, Jacek PS. The reply is a bit late, but I was on my holidays :-) From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:02:48 2005 Subject: No subject Message-ID: ... Installing ./wizhelp/free Installing ./wizhelp/freeze /usr/bin/install: cannot stat `./wizhelp/freeze': No such file or directory Installing ./wizhelp/goto Installing ./wizhelp/invisible ... From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:02:49 2005 Subject: No subject Message-ID: clean_friendly_list: Removed 1 bogus links CS: connection from client of type < GTK Unix Client 1.3.0> Get SetupCmd:: map1acmd 1 sound 1 sexp 1 darkness 1 newmapcmd 1 faceset 0 facecache 0 itemcmd 2 SendBack SetupCmd:: setup map1acmd 1 sound 1 sexp 1 darkness 1 newmapcmd 1 faceset 0 facecache 0 itemcmd Get SetupCmd:: mapsize 12x12 SendBack SetupCmd:: setup mapsize 12x12 Get SetupCmd:: faceset 0 SendBack SetupCmd:: setup faceset 0 Trying to load map /home/games/share/crossfire/maps/HallOfSelection. load_original_map: /HallOfSelection (0) Can't open /home/games/var/crossfire/maps/HallOfSelection Can't open overlay /home/games/var/crossfire/maps/HallOfSelection enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1) PYTHON - triggerEvent:: eventcode 20 Object ring seems to have too low item power? 21 > 7 Object ring seems to have too low item power? 11 > 5 Trying to load map /home/games/share/crossfire/maps/city/city. load_original_map: /city/city (0) Can't open /home/games/var/crossfire/maps/city/city Can't open overlay /home/games/var/crossfire/maps/city/city enter_map: supplied coordinates are not within the map! (/city/city: -1, -1) PYTHON - triggerEvent:: eventcode 20 PYTHON - triggerEvent:: eventcode 18 Checksums: 0 0 LOGIN: Player named SirK from ip 127.0.0.1 Trying to load map /home/games/var/crossfire/players/SirK/_city_apartment_apartments. load_original_map: /home/games/var/crossfire/players/SirK/_city_apartment_apartments (2) PYTHON - triggerEvent:: eventcode 21 PYTHON - triggerEvent:: eventcode 20 Scripting Weapon wielded PYTHON - triggerEvent:: eventcode 21 PYTHON - triggerEvent:: eventcode 20 Trying to load map /home/games/share/crossfire/maps/city/misc/beginners. load_original_map: /city/misc/beginners (0) Can't open /home/games/var/crossfire/maps/city/misc/beginners Can't open overlay /home/games/var/crossfire/maps/city/misc/beginners PYTHON - triggerEvent:: eventcode 21 PYTHON - triggerEvent:: eventcode 20 get_nearest_player: Found free/non friendly object on friendly list PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! Resetting map /HallOfSelection. PYTHON - triggerEvent:: eventcode 22 Event MAPRESET generated by /HallOfSelection PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! make_path_tofile /home/games/var/crossfire/players/SirK/_city_apartment_apartments... Saving map /home/games/var/crossfire/players/SirK/_city_apartment_apartments PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! Saving map /city/city PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! Resetting map /home/games/var/crossfire/players/SirK/_city_apartment_apartments. PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! PYTHON - triggerEvent:: eventcode 2 PYTHON - HandleEvent:: got script file >/python/weapon_occidental_mages.py< PYTHON - HandleEvent:: script loaded (/python/weapon_occidental_mages.py)! BUG: SK_level(arch igate_closed_2, name iron gate): level <= 0 BUG: SK_level(arch igate_closed_2, name iron gate): level <= 0 From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:02:51 2005 Subject: No subject Message-ID: When you set "walk_on 0" to a button it will never get pressed because it doesn't realize a step-on. When you set "walk_off 0" the button will get pressed only once and never be released because it doesn't realize the step-off. Kurt's proposed changes make a lot of sense, really. AFAIK it is not possible to make a sane work-around for the problem, and I really tried hard once. AndreasV From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:03:18 2005 Subject: No subject Message-ID: disadvantages. On the good side, it tries to keep the client's view of the universe from getting too far ahead of the server's view (e.g. the chest/Dragon example above). The down side is that if enough many commands are queued quickly enough to overrun the window size, what one enters is not necessarily what one gets back. My attempt to issue 50 'search' commands, for example, actually executed some number less than that (as shown by the error message above)... with potentially painful consequences. Fortunately, the command window size is determined by the client. The following describes how to turn this particular knob on the Linux client (other clients may provide different mechanisms). The 'help command describes two commands of interest: 'cwindow N sets the window size to N (1...127), and 'savedefaults creates a .crossfire/defaults file, which will include the command_window setting. In my case both the client and the server on the same machine, a 32 Mb 486DX4-100 with SuSE Linux 6.4. For the most part this works acceptably, but until I cranked the 'cwindow setting up to 40 I was losing a _lot_ of attempts to stack multiple 'use_skills praying' commands. Even at 40, as you can see from the above error messages, I'm not actually doing all the 'search'ing I _thought_ I was doing, so I'll probably increase the setting to something in the 60-80 range and monitor my stderr output. Hope this helps. -- My thanks to Mark Wedel, whose comments a few days back started my research on this. However, I should point out that any typos, misinterpretations, or misreadings of the Crossfire code are mine and mine alone (;-). Frank McKenney Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:03:34 2005 Subject: No subject Message-ID: go 8E, then move 1N. The countryside will undergo some "odd" transitions, but if you move far enough W, S, or E, things will clear up. One final note: The "lost at sea" described above is not the same as the one I encountered a while back exiting the Ruins of Euthville. That one put me on the W side of the water; this one leaves you on the N side. Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 E-mail: frank_mckenney@mindspring.com From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:03:52 2005 Subject: No subject Message-ID: "pngcrush is an excellent batch-mode compression utility for PNG images. Depending on the application that created the original PNGs, it can improve the file size anywhere from a few percent to 40% or more (completely losslessly). The utility also allows specified PNG chunks (e.g. text comments) to be inserted or deleted, and it can fix incorrect gamma info written by Photoshop 5.0 as well as the erroneous iCCP chunk written by Photoshop 5.5." Perhaps we could add comments that tell that something like "this png is used in an open source RPG crossfire. http://...". :-) -- BSc. Pertti Karppinen |'Bridge Players | Systems Designer, University of Jyvaskyla, Finland | Do | http://www.iki.fi/~pjka/ | Office : +358 14 260 2088 | It | HAM: OH6KTR QTH: KP22UF | Cellular: +358 40 564 0786 | on the Table' | From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:03:59 2005 Subject: No subject Message-ID: After killing the acid spheres, go downstairs and look for a square where you can cast spells. It's a "special-looking" sand square to the north. Cast show invisible there and pull the lever that appears. Now I guess you'll say: "WTF??". So feel free to modify this map and insert a hint or something. :-) Andreas V. From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:04:18 2005 Subject: No subject Message-ID: At least this modifier to damage is on the damage variable itself and not on something else even more bizarre like "last_sp". Have you read the docs on diseases? Your laundry list of suggested capabilities below are ALL in diseases right now, with the exception of "percentage of current HP", a feature I didn't think worth bothering with, since I don't see much use in geometrically decreasing damage. So diseases CAN in practice (not just in theory): do fixed HP damage do a percentage of MAX HP have both of those adjusted by the caster level hit with various attacktypes reduce various stats reduce hp and mana regen get progressively worse with time and more deadly if not cured be more or less contageous, depending on caster level have a different contageos range, depending on caster level lie on the ground and infect anyone who investigates a corpse that died of a disease, for a tunable period of time have messages and symptoms (perhaps creating objects) based on the disease And to do all this I had to use the available crossfire object items as parameters, which means for some of the parameters I was able to use sensible names like "Cha" for reducing charisma, for others, I had to do things like what you object to. Anyway, this somewhat lame situation could be fixed by doing a re-write of Crossfire in C++, a measure no one has stepped forward to do.... PM > Also, using +/- limits diseases to only two types of damage modifiers and > there is no inherent reason for such a limit. Diseases could, in theory, > do fixed HP damage, a percentage of current HP, a percentage of MAX HP and > all of these further either independent of caster level or adjuster by > caster level. A disease like gangrene might make more sense as a percentage > of current HP while a disease like sepsis might make more sense as a > percentage of max HP while a cold might be a fixed number of HP (a > strong person might be barely affected while a weak person is comparatively > hit hard). > > Scott Wedel > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From bogus@does.not.exist.com Thu Jan 13 17:53:03 2005 From: bogus@does.not.exist.com () Date: Thu Jan 13 18:04:23 2005 Subject: No subject Message-ID: a spell is available in "book format" instead of "book format - available in stores" And since this is where the website information is obtained, that's why it appears as it does. > The following ones have been marked as quests, although I've never seen > some of them so I'm not sure if they are really quests or should not be > marked as quest: > > ball lightning > dragon breath > large icestorm > face of death > comet > meteor swarm > color spray > polymorph > cause critical wounds IIRC, polymorph has been disbaled due to issues of abuse. Cause Critical Wounds is a spell granted by Sorig. The others are available through quests. Now, for corrections and updates - did you happen to edit the HTML first before creating the .pdf and .tex file? If so, can you contact me off-list about making a copy available? I'd rather not go through that table line by line. =) Thanks. - Rick Tanner leaf@real-time.com From leaf at real-time.com Fri Jan 14 17:55:42 2005 From: leaf at real-time.com (Rick Tanner) Date: Fri Jan 14 18:22:56 2005 Subject: [crossfire] Re: [CF-Devel] Planned crossfire release, approx Jan 22-23 In-Reply-To: <41E3901E.8070608@sonic.net> References: <41E3901E.8070608@sonic.net> Message-ID: Just replying to this message as a reminder for people on the upcoming (pending?) release. =) On Tue, 11 Jan 2005, Mark Wedel wrote: > > As Ryo suggested, giving some people some advanced notice of when I plan to > make a new release is probably a good idea, to commit those changes. > > My plan is to make a release sometime on the weekend of the 22-23rd. > > I propose the following schedule: > > This week: > Commit any minor changes, bug fixes, or other modest changes (IMO, it is a bit > later for 'major changes' at this time). > Next week (17-22) - only commit critical bug fixes. > > The real idea is so that I can update metalforge around the 17-18th and give > it several days of run time with what will really ship as the official release. From pc-crossfire04 at crowcastle.net Sun Jan 16 21:13:25 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Sun Jan 16 21:18:21 2005 Subject: [crossfire] client: pickup count Message-ID: <1105931605.13868.42.camel@myth.crowcastle.com> I just updated from CVS for the first time in a good while. It used to be that if, say, I wanted to pick up 7 waters, I would move to a stack of water, hit '7' and then ',' with the result being getting 7 waters picked up. Now it tries to pick up all the waters. Now I can only get the count to work when trying to pick up using the mouse. Now it also has a problem with not clearing the count like it used to. This is with the gtk client under Linux. Was there an intentional change of some sort? I found the old behaviour to be much more useful. --PC From robert at timetraveller.org Sun Jan 16 21:59:57 2005 From: robert at timetraveller.org (Robert Brockway) Date: Sun Jan 16 22:03:20 2005 Subject: [crossfire] client: pickup count In-Reply-To: <1105931605.13868.42.camel@myth.crowcastle.com> References: <1105931605.13868.42.camel@myth.crowcastle.com> Message-ID: On Sun, 16 Jan 2005, Preston Crow wrote: > I just updated from CVS for the first time in a good while. It used to > be that if, say, I wanted to pick up 7 waters, I would move to a stack > of water, hit '7' and then ',' with the result being getting 7 waters > picked up. Now it tries to pick up all the waters. > > Now I can only get the count to work when trying to pick up using the > mouse. > > Now it also has a problem with not clearing the count like it used to. How long since you updated? I'm been seeing the problem of the count not clearing with the GTK client for a good couple of years, going back over 2 or more versions (from memory). Yes, it is annoying. I believe the curent client is the latest release. In any case I built it on May 1, 2004. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, rbrockway@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin From robert at timetraveller.org Sun Jan 16 21:59:57 2005 From: robert at timetraveller.org (Robert Brockway) Date: Sun Jan 16 22:14:54 2005 Subject: [crossfire] client: pickup count In-Reply-To: <1105931605.13868.42.camel@myth.crowcastle.com> References: <1105931605.13868.42.camel@myth.crowcastle.com> Message-ID: On Sun, 16 Jan 2005, Preston Crow wrote: > I just updated from CVS for the first time in a good while. It used to > be that if, say, I wanted to pick up 7 waters, I would move to a stack > of water, hit '7' and then ',' with the result being getting 7 waters > picked up. Now it tries to pick up all the waters. > > Now I can only get the count to work when trying to pick up using the > mouse. > > Now it also has a problem with not clearing the count like it used to. How long since you updated? I'm been seeing the problem of the count not clearing with the GTK client for a good couple of years, going back over 2 or more versions (from memory). Yes, it is annoying. I believe the curent client is the latest release. In any case I built it on May 1, 2004. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, rbrockway@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin From pc-crossfire04 at crowcastle.net Sun Jan 16 22:12:49 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Sun Jan 16 22:14:57 2005 Subject: [crossfire] client: pickup count In-Reply-To: References: <1105931605.13868.42.camel@myth.crowcastle.com> Message-ID: <1105935169.13874.45.camel@myth.crowcastle.com> On Sun, 2005-01-16 at 22:59, Robert Brockway wrote: > On Sun, 16 Jan 2005, Preston Crow wrote: > > > I just updated from CVS for the first time in a good while. It used to > > be that if, say, I wanted to pick up 7 waters, I would move to a stack > > of water, hit '7' and then ',' with the result being getting 7 waters > > picked up. Now it tries to pick up all the waters. > > > > Now I can only get the count to work when trying to pick up using the > > mouse. > > > > Now it also has a problem with not clearing the count like it used to. > > How long since you updated? I'm been seeing the problem of the count not > clearing with the GTK client for a good couple of years, going back over 2 > or more versions (from memory). Yes, it is annoying. I believe the > curent client is the latest release. In any case I built it on May 1, > 2004. I think the old one was build on 9 May 2004. It didn't always clear out the pickup count, but it worked pretty well. With the current CVS version, when the pickup count is zero, and you start to enter something, instead of starting with what you enter, it suddenly reverts back to the old number and what you add is appended on to that. --PC From pc-crossfire04 at crowcastle.net Sun Jan 16 22:12:49 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Sun Jan 16 22:15:00 2005 Subject: [crossfire] client: pickup count In-Reply-To: References: <1105931605.13868.42.camel@myth.crowcastle.com> Message-ID: <1105935169.13874.45.camel@myth.crowcastle.com> On Sun, 2005-01-16 at 22:59, Robert Brockway wrote: > On Sun, 16 Jan 2005, Preston Crow wrote: > > > I just updated from CVS for the first time in a good while. It used to > > be that if, say, I wanted to pick up 7 waters, I would move to a stack > > of water, hit '7' and then ',' with the result being getting 7 waters > > picked up. Now it tries to pick up all the waters. > > > > Now I can only get the count to work when trying to pick up using the > > mouse. > > > > Now it also has a problem with not clearing the count like it used to. > > How long since you updated? I'm been seeing the problem of the count not > clearing with the GTK client for a good couple of years, going back over 2 > or more versions (from memory). Yes, it is annoying. I believe the > curent client is the latest release. In any case I built it on May 1, > 2004. I think the old one was build on 9 May 2004. It didn't always clear out the pickup count, but it worked pretty well. With the current CVS version, when the pickup count is zero, and you start to enter something, instead of starting with what you enter, it suddenly reverts back to the old number and what you add is appended on to that. --PC From tchize at myrealbox.com Mon Jan 17 02:23:39 2005 From: tchize at myrealbox.com (tchize) Date: Mon Jan 17 02:28:36 2005 Subject: [crossfire] Please do not post to both mailiing lists In-Reply-To: References: <1105931605.13868.42.camel@myth.crowcastle.com> Message-ID: <200501170923.39401.tchize@myrealbox.com> Sorry, but posting to cf-devel and crossfire@metalforge is quite annoying, i subscribed to only one mailing list and i received the messages twice :) From rbrockway at opentrend.net Mon Jan 17 07:44:52 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Mon Jan 17 07:53:26 2005 Subject: [OT] Re: [crossfire] Please do not post to both mailiing lists In-Reply-To: <200501170923.39401.tchize@myrealbox.com> References: <1105931605.13868.42.camel@myth.crowcastle.com> <200501170923.39401.tchize@myrealbox.com> Message-ID: <20050117133942.R17695@nirmala.opentrend.net> On Mon, 17 Jan 2005, tchize wrote: > Sorry, but posting to cf-devel and crossfire@metalforge is quite annoying, i > subscribed to only one mailing list and i received the messages twice :) Strange you got it twice if you are subscribed to only one list. In any case... If you use Unix and procmail you can have it remove duplictes for you. I have this in my ~/.procmailrc. It is straight from the procmailex man page. Put this at the top of ~/.procmailrc: # Weed out dupes :0 Wh: msgid.lock | formail -D 8192 msgid.cache Always verify the legitmacy of new procmail receipes before using them. Yes, I did cross-post this sorry :) Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (www.spi-inc.org) From rbrockway at opentrend.net Mon Jan 17 07:44:52 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Mon Jan 17 08:26:35 2005 Subject: [OT] Re: [crossfire] Please do not post to both mailiing lists In-Reply-To: <200501170923.39401.tchize@myrealbox.com> References: <1105931605.13868.42.camel@myth.crowcastle.com> <200501170923.39401.tchize@myrealbox.com> Message-ID: <20050117133942.R17695@nirmala.opentrend.net> On Mon, 17 Jan 2005, tchize wrote: > Sorry, but posting to cf-devel and crossfire@metalforge is quite annoying, i > subscribed to only one mailing list and i received the messages twice :) Strange you got it twice if you are subscribed to only one list. In any case... If you use Unix and procmail you can have it remove duplictes for you. I have this in my ~/.procmailrc. It is straight from the procmailex man page. Put this at the top of ~/.procmailrc: # Weed out dupes :0 Wh: msgid.lock | formail -D 8192 msgid.cache Always verify the legitmacy of new procmail receipes before using them. Yes, I did cross-post this sorry :) Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (www.spi-inc.org) From tchize at myrealbox.com Mon Jan 17 09:39:18 2005 From: tchize at myrealbox.com (tchize) Date: Mon Jan 17 09:43:27 2005 Subject: [OT] Re: [crossfire] Please do not post to both mailiing lists In-Reply-To: <20050117133942.R17695@nirmala.opentrend.net> References: <1105931605.13868.42.camel@myth.crowcastle.com> <200501170923.39401.tchize@myrealbox.com> <20050117133942.R17695@nirmala.opentrend.net> Message-ID: <200501171639.18656.tchize@myrealbox.com> Took a look at http://mailman.metalforge.org/mailman/listinfo/crossfire and am only listed on one mailing list. I suppose is the same mailing list with a new address. As i didn't see any annoucements about any change for the cf-devel mailing list moving to metalforge, i guess we should stick to the cf-devel one. And no, i can't use a procmail filter on the novell's free servers, no shell account :) Le Lundi 17 Janvier 2005 14:44, Robert Brockway a ?crit : > On Mon, 17 Jan 2005, tchize wrote: > > Sorry, but posting to cf-devel and crossfire@metalforge is quite > > annoying, i subscribed to only one mailing list and i received the > > messages twice :) > > Strange you got it twice if you are subscribed to only one list. In any > case... > > If you use Unix and procmail you can have it remove duplictes for you. I > have this in my ~/.procmailrc. It is straight from the procmailex man > page. > > Put this at the top of ~/.procmailrc: > > # Weed out dupes > > :0 Wh: msgid.lock > : > | formail -D 8192 msgid.cache > > Always verify the legitmacy of new procmail receipes before using them. > > Yes, I did cross-post this sorry :) > > Rob From leaf at real-time.com Mon Jan 17 12:47:57 2005 From: leaf at real-time.com (Rick Tanner) Date: Mon Jan 17 12:50:31 2005 Subject: [crossfire] Please do not post to both mailiing lists In-Reply-To: <200501170923.39401.tchize@myrealbox.com> References: <1105931605.13868.42.camel@myth.crowcastle.com> <200501170923.39401.tchize@myrealbox.com> Message-ID: On Mon, 17 Jan 2005, tchize wrote: > Sorry, but posting to cf-devel and crossfire@metalforge is quite annoying, i > subscribed to only one mailing list and i received the messages twice :) crossfire-devel@lists.real-time.com is now an alias for crossfire@metalforge.org The mailing list moved to a new server with the new list domain name (metalforge.org) to ease the transition on a technical level. ;) So, going forward - you just need to post to one address and not the other. Don't post to both. From mwedel at sonic.net Tue Jan 18 01:55:04 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jan 18 01:58:32 2005 Subject: [crossfire] client: pickup count In-Reply-To: <1105935169.13874.45.camel@myth.crowcastle.com> References: <1105931605.13868.42.camel@myth.crowcastle.com> <1105935169.13874.45.camel@myth.crowcastle.com> Message-ID: <41ECC0D8.6020809@sonic.net> > > I think the old one was build on 9 May 2004. It didn't always clear out > the pickup count, but it worked pretty well. With the current CVS > version, when the pickup count is zero, and you start to enter > something, instead of starting with what you enter, it suddenly reverts > back to the old number and what you add is appended on to that. I just tried this out, and it worked normal, as far as I'm concerned. In my testing, I dropped a huge pile of platinum, and disabled auto pickup mode. hitting '14' ',' picked up 14 platinum, and so on for other quantities. One thing to look at is the 'count' spin at the top of the inventory pane. I also run with no popup mode and non split (one big window). One oddity, which as I recall has no good solution, is that if I take a step or do other command between entering the number and executing the pickup, that it doesn't use the account. Eg, typing '4', 'who', ',' will result picking up the entire pile, not just 4 coins. There is also some odd remembering of those results, as if I then click to drop the coins again, it only drops 4 coins, not the entire pile. The problem, if memory serves, is that there are more commands than just pickup/drop that the count can be useful on. So the client basically has to send it for every command to the server, and then reset the count, since the client can't easily know if count will be useful for the command sent (and example here is dimension door, where count is used to specific a specific number of spaces to move, and that is done with the 'fire' command). There may be some others I'm also forgetting about beyond just the drop and pickup and that case for fire. However, I think where the 'caching' of the unused one comes in above is that the server remembers the count value the client sent it. so I think there is some strange result of the server remembering the count it didn't use, or for some reason, the client not clearing it. In any case, it basically works. This could certainly be improved by the server sending the count value it is expecting to use to the client (because those special cases I mention above do clear the server side count). Thus, the client would know if its count value was used or not (but as I think about it, I'm not sure if the client should care). One possibility for what it doesn't work is if there is some intervening command from entering the number to typing the comma (maybe comma is bound to something more than just pickup?) From mwedel at sonic.net Tue Jan 18 01:55:04 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jan 18 02:17:17 2005 Subject: [crossfire] client: pickup count In-Reply-To: <1105935169.13874.45.camel@myth.crowcastle.com> References: <1105931605.13868.42.camel@myth.crowcastle.com> <1105935169.13874.45.camel@myth.crowcastle.com> Message-ID: <41ECC0D8.6020809@sonic.net> > > I think the old one was build on 9 May 2004. It didn't always clear out > the pickup count, but it worked pretty well. With the current CVS > version, when the pickup count is zero, and you start to enter > something, instead of starting with what you enter, it suddenly reverts > back to the old number and what you add is appended on to that. I just tried this out, and it worked normal, as far as I'm concerned. In my testing, I dropped a huge pile of platinum, and disabled auto pickup mode. hitting '14' ',' picked up 14 platinum, and so on for other quantities. One thing to look at is the 'count' spin at the top of the inventory pane. I also run with no popup mode and non split (one big window). One oddity, which as I recall has no good solution, is that if I take a step or do other command between entering the number and executing the pickup, that it doesn't use the account. Eg, typing '4', 'who', ',' will result picking up the entire pile, not just 4 coins. There is also some odd remembering of those results, as if I then click to drop the coins again, it only drops 4 coins, not the entire pile. The problem, if memory serves, is that there are more commands than just pickup/drop that the count can be useful on. So the client basically has to send it for every command to the server, and then reset the count, since the client can't easily know if count will be useful for the command sent (and example here is dimension door, where count is used to specific a specific number of spaces to move, and that is done with the 'fire' command). There may be some others I'm also forgetting about beyond just the drop and pickup and that case for fire. However, I think where the 'caching' of the unused one comes in above is that the server remembers the count value the client sent it. so I think there is some strange result of the server remembering the count it didn't use, or for some reason, the client not clearing it. In any case, it basically works. This could certainly be improved by the server sending the count value it is expecting to use to the client (because those special cases I mention above do clear the server side count). Thus, the client would know if its count value was used or not (but as I think about it, I'm not sure if the client should care). One possibility for what it doesn't work is if there is some intervening command from entering the number to typing the comma (maybe comma is bound to something more than just pickup?) From mikeeusaaa at yahoo.com Tue Jan 18 02:36:42 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Tue Jan 18 02:38:32 2005 Subject: [crossfire] Please do not post to both mailiing lists In-Reply-To: Message-ID: <20050118083642.6519.qmail@web61007.mail.yahoo.com> Yea yo, dont [beep]ing double post yo. Ight> Is that OK? Man east chost wisdom hits west chost hype articulating into a both-coast fight. Peoples shoot rokets, no arrows, no gore just body parts flyin' while mackin the elvin whore. Wizards be [beep]iching about who knows what coffe whenches be listinin making bets on rost bump Scorn is a burnin, like always is be the breakin wheel be turnin, crushing victims at the knee but all yall will do about all this criminal shyte is post on both lists like you just took a dope hit. Damn foos, you don't KNOW what iz like on the streets of the ghettos in crossfire... you and yo rich [beep] computauahz. Pfft yeah you keep it real... reall kepin it. (mumble)[beep]ing uncle tom elvin sisy boiz --- Rick Tanner wrote: > On Mon, 17 Jan 2005, tchize wrote: > > > Sorry, but posting to cf-devel and > crossfire@metalforge is quite annoying, i > > subscribed to only one mailing list and i received > the messages twice :) > > crossfire-devel@lists.real-time.com is now an alias > for > crossfire@metalforge.org > > The mailing list moved to a new server with the new > list domain name > (metalforge.org) to ease the transition on a > technical level. ;) > > So, going forward - you just need to post to one > address and not the > other. Don't post to both. > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From tchize at myrealbox.com Tue Jan 18 03:00:10 2005 From: tchize at myrealbox.com (tchize) Date: Tue Jan 18 02:58:34 2005 Subject: [crossfire] Please do not post to both mailiing lists In-Reply-To: <20050118083642.6519.qmail@web61007.mail.yahoo.com> References: <20050118083642.6519.qmail@web61007.mail.yahoo.com> Message-ID: <200501181000.11173.tchize@myrealbox.com> Did you smoke something, take illegal substances or eat quite old food Mitch? What's the point in this mail?? Le Mardi 18 Janvier 2005 09:36, Mitch Obrian a ?crit : > Yea yo, dont [beep]ing double post yo. Ight> Is that > OK? Man east chost wisdom hits west chost hype > articulating into a both-coast fight. > Peoples shoot rokets, no arrows, no gore > just body parts flyin' while mackin the elvin whore. > Wizards be [beep]iching about who knows what > coffe whenches be listinin making bets on rost bump > Scorn is a burnin, like always is be > the breakin wheel be turnin, > crushing victims at the knee > but all yall will do about all this criminal shyte > is post on both lists like you just took a dope hit. > > Damn foos, you don't KNOW what iz like on the streets > of the ghettos in crossfire... you and yo rich [beep] > computauahz. > > Pfft yeah you keep it real... reall kepin it. > (mumble)[beep]ing uncle tom elvin sisy boiz > > --- Rick Tanner wrote: > > On Mon, 17 Jan 2005, tchize wrote: > > > Sorry, but posting to cf-devel and > > > > crossfire@metalforge is quite annoying, i > > > > > subscribed to only one mailing list and i received > > > > the messages twice :) > > > > crossfire-devel@lists.real-time.com is now an alias > > for > > crossfire@metalforge.org > > > > The mailing list moved to a new server with the new > > list domain name > > (metalforge.org) to ease the transition on a > > technical level. ;) > > > > So, going forward - you just need to post to one > > address and not the > > other. Don't post to both. > > > > > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > __________________________________ > Do you Yahoo!? > The all-new My Yahoo! - What will yours do? > http://my.yahoo.com > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From tanner at real-time.com Tue Jan 18 08:32:46 2005 From: tanner at real-time.com (Bob Tanner) Date: Tue Jan 18 08:33:35 2005 Subject: [OT] Re: [crossfire] Please do not post to both mailiing lists In-Reply-To: <200501171639.18656.tchize@myrealbox.com> References: <1105931605.13868.42.camel@myth.crowcastle.com> <20050117133942.R17695@nirmala.opentrend.net> <200501171639.18656.tchize@myrealbox.com> Message-ID: <200501180832.47164@www.mn-linux.org.or.transmuter.real-time.com> On Monday 17 January 2005 09:39 am, tchize wrote: > Took a look at > http://mailman.metalforge.org/mailman/listinfo/crossfire > and am only listed on one mailing list. > I suppose is the same mailing list with a new > address. As i didn't see any annoucements about any change for the cf-devel > mailing list moving to metalforge, i guess we should stick to the cf-devel > one. > > And no, i can't use a procmail filter on the novell's free servers, no > shell account :) Hmm, my fault. Might not have explained it clearly to Leaf. Anyways, I merged crossfire-list and crossfire-devel from the old server into just crossfire on the new server. It seem most of the posts where capable of being on either list. With the forums, the line is even more obtuse. Just wanted to reduce the number of places you have to look to get crossfire info. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From rbrockway at opentrend.net Tue Jan 18 08:26:15 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Tue Jan 18 08:33:38 2005 Subject: [crossfire] client: pickup count In-Reply-To: <41ECC0D8.6020809@sonic.net> References: <1105931605.13868.42.camel@myth.crowcastle.com> <1105935169.13874.45.camel@myth.crowcastle.com> <41ECC0D8.6020809@sonic.net> Message-ID: <20050118141028.K17695@nirmala.opentrend.net> On Mon, 17 Jan 2005, Mark Wedel wrote: > I just tried this out, and it worked normal, as far as I'm concerned. > > In my testing, I dropped a huge pile of platinum, and disabled auto pickup > mode. > > hitting '14' ',' picked up 14 platinum, and so on for other quantities. Yes this works. My experience is this: If I ran your test I would also be able to pickup 14 as long as the count box was empty. The count now contains 14. If I try to pickup something else without entering a new number then it will pass 14 to the pickup routine again. Thus I'll pickup 14 of the new item or fail depending on whether there are more or less than 14 items. Any attempt to add a new number before the pickup will append to the 14. I need to move to the count box and "zero" it by repeatedly entering 0s until the number clears. Count will now operate normally until a new number is entered. Note, I've used pickup as an example here but this problem applies to everything using count IIRC. > One thing to look at is the 'count' spin at the top of the inventory pane. > > I also run with no popup mode and non split (one big window). I run with popups and non-split. I was going to change to no popup actually. Thanks for reminding me :) > One oddity, which as I recall has no good solution, is that if I take a step > or do other command between entering the number and executing the pickup, > that it doesn't use the account. > > Eg, typing '4', 'who', ',' will result picking up the entire pile, not just > 4 coins. > > There is also some odd remembering of those results, as if I then click to > drop the coins again, it only drops 4 coins, not the entire pile. My problem is also an odd remembering of the count but is not tied to me issuing commands between the count and ','. > In any case, it basically works. This could certainly be improved by the Yes, the problem I'm seeing can be worked around but it is a bit annoying. If I drop 14 platinum pieces I don't think the client or server should assume I am going to pickup 14 food or that I want the next number to start with 1 4 :) > server sending the count value it is expecting to use to the client (because > those special cases I mention above do clear the server side count). Thus, > the client would know if its count value was used or not (but as I think > about it, I'm not sure if the client should care). > > One possibility for what it doesn't work is if there is some intervening > command from entering the number to typing the comma (maybe comma is bound to > something more than just pickup?) As I read the first part of your post I was wondering this. I'll go look at the keybindings. This would certainly explain why I've seen it across numerous client and server versions since my keybindings are that old. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (www.spi-inc.org) From pc-crossfire04 at crowcastle.net Tue Jan 18 18:32:51 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Tue Jan 18 18:33:39 2005 Subject: [crossfire] broken formulae Message-ID: <1106094771.5137.9.camel@myth.crowcastle.com> I just fixed a few formulae. One was because leather armour is now just armour with a material type of leather. Several were because they used the arch name instead of title for talismans. Still broken are formulae that require a "potion of health" or a "balm of traveling." I'm not sure what the correct conversion is. --PC From pc-crossfire04 at crowcastle.net Tue Jan 18 18:55:10 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Tue Jan 18 18:58:38 2005 Subject: [crossfire] material type issue Message-ID: <1106096110.5133.14.camel@myth.crowcastle.com> I've noticed that if I buy a bunch of stuff from a table (like alchemical elements), they don't have a material type, but if I leave them in my apartment and come back after the map has been saved, the material type is set. This means that newly-bought items don't merge with older items (and they're indestructible). Is this something that is easily fixed? --PC From temitchell at sympatico.ca Wed Jan 19 22:36:34 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Wed Jan 19 22:38:50 2005 Subject: [crossfire] some bugs Message-ID: <1106195794.5396.20.camel@oberon.kameria> Haven't had much time to test for the upcoming release but I did pull latest CVS of the server out and did a fresh install - some things I found: 1. cannot install server without linking arch dir in the crossfire/lib and letting it do a collect (CVS debian woody) 2. healing potions created by tables or DMs still don't work 3/ some shop mats will not let me buy stuff even though I have money to buy the item - I manage to buy item for 12 plat but cannot buy healing potion in house of healing - message says "You lack 528 platinum coins, 3 gold coins and 6 silver coins to buy healing potion." even though I have over 800 platinum and change. 4. my mail to the old crossfire-devel@lists.real-time.com bounced. 5. Python Bank system not working- trying to deposit money results in: Traceback (most recent call last): File "/usr/local/CFS/share/crossfire/maps/python/IPO/banksay.py", line 64, in ? if (CFPython.PayAmount(activator, (int(text[1])*exchange_rate)*fees)): SystemError: ../Objects/longobject.c:391: bad argument to internal function -is this because im still using python 2.1 for CF server or do the bank scripts need to be modified? Should there be a warning of something during the ./configure if python < 2.2 is used? The slots don't work either - perhaps same reason. -- Todd Mitchell From temitchell at sympatico.ca Wed Jan 19 22:53:00 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Wed Jan 19 22:53:50 2005 Subject: [crossfire] some bugs In-Reply-To: <1106195794.5396.20.camel@oberon.kameria> References: <1106195794.5396.20.camel@oberon.kameria> Message-ID: <1106196780.5396.25.camel@oberon.kameria> Nevermind this one- I see now that I just kept misreading the freaking price all along... (urk!) > 3/ some shop mats will not let me buy stuff even though I have money > to > buy > the item - I manage to buy item for 12 plat but cannot buy healing > potion in house of healing - message says "You lack 528 platinum > coins, > 3 gold coins and 6 silver coins to buy healing potion." even though I > have over 800 platinum and change. From tanner at real-time.com Wed Jan 19 23:03:42 2005 From: tanner at real-time.com (Bob Tanner) Date: Wed Jan 19 23:08:52 2005 Subject: [crossfire] some bugs In-Reply-To: <1106195794.5396.20.camel@oberon.kameria> References: <1106195794.5396.20.camel@oberon.kameria> Message-ID: <20050120050342.GB9105@real-time.com> Quoting Todd Mitchell (temitchell@sympatico.ca): > 4. my mail to the old crossfire-devel@lists.real-time.com bounced. Please forward (with complete smtp headers) the bounce so I can investigate. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 From pc-crossfire04 at crowcastle.net Thu Jan 20 07:59:52 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Thu Jan 20 08:07:14 2005 Subject: [crossfire] door bug Message-ID: <1106229592.7177.2.camel@myth.crowcastle.com> A few minor bugs with unlocked doors (the ones that look like normal doors, but you can walk through them). * They have traps just as often as normal doors, but they can only be set off when trying to disarm them. * If you kill a monster standing on the same square as the door, you destroy the door (and set off any trap, I think). --PC From temitchell at sympatico.ca Thu Jan 20 09:31:53 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 20 09:40:23 2005 Subject: [crossfire] door bug In-Reply-To: <1106229592.7177.2.camel@myth.crowcastle.com> References: <1106229592.7177.2.camel@myth.crowcastle.com> Message-ID: <41EFCEE9.2000508@sympatico.ca> I don't think it's a bug but a map making error... I don't think there is an arch for these - they are just modified doors - the solution would be to search through the maps and look for doors with the no_ pass setting changed to 0 and remove their treasurelists. Maybe they should have their own arch and different images which people can be encouraged to use (except for special cases). Preston Crow wrote: >A few minor bugs with unlocked doors (the ones that look like normal >doors, but you can walk through them). > >* They have traps just as often as normal doors, but they can only be >set off when trying to disarm them. > >* If you kill a monster standing on the same square as the door, you >destroy the door (and set off any trap, I think). > > > From temitchell at sympatico.ca Thu Jan 20 09:41:24 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 20 09:52:37 2005 Subject: [crossfire] exploding MOBs Message-ID: <41EFD124.3070305@sympatico.ca> Is this crossfire discussion list for dev or crossfire in general - or have those two lists been merged into one list? Anyway I have a suggestion for future development I just thought of. It would be neat to have a arch flag that denotes a mob will explode on death. They could deal out their attack type or if people wanted to be a bit funky allow for a specific damage type for the explosion. Imagine posion puffballs or getting mobbed by a sort of puffy kobold that explodes doing drain damage... Should be fairly simple to do and might be fun. From nicolas.weeger at laposte.net Thu Jan 20 10:04:26 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jan 20 10:08:58 2005 Subject: [crossfire] exploding MOBs In-Reply-To: <41EFD124.3070305@sympatico.ca> References: <41EFD124.3070305@sympatico.ca> Message-ID: <41EFD68A.1050500@laposte.net> > Should be fairly simple to do and might be fun. I'd use some field like 'other_arch', maybe? and 2 fields to specify how many to spawn? But yeah, sure could be real fun :) Nicolas "Ryo" (who almost signed ~~~~ per evil Wikipedia habit...) From tanner at real-time.com Thu Jan 20 10:27:16 2005 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 20 10:40:43 2005 Subject: [crossfire] OT: Testing crossfire-admin@lists.real-time.com Message-ID: <20050120162715.GA10375@real-time.com> Testing. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 From temitchell at sympatico.ca Thu Jan 20 11:20:47 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 20 11:23:58 2005 Subject: [crossfire] exploding MOBs In-Reply-To: <41EFD68A.1050500@laposte.net> References: <41EFD124.3070305@sympatico.ca> <41EFD68A.1050500@laposte.net> Message-ID: <41EFE86F.2000805@sympatico.ca> Well you can put arches into inventory now - so you can already for example spawn a couple guards or fireballs or something when a MOB is destroyed. I was thinking of a will_explode and explode_attacktype flags where if will_explode = 1, it produces a little pop graphic and deals out damage from attacktype (or explode_attacktype if it's not 0). Nicolas Weeger wrote: >> Should be fairly simple to do and might be fun. > > > I'd use some field like 'other_arch', maybe? and 2 fields to specify > how many to spawn? > > But yeah, sure could be real fun :) > From tanner at real-time.com Thu Jan 20 15:27:36 2005 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 20 15:32:10 2005 Subject: [crossfire] OT: crossfire-admin@lists.real-time.com (approve this) Message-ID: <20050120212736.GA9825@real-time.com> Testing crossfire-admin@lists.real-time.com -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From tanner at real-time.com Thu Jan 20 15:40:20 2005 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 20 15:48:19 2005 Subject: [crossfire] crossfire-admin Message-ID: <20050120214020.GA10060@real-time.com> testing From kirschbaum at myrealbox.com Thu Jan 20 15:54:20 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Jan 20 15:57:10 2005 Subject: [crossfire] Re: [CF-Devel] Python questions In-Reply-To: <41DF1B9E.7000909@laposte.net> References: <41DF1B9E.7000909@laposte.net> Message-ID: <20050120215420.GA17596@idefix2.dvlp.in-medias-res.com> Nicolas Weeger wrote: > Also, under Windows, there's a big issue, which was already raised > some months ago, but is still there: the 'settings' variable is NOT > available from the plugin module - it has default values, not the ones > loaded from server itself. I'm not aware of this problem. Could you give an example to demonstrate that bug? (There are currently only a few Python functions (CFPython.GetXxxDirectory) that access the settings structure. But I can't think of any problem here because these functions are very simple: they just return "settings.xxxdir".) > And i fear all other variables are in the same case... I guess the > best fix would be to use callbacks for all those variables? There are more than 50 variables in the settings structure. For most of these variables, I can't see how they could be of any use to a script. Therefore I would rather not add callbacks for all variables but just add callbacks for variables that are actually needed. From kirschbaum at myrealbox.com Thu Jan 20 16:20:45 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Jan 20 16:22:11 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20050120222045.GA17834@idefix2.dvlp.in-medias-res.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > server/c_party.c: party password max length is 7, due to buffer size. > (i think it was a patch from Casper?) I had fixed this problem a few days before. (See the ChangeLog entry a few lines below.) My fix made passwords up to 8 characters work: the field party_struct.passwd can hold passwords of 8 characters length because it is declared as "char passwd[9];". IIRC the real problem was the code that put the password into the struct. It was missing a length check and possibly not terminating the password with '\0'. Other than that, it is now broken: passwords of 8 characters length are silently truncated to 7 characters, but passwords of 9 or more characters length are rejected with "The password must not exceed 8 characters". From kirschbaum at myrealbox.com Thu Jan 20 16:33:13 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Jan 20 16:37:11 2005 Subject: [crossfire] material type issue In-Reply-To: <1106096110.5133.14.camel@myth.crowcastle.com> References: <1106096110.5133.14.camel@myth.crowcastle.com> Message-ID: <20050120223313.GD17834@idefix2.dvlp.in-medias-res.com> > I've noticed that if I buy a bunch of stuff from a table (like > alchemical elements), they don't have a material type, but if I leave > them in my apartment and come back after the map has been saved, the > material type is set. This means that newly-bought items don't merge > with older items (and they're indestructible). > > Is this something that is easily fixed? I had the same problem while checking the Python plugin. The attached patch fixed the problem for me, but I don't know if using a fixed difficulty (5) is correct. -------------- next part -------------- Index: common/arch.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/arch.c,v retrieving revision 1.29 diff -w -c -5 -r1.29 arch.c *** common/arch.c 27 Oct 2003 07:24:13 -0000 1.29 --- common/arch.c 20 Jan 2005 22:30:37 -0000 *************** *** 571,580 **** --- 571,581 ---- return NULL; } op=get_object(); copy_object(&at->clone,op); op->arch=at; + set_materialname(op, 5, NULL); return op; } /* * Creates an object. This function is called by get_archetype() From kirschbaum at myrealbox.com Thu Jan 20 16:26:49 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Jan 20 16:37:15 2005 Subject: [crossfire] some bugs In-Reply-To: <1106195794.5396.20.camel@oberon.kameria> References: <1106195794.5396.20.camel@oberon.kameria> Message-ID: <20050120222649.GC17834@idefix2.dvlp.in-medias-res.com> Todd Mitchell wrote: > 5. Python Bank system not working- trying to deposit money results in: > > Traceback (most recent call last): > File "/usr/local/CFS/share/crossfire/maps/python/IPO/banksay.py", line 64, in ? > if (CFPython.PayAmount(activator, (int(text[1])*exchange_rate)*fees)): > SystemError: ../Objects/longobject.c:391: bad argument to internal function > > -is this because im still using python 2.1 for CF server or do the > bank scripts need to be modified? It is because I changed the Python plugin to use an uint64 for all variables holding money. This data type is not supported by Python below version 2.2. > Should there be a warning of something during the ./configure if > python < 2.2 is used? IMHO, it should not even compile the plugin in that case. (Not too good to have a plugin that fails for some (random) functions/scripts.) I did not find an acceptable solution yet. My possible alternatives would be: 1. Just check the Python version and reject versions below 2.2. This alternative would be very easy to implement, but I'm not sure if that would be the right way to go: the Python documentation (version 2.3) says: | "L" (integer) [PY_LONG_LONG] | | Convert a Python integer to a C long long. This format is only | available on platforms that support long long (or _int64 on | Windows). Therefore it may be possible that this format specifier is not available even if the Python version is >=2.2. 2. Add a (compile-time) check to the configure script: run a small test-program to check if the "L" format specifier is supported. I did implement this alternative, but then realized that it would prevent cross-compiling: you just can't check the Python version of the target system while compiling on the host system. 3. Add a (runtime) check to the server: try to use the "L" format specifier when the plugin loads and fail if it is not supported. Problems here is that it would add some complexity to the plugin just to fail in some cases and that it fails not until runtime. My preferred solution would be both alternatives 1 and 3: compile-time check for Python >=2.2 and runtime check for working "L" format specifier. > The slots don't work either - perhaps same reason. I think so: they are using money, too? From kirschbaum at myrealbox.com Thu Jan 20 16:23:19 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Jan 20 16:37:19 2005 Subject: [crossfire] Re: [CF-Devel] Missing archetypes used by python plugin In-Reply-To: <41C75454.2000205@sympatico.ca> References: <20041018175104.GA30872@idefix2.dvlp.in-medias-res.com> <20041018180424.GB25816@laranja.org> <20041220205332.GA18213@idefix2.dvlp.in-medias-res.com> <41C75454.2000205@sympatico.ca> Message-ID: <20050120222319.GB17834@idefix2.dvlp.in-medias-res.com> Todd Mitchell wrote: > Another big thing along the same lines would be to clean up the spell > and skill stuff... I don't know how the spell and skill wrappers can > be loaded into the plugin any longer now that they are dynamically > loaded from the arches, but this is a lot of legacy code in the > plugin. The solution to the skill stuff could be to remove the SkillXxx() wrapper functions and to convert skill ids into skill names: GetSkillExperience(object who, string skill) SetSkillExperience(object who, string skill, long exp) You could use these functions as follows: who = CFPython.WhoIsActivator() exp = CFPython.GetSkillExperience(who, "alchemy") if exp != None: CFPython.SetSkillExperience(who, "alchemy", exp+1) else: CFPython.Write("You do not know how to do alchemy!", who) For the spell related functions, the following code did work for me: who = CFPython.WhoIsActivator() # learn a spell spell = CFPython.CreateObject("spell_large_fireball", (0, 0)) CFPython.AcquireSpell(who, spell) CFPython.RemoveObject(spell) # forget a spell CFPython.ForgetSpell(who, "large fireball") Note: I had to create the spell object with CreateObject() at the (arbitrary) position (0, 0) because I could not find a function to create a (spell-)object that is not part of a map (and not inside an inventory). That said, I think the spell wrapper functions are not needed anymore and could be removed. From mwedel at sonic.net Fri Jan 21 02:41:14 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jan 21 02:42:16 2005 Subject: [crossfire] door bug In-Reply-To: <41EFCEE9.2000508@sympatico.ca> References: <1106229592.7177.2.camel@myth.crowcastle.com> <41EFCEE9.2000508@sympatico.ca> Message-ID: <41F0C02A.8080803@sonic.net> Todd Mitchell wrote: > I don't think it's a bug but a map making error... > I don't think there is an arch for these - they are just modified doors > - the solution would be to search through the maps and look for doors > with the no_ pass setting changed to 0 and remove their treasurelists. > Maybe they should have their own arch and different images which people > can be encouraged to use (except for special cases). The passable doors being trapped is a bug in the map, and not the code - the code is doing the right thing and putting treasure in objects that have treasurelists (in short, I agree with Todd's assessment above). The monster death destroying a door it stands on seems odd to me - I don't see why that would happen. I think there may be some oddity in the attack code for monsters - at one point, they would attack such non passable doors, destroying them, because the code was just looking to see if the object type was a door, and not that it blocked passage. It could be something similar as to why they are being destroyed. > > > Preston Crow wrote: > >> A few minor bugs with unlocked doors (the ones that look like normal >> doors, but you can walk through them). >> >> * They have traps just as often as normal doors, but they can only be >> set off when trying to disarm them. >> >> * If you kill a monster standing on the same square as the door, you >> destroy the door (and set off any trap, I think). >> >> >> > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Fri Jan 21 03:01:11 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jan 21 03:02:16 2005 Subject: [crossfire] exploding MOBs In-Reply-To: <41EFE86F.2000805@sympatico.ca> References: <41EFD124.3070305@sympatico.ca> <41EFD68A.1050500@laposte.net> <41EFE86F.2000805@sympatico.ca> Message-ID: <41F0C4D7.3050602@sonic.net> Todd Mitchell wrote: > Well you can put arches into inventory now - so you can already for > example spawn a couple guards or fireballs or something when a MOB is > destroyed. I was thinking of a will_explode and explode_attacktype > flags where if will_explode = 1, it produces a little pop graphic and > deals out damage from attacktype (or explode_attacktype if it's not 0). Putting fireballs in the inventory is less likely to work, because of the timing - to get them to blow up after the monster dies, not before and not a long time after, is more complicated. Of course, I'd think exploding monsters could also be done via script (hook into the death event of the monster). When the monster dies, death event is called, which basically just creates some objects specified wherever the monster died. That still has some problem in that you could only use standard archetypes for those objects (this is actually one problem with using other_arch also - you can't customize the object, which with the spell code, is pretty important - taking just the firebullet arch (or whatever) and putting it in a map won't do much at all). The scripts could in theory be more clever, by looking at the objects in the now deceased monster, and if those objects have some flag set, it knows to use those objects as the explosion objects (remove from inventory, update the speed/speed_left so they blow up immediately, insert onto map). Script could look either at nrof field for number to insert, or find number of objects in inventory with unique flag (value) set. I'm uncertain how often such functionality would end up being used - there are lots of cool things that can be envisioned, but at some level, for things that don't happen a lot, using scripts may be the way to go instead of trying to C code all these possible events. OTOH, an intermediate approach could make sense - something like built in basic script hooks that don't require external python scripts. For example, you could keep all the current script hooks (death, apply, whatever). You could then have another set of basic script actions (insert onto map, remove object, change value, identify, etc). These actions could then take some number of optional paremeters. Thus, you could have something like: event_apply_plugin Builtin event_apply Change_Value, -1 (which would decrease the value of the object by 1 each time it is applied). Or in this case, could be something like: event_death_plugin Builtin event_death insert_spell_from_inventory_to_map, fireball The advantage of doing this via builtin scripts is that it allows more flexibility (was mentiond to do this would require something like FLAG_INSERT_AT_DEATH) - the problem is that you would need a whole bunch of flags to cover all the possiblities (death, apply, etc). The other problem is that there are not always available fields. For example, other_arch was mentioned as a field to use. One problem there is that other_arch is used by some monsters for what they turn into/generate, which then means you can't have those monsters explode. The advantage of builtin scripts (vs the external python) is twofold - builtin scripts would basically always be available (nothing external required - not even dynamic linking), and performance shoudl also be better. My understanding right now is that whenever a python script is loaded, it will read the python script from disk - granted good OS's will cache the file, but I imagined there is certainly more overhead in loading that file, parsing it, and handling the conversion of the C structures to something that is usuable in python. All that said, builtin scripts (which is a bit of a misnomer in fact, since they are not scripts) would largely cover the most basic and common things that need to be done. But the builtin method has the nice advantage of being able to take those optional parameters and thus be quite flexible in what it can do - can specify those different objects to insert instead of trying to find free files to put them into in the object structure. From erhard.sanio at gmx.net Fri Jan 21 06:50:08 2005 From: erhard.sanio at gmx.net (Erhard Sanio) Date: Fri Jan 21 06:52:16 2005 Subject: Please remove me from the list was Re: [crossfire] material type issue References: <20050120223313.GD17834@idefix2.dvlp.in-medias-res.com> Message-ID: <24312.1106311808@www13.gmx.net> Hello, For reasons beyond my influence, metalforge.org is blocking connections from the German provider t-online. Therefore I asked to remove me from the mailing list years ago. That seemed to have worked for a while, but now, mailing list traffic reaches my mailbox, again. Due to blocking of http connects, I am unable to reach the mailing list over the web, thus cannot contact the administrator. Please help me to get out of the list, an all the best for you all. sincerely, e.sanio -- Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl From temitchell at sympatico.ca Fri Jan 21 09:49:41 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Fri Jan 21 09:58:47 2005 Subject: [crossfire] exploding MOBs In-Reply-To: <41F0C4D7.3050602@sonic.net> References: <41EFD124.3070305@sympatico.ca> <41EFD68A.1050500@laposte.net> <41EFE86F.2000805@sympatico.ca> <41F0C4D7.3050602@sonic.net> Message-ID: <41F12495.6010900@sympatico.ca> What I should have said is "you can put arches into inventory now, BUT WHAT I was thinking of IS adding will_explode and explode_attacktype flags... I was just going to add two new flags and change the death realted code to pop up a explosion graphic and deal up some damage when the creature dies. Nothing too fancy involving arches or scripts. I just thought that exploding beasties would be quite useful and would encourage more ranged combat and more novel combat strategies (You encounter a pack of terrible Ogger Kobolds. They try to swarm you - you don't want to fight back or they might go off in a chain reaction.. you try to use your windstorm spell to push them away... oh no! your party mate fires an arrow into the pack and it's all over - boom!) Maybe it can be done in the plugin however. Mark Wedel wrote: > Todd Mitchell wrote: > >> Well you can put arches into inventory now - so you can already for >> example spawn a couple guards or fireballs or something when a MOB is >> destroyed. I was thinking of a will_explode and explode_attacktype >> flags where if will_explode = 1, it produces a little pop graphic and >> deals out damage from attacktype (or explode_attacktype if it's not 0). > > > Putting fireballs in the inventory is less likely to work, because of > the timing - to get them to blow up after the monster dies, not before > and not a long time after, is more complicated. > > Of course, I'd think exploding monsters could also be done via script > (hook into the death event of the monster). When the monster dies, > death event is called, which basically just creates some objects > specified wherever the monster died. > ... From leaf at real-time.com Fri Jan 21 10:24:35 2005 From: leaf at real-time.com (Rick Tanner) Date: Fri Jan 21 10:27:19 2005 Subject: [crossfire] [OT] Reminder: ways to unsubsribe from the mailing list Message-ID: For those who wish to unsubscribe from the list for one reason or another, select any one of the following: Send email to crossfire-owner@metalforge.org and ask to be removed (Notice the "-owner" in the address, and it's helpful if you send the email from the subscribed address or indicate which address you want to unsubscribe) Visit and follow the instructions here: http://shadowknight.real-time.com/mailman/listinfo/crossfire Send an email to crossfire-request@metalforge.org -AND- make sure to use the word "unsubscribe" (whithout the quotes) as the subject (Note: this will only work if you email from the subscribed adress; if that's not possible, then use one of the methods mentioned above) Thanks. -- From leaf at real-time.com Fri Jan 21 10:26:50 2005 From: leaf at real-time.com (Rick Tanner) Date: Fri Jan 21 10:30:43 2005 Subject: List (cf-list and cf-devel) merger, was Re: [crossfire] exploding MOBs In-Reply-To: <41EFD124.3070305@sympatico.ca> References: <41EFD124.3070305@sympatico.ca> Message-ID: On Thu, 20 Jan 2005, Todd Mitchell wrote: > Is this crossfire discussion list for dev or crossfire in general - or > have those two lists been merged into one list? The lists were merged as the only traffic on the general list (cf-list) in the past 7 or 8+ months was cross posts from cf-devel. From mwedel at sonic.net Sat Jan 22 02:40:25 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jan 22 02:47:27 2005 Subject: [crossfire] exploding MOBs In-Reply-To: <41F12495.6010900@sympatico.ca> References: <41EFD124.3070305@sympatico.ca> <41EFD68A.1050500@laposte.net> <41EFE86F.2000805@sympatico.ca> <41F0C4D7.3050602@sonic.net> <41F12495.6010900@sympatico.ca> Message-ID: <41F21179.3090001@sonic.net> Todd Mitchell wrote: > What I should have said is "you can put arches into inventory now, BUT > WHAT I was thinking of IS adding will_explode and explode_attacktype > flags... Not sure what you mean by exploed_attacktype flag. You could certainly have an EXPLODE attacktype, but that doesn't seem quite right - it isn't really an attacktype, but rather an action of something that happens after death (there are some attacktypes currently that are more effects than real attacktypes, and I personally don't really like those, but they are left over for historical reasons - I'm mostly thinking about ghosthit, which says the monster disappears after hitting something, and chaos, which isn't an attacktype, but causes the attacktypes it has to get shuffled) If you mean some way to store the attacktype of the explosion, that gets more difficult - flags are just binary values (1/0), so are unable to hold the entire attacktype. > > I was just going to add two new flags and change the death realted code > to pop up a explosion graphic and deal up some damage when the creature > dies. Nothing too fancy involving arches or scripts. I just thought > that exploding beasties would be quite useful and would encourage more > ranged combat and more novel combat strategies (You encounter a pack of > terrible Ogger Kobolds. They try to swarm you - you don't want to fight > back or they might go off in a chain reaction.. you try to use your > windstorm spell to push them away... oh no! your party mate fires an > arrow into the pack and it's all over - boom!) The real problem is there are a fair amount of limitation with the above method: How much damage does the explosion of the creature do (by default, it would either have to be hardcode, or derived by how much the creature does by itself) - that is to say, difficult to customize. What attacktype does the explosion do - once again, easy to make a default, but one could see different things (think of old gas spore monster for AD&D, which should really be poison, but one could certain envision other creatuers having fire or cold or whatever attacktypes. How big is the explosion? If only 1 space, not all that meaningful, so a 3x3 is probably mininum. But do you want to allow larger explosions, etc. I certainly don't mean to say that your method won't work. I'm just trying to envision the longer term of what people may want from the feature, and whether the proposed implementation will match that. It may not make a lot of sense to write code that basically gets thrown out a little while later because it doesn't meet possible needs. However, perhaps I'm just being overly sensitive, because at one point there was an item on the TODO list to have an item turn into something else when destroyed, so have a more abstract way of doing that would be nice. Real examples I could think where that would be 'cute' is something like chickens getting hit by fire turning into roast birds for exmaple. I'm sure there are other examples of things like this happening. My other point, which went way beyond the start of the discussion, is it would be nice to have some ability to include more arbitrary but not often used values. Right now, the object structure has a field for every value that may ever be set - the problem this leads to is that if you want to add a new variable, you need to add a new field, update the loader/saver, possibly merge logic and other things. And increase the object structure by some number of bytes for something that may not be frequently used. That is sort of where the idea of 'builtin' plugins comes from - the built in plugin can basically take a list of string options for additional information, which then makes it much easier to customize values. But that is really a different discussion. From mwedel at sonic.net Sat Jan 22 02:47:28 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jan 22 02:52:26 2005 Subject: [crossfire] material type issue In-Reply-To: <20050120223313.GD17834@idefix2.dvlp.in-medias-res.com> References: <1106096110.5133.14.camel@myth.crowcastle.com> <20050120223313.GD17834@idefix2.dvlp.in-medias-res.com> Message-ID: <41F21320.5060000@sonic.net> Andreas Kirschbaum wrote: >>I've noticed that if I buy a bunch of stuff from a table (like >>alchemical elements), they don't have a material type, but if I leave >>them in my apartment and come back after the map has been saved, the >>material type is set. This means that newly-bought items don't merge >>with older items (and they're indestructible). >> >>Is this something that is easily fixed? > > > I had the same problem while checking the Python plugin. The attached > patch fixed the problem for me, but I don't know if using a fixed > difficulty (5) is correct. I don't think modifying the arch_to_object function is really the right approach. IMO, the arch_to_object function should really just do the basic 'make an object out of this arch' - it should do other customizations. I'd make the case that it is the convert_item() function that should make that call, probably in fact calling fix_generated_item(). Adding a call to fix_generated_item() should also mean healing potions generated by tables would then work, as fix_generated_item() would then do the work of processing its treasure list and putting the correct spell object in it. > > > ------------------------------------------------------------------------ > > Index: common/arch.c > =================================================================== > RCS file: /cvsroot/crossfire/crossfire/common/arch.c,v > retrieving revision 1.29 > diff -w -c -5 -r1.29 arch.c > *** common/arch.c 27 Oct 2003 07:24:13 -0000 1.29 > --- common/arch.c 20 Jan 2005 22:30:37 -0000 > *************** > *** 571,580 **** > --- 571,581 ---- > return NULL; > } > op=get_object(); > copy_object(&at->clone,op); > op->arch=at; > + set_materialname(op, 5, NULL); > return op; > } > > /* > * Creates an object. This function is called by get_archetype() > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Sat Jan 22 02:50:57 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jan 22 02:52:30 2005 Subject: [crossfire] some bugs In-Reply-To: <1106195794.5396.20.camel@oberon.kameria> References: <1106195794.5396.20.camel@oberon.kameria> Message-ID: <41F213F1.8020709@sonic.net> Todd Mitchell wrote: > Haven't had much time to test for the upcoming release but I did pull > latest CVS of the server out and did a fresh install - some things I > found: > > 1. cannot install server without linking arch dir in the crossfire/lib > and > letting it do a collect (CVS debian woody) This is a packaging issue/CVS timing issue. The Makefile does the right thing and looks at the datestamps of different files to figure out if it needs to run a collect. However, for that to work, files have to be created in a specific order. If you just do a 'cvs checkout', it doesn't create the files in the correct order (there is in fact, no easy way to fix that). However, when the official releases are made in tar format, the order the files are put into the archive (and thus, order they are extracted in) is very specific, and thus it doesn't try to rebuild the archtypes. From mikeeusaaa at yahoo.com Sat Jan 22 14:59:58 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Jan 22 15:02:29 2005 Subject: [crossfire] [OT] Reminder: ways to unsubsribe from the mailing list In-Reply-To: Message-ID: <20050122205958.14888.qmail@web61008.mail.yahoo.com> Wy would anyone want to unsubscribe? Also ... we need to advertise crossfire more and perhapse bundle gtk with the win crossfire. --- Rick Tanner wrote: > > For those who wish to unsubscribe from the list for > one reason or > another, select any one of the following: > > Send email to crossfire-owner@metalforge.org and ask > to be removed > (Notice the "-owner" in the address, and it's > helpful if you send the > email from the subscribed address or indicate which > address you want to > unsubscribe) > > Visit and follow the instructions here: > http://shadowknight.real-time.com/mailman/listinfo/crossfire > > Send an email to crossfire-request@metalforge.org > -AND- make sure to use the word "unsubscribe" > (whithout the quotes) as > the subject (Note: this will only work if you email > from the subscribed > adress; if that's not possible, then use one of the > methods mentioned > above) > > Thanks. > > -- > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From rbrockway at opentrend.net Sat Jan 22 15:08:23 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Sat Jan 22 15:15:47 2005 Subject: [crossfire] [OT] Reminder: ways to unsubsribe from the mailing list In-Reply-To: <20050122205958.14888.qmail@web61008.mail.yahoo.com> References: <20050122205958.14888.qmail@web61008.mail.yahoo.com> Message-ID: <20050122210703.P86934@nirmala.opentrend.net> On Sat, 22 Jan 2005, Mitch Obrian wrote: > Wy would anyone want to unsubscribe? Well I'm on here with 2 different addresses. I should remove the other one :) > Also ... we need to advertise crossfire more and > perhapse bundle gtk with the win crossfire. I've done talks on Crossfire at LUG meetings (not all LUG talks need to be serious) and each time several people have started playing. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (www.spi-inc.org) From mikeeusaaa at yahoo.com Sat Jan 22 17:13:33 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Jan 22 17:17:31 2005 Subject: [crossfire] Telnet support In-Reply-To: <41F213F1.8020709@sonic.net> Message-ID: <20050122231333.29681.qmail@web61005.mail.yahoo.com> Was wondering if telnet support in the crossfire server could be revialised, or perhapse even code nethack-like telnet support into the server so players who like such styles can connect and play that way? It could all be done through telnet. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rbrockway at opentrend.net Sat Jan 22 18:28:10 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Sat Jan 22 18:37:30 2005 Subject: [crossfire] Telnet support In-Reply-To: <20050122231333.29681.qmail@web61005.mail.yahoo.com> References: <20050122231333.29681.qmail@web61005.mail.yahoo.com> Message-ID: <20050123002737.C86934@nirmala.opentrend.net> On Sat, 22 Jan 2005, Mitch Obrian wrote: > Was wondering if telnet support in the crossfire > server could be revialised, or perhapse even code > nethack-like telnet support into the server so players > who like such styles can connect and play that way? It > could all be done through telnet. I liked the old ability to telnet to a particular port and talk to people playing on the server. That was cool :) Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (www.spi-inc.org) From mikeeusaaa at yahoo.com Sat Jan 22 18:52:58 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Jan 22 18:57:31 2005 Subject: [crossfire] Telnet support In-Reply-To: <20050123002737.C86934@nirmala.opentrend.net> Message-ID: <20050123005258.68682.qmail@web61004.mail.yahoo.com> Id like the ability to telnet to a paticular port and play crossfire nethack style (perhapse with 3x3 tiles rather than 1x1 ascii tiles) we have 16x16 (forground and background) color combos to use... acc 1x1 ascii tiles would be cool to (whichever..)... also maby put in another port to play it like a MUD. This way we'd get more players as people have specific ways they like to play. Nethack style port would be awome because then people could play while in my shell server :D. --- Robert Brockway wrote: > On Sat, 22 Jan 2005, Mitch Obrian wrote: > > > Was wondering if telnet support in the crossfire > > server could be revialised, or perhapse even code > > nethack-like telnet support into the server so > players > > who like such styles can connect and play that > way? It > > could all be done through telnet. > > I liked the old ability to telnet to a particular > port and talk to people > playing on the server. That was cool :) > > Rob > > -- > Robert Brockway B.Sc. > Senior Technical Consultant, OpenTrend Solutions > Ltd. > Phone: 416-669-3073 Email: rbrockway@opentrend.net > http://www.opentrend.net > OpenTrend Solutions: Reliable, secure solutions to > real world problems. > Contributing Member of Software in the Public > Interest (www.spi-inc.org) > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com From mwedel at sonic.net Sat Jan 22 22:41:49 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jan 22 22:47:33 2005 Subject: [crossfire] Telnet support In-Reply-To: <20050123005258.68682.qmail@web61004.mail.yahoo.com> References: <20050123005258.68682.qmail@web61004.mail.yahoo.com> Message-ID: <41F32B0D.5000004@sonic.net> Mitch Obrian wrote: > Id like the ability to telnet to a paticular port and > play crossfire nethack style (perhapse with 3x3 tiles > rather than 1x1 ascii tiles) we have 16x16 (forground > and background) color combos to use... acc 1x1 ascii > tiles would be cool to (whichever..)... also maby put > in another port to play it like a MUD. This way we'd > get more players as people have specific ways they > like to play. Nethack style port would be awome > because then people could play while in my shell > server :D. What you describe above is an ASCII based client. If you want one, go and make one. I think for a lot of reasons, development of ASCII clients hasn't gone much of anywhere. It is fairly tricky, because there are thousands of graphics in crossfire, so trying to find ascii codes to show them is very difficult. No way will that code ever be in the server - first, as said, it is a client issue. It is also a step backwards (From client/server we currently have). It also adds a lot of complication and adds new dependencies that the server does not have. Now, if it is too much a bother for players to install an ascii client (if one was ever developed), a site could certainly have the ascii client get launched when someone connects to a specific port. The client would then connect to whatever server (it wouldn't be hard to make it such that a client is hard bound to a specific server, such as the one running on the same machine). In terms of the 'old' telnet support, that is still there. Just connect to port 13327, and type 'oldsocketmode'. You can then do the various old commands. > > --- Robert Brockway wrote: > > >>On Sat, 22 Jan 2005, Mitch Obrian wrote: >> >> >>>Was wondering if telnet support in the crossfire >>>server could be revialised, or perhapse even code >>>nethack-like telnet support into the server so >> >>players >> >>>who like such styles can connect and play that >> >>way? It >> >>>could all be done through telnet. >> >>I liked the old ability to telnet to a particular >>port and talk to people >>playing on the server. That was cool :) >> >>Rob >> >>-- >>Robert Brockway B.Sc. >>Senior Technical Consultant, OpenTrend Solutions >>Ltd. >>Phone: 416-669-3073 Email: rbrockway@opentrend.net >>http://www.opentrend.net >>OpenTrend Solutions: Reliable, secure solutions to >>real world problems. >>Contributing Member of Software in the Public >>Interest (www.spi-inc.org) >> >>_______________________________________________ >>crossfire mailing list >>crossfire@metalforge.org >> > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > __________________________________ > Do you Yahoo!? > The all-new My Yahoo! - What will yours do? > http://my.yahoo.com > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mikeeusaaa at yahoo.com Sat Jan 22 22:59:25 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Jan 22 23:00:23 2005 Subject: [crossfire] Telnet support In-Reply-To: <41F32B0D.5000004@sonic.net> Message-ID: <20050123045925.86382.qmail@web61005.mail.yahoo.com> Why always the "go and do it yourself" answer? --- Mark Wedel wrote: > Mitch Obrian wrote: > > Id like the ability to telnet to a paticular port > and > > play crossfire nethack style (perhapse with 3x3 > tiles > > rather than 1x1 ascii tiles) we have 16x16 > (forground > > and background) color combos to use... acc 1x1 > ascii > > tiles would be cool to (whichever..)... also maby > put > > in another port to play it like a MUD. This way > we'd > > get more players as people have specific ways they > > like to play. Nethack style port would be awome > > because then people could play while in my shell > > server :D. > > What you describe above is an ASCII based client. > If you want one, go and > make one. > > I think for a lot of reasons, development of ASCII > clients hasn't gone much of > anywhere. It is fairly tricky, because there are > thousands of graphics in > crossfire, so trying to find ascii codes to show > them is very difficult. > > No way will that code ever be in the server - > first, as said, it is a client > issue. It is also a step backwards (From > client/server we currently have). It > also adds a lot of complication and adds new > dependencies that the server does > not have. > > Now, if it is too much a bother for players to > install an ascii client (if one > was ever developed), a site could certainly have the > ascii client get launched > when someone connects to a specific port. The > client would then connect to > whatever server (it wouldn't be hard to make it such > that a client is hard bound > to a specific server, such as the one running on the > same machine). > > In terms of the 'old' telnet support, that is > still there. Just connect to > port 13327, and type 'oldsocketmode'. You can then > do the various old commands. > > > > > > --- Robert Brockway > wrote: > > > > > >>On Sat, 22 Jan 2005, Mitch Obrian wrote: > >> > >> > >>>Was wondering if telnet support in the crossfire > >>>server could be revialised, or perhapse even code > >>>nethack-like telnet support into the server so > >> > >>players > >> > >>>who like such styles can connect and play that > >> > >>way? It > >> > >>>could all be done through telnet. > >> > >>I liked the old ability to telnet to a particular > >>port and talk to people > >>playing on the server. That was cool :) > >> > >>Rob > >> > >>-- > >>Robert Brockway B.Sc. > >>Senior Technical Consultant, OpenTrend Solutions > >>Ltd. > >>Phone: 416-669-3073 Email: rbrockway@opentrend.net > >>http://www.opentrend.net > >>OpenTrend Solutions: Reliable, secure solutions to > >>real world problems. > >>Contributing Member of Software in the Public > >>Interest (www.spi-inc.org) > >> > >>_______________________________________________ > >>crossfire mailing list > >>crossfire@metalforge.org > >> > > > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > > > > > > __________________________________ > > Do you Yahoo!? > > The all-new My Yahoo! - What will yours do? > > http://my.yahoo.com > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From mwedel at sonic.net Sun Jan 23 00:02:56 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jan 23 00:07:32 2005 Subject: [crossfire] Telnet support In-Reply-To: <20050123045925.86382.qmail@web61005.mail.yahoo.com> References: <20050123045925.86382.qmail@web61005.mail.yahoo.com> Message-ID: <41F33E10.9050100@sonic.net> Mitch Obrian wrote: > Why always the "go and do it yourself" answer? If you want something done, do it yourself? :) But the issue, which has been discussed, is that crossfire is a volunteer project. As such, most people that are going to work on it are going to do things they find interesting. Perhaps you can find a developer that will find writing an ASCII client interesting. I, however, am not that developer, so I won't be writing one. In fact, even fixing bugs is something that I don't find interesting to do - I'd much rather spend my time working on 'grander' aspects of programming for the game. But at some level, one has to do some of the more mundane work - doing only cool stuff but never fixing bugs would probably result in a program that has tons of bells and whistles but crashes every 5 minutes. Also, there has never been a pure only text client that I am aware of in the entire history of crossfire. So it is not like this is functionality that disappeared - this is new functionality that needed (the telnet interface that used to exist basically still exists - it never allowed one to play the game, it is just back in way back times, you needed to connect via telnet to tell the server to display the X11 client back to your display. But once you did that, it was still graphical. So writing a ASCII client/interface is not just a trivial amount of work - I'd say it would actually take quite a bit of work. The other issue is the related demand/usefulness. Most developers, myself included, are more willing to write code that will be used by a bunch of people and not a few. I just have a hard time believing that lots of people are clamoring for a ASCII client. It's not like there are likely many systems that don't have sufficient graphics to play the game. From rbrockway at opentrend.net Sat Jan 22 23:56:55 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Sun Jan 23 00:07:37 2005 Subject: [crossfire] Telnet support In-Reply-To: <20050123045925.86382.qmail@web61005.mail.yahoo.com> References: <20050123045925.86382.qmail@web61005.mail.yahoo.com> Message-ID: <20050123055439.O86934@nirmala.opentrend.net> On Sat, 22 Jan 2005, Mitch Obrian wrote: > Why always the "go and do it yourself" answer? Because this is a volunteer OSS effort. You are the one who sees the need. The great thing about OSS is you can go ahead and fulfil the need and offer the code to others to enjoy also. You may find that if you start a CLI client project that other coders may join you to share the work, or they may not. It depends on who feels there is a need. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (www.spi-inc.org) From mikeeusaaa at yahoo.com Sun Jan 23 12:40:56 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Jan 23 12:42:38 2005 Subject: [crossfire] Telnet support In-Reply-To: <41F33E10.9050100@sonic.net> Message-ID: <20050123184056.6935.qmail@web61010.mail.yahoo.com> I inquired because MUDers I've talked to don't like to play crossfire because there is no text mudlike iface... then I started talking about a nethack like interface because ... well that's the text type thing I'd like :) (MUD is not graphical enough for me). I was thinking that since crossfire allready spits out mud like things (you killed the knight) perhapse a mud telnet iface could be coded in so CFservers could pick up Text MUD players (this type of Iface wouldn't need the tiles). --- Mark Wedel wrote: > Mitch Obrian wrote: > > Why always the "go and do it yourself" answer? > > If you want something done, do it yourself? :) > > But the issue, which has been discussed, is that > crossfire is a volunteer project. > > As such, most people that are going to work on it > are going to do things they > find interesting. Perhaps you can find a developer > that will find writing an > ASCII client interesting. I, however, am not that > developer, so I won't be > writing one. > > In fact, even fixing bugs is something that I > don't find interesting to do - > I'd much rather spend my time working on 'grander' > aspects of programming for > the game. But at some level, one has to do some of > the more mundane work - > doing only cool stuff but never fixing bugs would > probably result in a program > that has tons of bells and whistles but crashes > every 5 minutes. > > Also, there has never been a pure only text client > that I am aware of in the > entire history of crossfire. So it is not like this > is functionality that > disappeared - this is new functionality that needed > (the telnet interface that > used to exist basically still exists - it never > allowed one to play the game, it > is just back in way back times, you needed to > connect via telnet to tell the > server to display the X11 client back to your > display. But once you did that, > it was still graphical. > > So writing a ASCII client/interface is not just a > trivial amount of work - I'd > say it would actually take quite a bit of work. > > The other issue is the related demand/usefulness. > Most developers, myself > included, are more willing to write code that will > be used by a bunch of people > and not a few. I just have a hard time believing > that lots of people are > clamoring for a ASCII client. It's not like there > are likely many systems that > don't have sufficient graphics to play the game. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mikeeusaaa at yahoo.com Sun Jan 23 12:46:38 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Jan 23 12:52:38 2005 Subject: [crossfire] [OT] Reminder: ways to unsubsribe from the mailing list In-Reply-To: <20050122210703.P86934@nirmala.opentrend.net> Message-ID: <20050123184638.7704.qmail@web61010.mail.yahoo.com> If I had 2 mailboxes I, for one, would be thrilled to beable to read wonderfull crossfire mail twice. --- Robert Brockway wrote: > On Sat, 22 Jan 2005, Mitch Obrian wrote: > > > Wy would anyone want to unsubscribe? > > Well I'm on here with 2 different addresses. I > should remove the other > one :) > > > Also ... we need to advertise crossfire more and > > perhapse bundle gtk with the win crossfire. > > I've done talks on Crossfire at LUG meetings (not > all LUG talks need to be > serious) and each time several people have started > playing. > > Rob > > -- > Robert Brockway B.Sc. > Senior Technical Consultant, OpenTrend Solutions > Ltd. > Phone: 416-669-3073 Email: rbrockway@opentrend.net > http://www.opentrend.net > OpenTrend Solutions: Reliable, secure solutions to > real world problems. > Contributing Member of Software in the Public > Interest (www.spi-inc.org) > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bofh-lists-crossfire-dev at diegeekdie.com Mon Jan 24 02:00:47 2005 From: bofh-lists-crossfire-dev at diegeekdie.com (Sebastian Andersson) Date: Mon Jan 24 02:02:45 2005 Subject: [crossfire] Telnet support In-Reply-To: <20050123184056.6935.qmail@web61010.mail.yahoo.com> References: <41F33E10.9050100@sonic.net> <20050123184056.6935.qmail@web61010.mail.yahoo.com> Message-ID: <20050124080046.GD17511@hogia.net> On Sun, Jan 23, 2005 at 10:40:56AM -0800, Mitch Obrian wrote: > I inquired because MUDers I've talked to don't like to > play crossfire because there is no text mudlike > iface... If they want to play a mud, why not play an existing mud, designed and polished for its text interface for years? There are plenty of muds around that have the same kind of gameplay as crossfire already, there is no need for another one. > then I started talking about a nethack like > interface because ... well that's the text type thing > I'd like :) (MUD is not graphical enough for me). I If you want a realtime, text based, rogue-like game, there are a few. RCH2 for example (http://rch2.mine.nu). There is currently no public server, but if you are interested in advertising for players, writing maps, tutorials and/or designing new, cool things for it, let me know and I'll start up a server for you (or get the existing one up again). /Sebastian -- .oooO o,o Oooo. ( ) \_/ ( ) (o_ "Life is not fair, but root \ ( /|\ ) / (o_ //\ password helps!" -- The BOFH \_) (_/ (/)_ V_/_ From temitchell at sympatico.ca Mon Jan 24 08:57:17 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Mon Jan 24 09:02:46 2005 Subject: [crossfire] Telnet support In-Reply-To: <20050124080046.GD17511@hogia.net> References: <41F33E10.9050100@sonic.net> <20050123184056.6935.qmail@web61010.mail.yahoo.com> <20050124080046.GD17511@hogia.net> Message-ID: <41F50CCD.1050005@sympatico.ca> Not interested in a telnet client but it would be neat/useful if someone developed something for DMs to be able to login and monitor the server - listen in, speak to players, kick/banish players, and reset maps or whatnot. From rbrockway at opentrend.net Mon Jan 24 09:42:45 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Mon Jan 24 09:52:52 2005 Subject: [crossfire] Telnet support In-Reply-To: <41F50CCD.1050005@sympatico.ca> References: <41F33E10.9050100@sonic.net> <20050123184056.6935.qmail@web61010.mail.yahoo.com> <20050124080046.GD17511@hogia.net> <41F50CCD.1050005@sympatico.ca> Message-ID: <20050124153603.X86934@nirmala.opentrend.net> On Mon, 24 Jan 2005, Todd Mitchell wrote: > Not interested in a telnet client but it would be neat/useful if someone > developed something for DMs to be able to login and monitor the server - > listen in, speak to players, kick/banish players, and reset maps or whatnot. As noted by Mark recently the old capability to talk via telnet is still in the server. This article from the list archive lists some commands: http://archives.metalforge.org/pipermail/crossfire/2001-April/004839.html Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. Contributing Member of Software in the Public Interest (www.spi-inc.org) From mikeeusaaa at yahoo.com Mon Jan 24 11:20:10 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Mon Jan 24 11:26:09 2005 Subject: [crossfire] Telnet support In-Reply-To: <41F50CCD.1050005@sympatico.ca> Message-ID: <20050124172010.72037.qmail@web61010.mail.yahoo.com> Yes that would be good... like a crossfire shell right? --- Todd Mitchell wrote: > Not interested in a telnet client but it would be > neat/useful if someone > developed something for DMs to be able to login and > monitor the server - > listen in, speak to players, kick/banish players, > and reset maps or whatnot. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From nicolas.weeger at laposte.net Thu Jan 27 16:04:36 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jan 27 16:08:21 2005 Subject: [crossfire] Re: [CF-Devel] Re: [CF-maps] Mlab maps In-Reply-To: <1105155894.4814.0.camel@lilwoo> References: <41DEFB38.9080603@laposte.net> <1105155894.4814.0.camel@lilwoo> Message-ID: <41F96574.8030901@laposte.net> Joshua Wilson a ?crit : > Salathar did some testing on localhost as he indicated on tracker - I > wont have time to look at them this weekend, but I can try to take a > look Monday at some of them. So, should we put'em in? Ryo From tanner at real-time.com Fri Jan 28 18:37:18 2005 From: tanner at real-time.com (Bob Tanner) Date: Fri Jan 28 18:38:33 2005 Subject: [crossfire] misc.c: raiseChild() problem Message-ID: <20050129003718.GA25901@real-time.com> Debugging a problem where gcfclient was core dumping on a SIGPIPE when playing with sound active. Traced it back to cfsndsrv and misc.c:raiseChild(). Not sure who maintains this code, but the raiseChild function is not catching the error condition when the child exits with a non-zero exit condition. I had the wrong audio device name for linux and cfsndserv.c:init_audio() (listed below) int init_audio() { /* open the PCM device */ if ((err = snd_pcm_open(&handle,AUDIODEV,SND_PCM_STREAM_PLAYBACK,0)) <0) { ALSA9_ERROR("init_audio(): ",err); exit(1); } It seems that a child dieing is detected: [ INFO ] (common::monitorChilds) Child /usr/games/cfsndserv died. Removing and closing pipes But the death of the child isn't communicated/tracked anywhere else, so when play_sound() is invoked it -assumes- the cfsndserv is running. Not familiar enough with the code to determine if I should check if the cfsndserv is alive each time I attempt to play a sound or hack on the raiseChild() or monitorChilds(). -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From leaf at real-time.com Fri Jan 28 22:56:53 2005 From: leaf at real-time.com (Rick Tanner) Date: Fri Jan 28 22:58:34 2005 Subject: [crossfire] Spells & events with no sound? Message-ID: Is is possible that some spells (ex: fireball) and events (ex: player deaths) do not have any sounds associated with them? IIRC, these two examples did at one time. Perhaps the spell school split changed that? Same with any changes to the death code? After some testing and updates, the experimental (debian) client plays sounds for all events that has a sound associated with them. -- From mwedel at sonic.net Sat Jan 29 02:00:30 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jan 29 02:03:35 2005 Subject: [crossfire] Spells & events with no sound? In-Reply-To: References: Message-ID: <41FB429E.9090604@sonic.net> Rick Tanner wrote: > Is is possible that some spells (ex: fireball) and events (ex: player > deaths) do not have any sounds associated with them? > > IIRC, these two examples did at one time. > > Perhaps the spell school split changed that? Same with any changes to the > death code? The spell redo resulted in all the spell sounds basically getting lost. This is because the spell sounds before were hard coded by on spell number. Those spell numbers went away, thus, no way to map spells to sounds on a 1:1 basis. My thought at the time was to wait for the sound redo, which sould 'fix' this problem. The death sound should still be there - it shouldn't have been effected. I do remember that the new player sound, while it exists, wouldn't be played because it was larger than the max sound size allowed. Same might have been true with the death sound. From tchize at myrealbox.com Sun Jan 30 06:00:36 2005 From: tchize at myrealbox.com (tchize) Date: Sun Jan 30 06:03:48 2005 Subject: [crossfire] misc.c: raiseChild() problem In-Reply-To: <20050129003718.GA25901@real-time.com> References: <20050129003718.GA25901@real-time.com> Message-ID: <200501301300.40901.tchize@myrealbox.com> Hello, I did the original code of childs manipulation, raiseChild() being part of it. The first purpose of this code was to handle easily various clientside scripts. However the sound system fitted neatly into it (forking and piping commands). That's for historical point. Now to your problem. Indeed when client quits immediatly, and you want to write to the sound process you get a SIGPIPE. That's a normal behaviour. If you look at the code of play_sound, you see this: if ( (fprintf(sound_pipe,"%4x %4x %4x %4x\n",soundnum,soundtype,x,y)<=0) || (fflush(sound_pipe)!=0) ){ LOG(LOG_ERROR,"gtk::play_sound","couldn't write to sound pipe: %d",errno); use_config[CONFIG_SOUND]=0; fclose(sound_pipe); sound_process=NULL; return; } I did reproduce your sigpipe, having the soundserver do a exit(-1); as first main() instruction. I got this in console: [ INFO ] (common::raiseChild) Raising /tmp/bin/cfsndserv with flags 7 [ INFO ] (common::monitorChilds) Child /tmp/bin/cfsndserv died. Removing and closing pipes [ INFO ] (common::VersionCmd) Playing on server type Crossfire Server [WARNING ] (common::SetupCmd) Server returned FALSE on setup command sexp [ INFO ] (commands.c) addme_success received. [ ERROR ] (gtk::play_sound) couldn't write to sound pipe: 32 As you see, you simply detect the client is dead because the pipe is not working anymore, and that's what the client is doing, setting sound config to off as a result. Whatever, it did not core dump, and client shouldn't core dump on a sigpipe (it's just an information signal, not a critical thing). sigpipe is handled the following way: signal(SIGPIPE, signal_pipe); with void signal_pipe(int i) { /* do nothing, but perhaps do something more in the future */ } so it shouldn't mean a core dump. However, according to you mail, it does core dump. Maybe it core dumps later as a side effect of code. So, i want you to load your core dump into gdb with following command: gdb issue the following command: thread apply all bt and send the result to this mailing list. Also, you may want to fill a bug report on sourceforge so we keep track of problem. Thanks, Le Samedi 29 Janvier 2005 01:37, Bob Tanner a ?crit : Debugging a problem where gcfclient was core dumping on a SIGPIPE when playing with sound active. Traced it back to cfsndsrv and misc.c:raiseChild(). Not sure who maintains this code, but the raiseChild function is not catching the error condition when the child exits with a non-zero exit condition. I had the wrong audio device name for linux and cfsndserv.c:init_audio() (listed below) int init_audio() { /* open the PCM device */ if ((err = snd_pcm_open(&handle,AUDIODEV,SND_PCM_STREAM_PLAYBACK,0)) <0) { ALSA9_ERROR("init_audio(): ",err); exit(1); } It seems that a child dieing is detected: [ INFO ] (common::monitorChilds) Child /usr/games/cfsndserv died. Removing and closing pipes But the death of the child isn't communicated/tracked anywhere else, so when play_sound() is invoked it -assumes- the cfsndserv is running. Not familiar enough with the code to determine if I should check if the cfsndserv is alive each time I attempt to play a sound or hack on the raiseChild() or monitorChilds(). -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050130/2569c7aa/attachment.pgp From tanner at real-time.com Mon Jan 31 18:08:22 2005 From: tanner at real-time.com (Bob Tanner) Date: Mon Jan 31 19:44:01 2005 Subject: [crossfire] misc.c: raiseChild() problem In-Reply-To: <200501301300.40901.tchize@myrealbox.com> References: <20050129003718.GA25901@real-time.com> <200501301300.40901.tchize@myrealbox.com> Message-ID: <200501311808.25083@www.mn-linux.org.or.transmuter.real-time.com> On Sunday 30 January 2005 06:00 am, tchize wrote: > However, according to you mail, it does core dump. Maybe it core dumps > later as a side effect of code. So, i want you to load your core dump into > gdb with following command: > gdb I've fixed the problem, but fixing cfsndserv, the patch for the fix is on my gtk client rel-1-7-0-autoconf-rework branch. The rel-1-7-0 (head) has default sound device as /dev/dsp, I changed that to #define AUDIODEV "plughw:0,0" Prevents the crash, but sounds sound weird now. Haven't looked into that yet. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288