From crossfire-devel at archives.real-time.com Thu Apr 1 13:57:00 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Broken healing potions? Message-ID: This was pointed out to me today on crossfire.metalforge.net server. Healing potions (maybe others, haven't tested..), purchased from regular stores, are broken. The ones that do work were stockpiled in a players apartment, unknown date. See the samples below. Looks like the one potion is missing the associate spell of heal. There you see: - healing potion (98304229). - heal (98304230) 0 - woodfloor (98057999). arch potion_heal name healing potion name_pl healing potions face potionhea.111 sp 35 x 8 y 7 nrof 1 level 1 type 5 material 4 materialname glass value 5200 weight 1800 client_type 651 identified 1 been_applied 1 end There you see: - healing potion (98304145). - woodfloor (98057997). arch potion_heal name healing potion name_pl healing potions face potionhea.111 x 8 y 5 nrof 1 level 1 type 5 material 4 materialname glass value 5200 weight 1800 client_type 651 identified 1 been_applied 1 end _______________________________________________ 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 Apr 1 21:50:11 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Broken healing potions? In-Reply-To: References: Message-ID: <200404012150.11098.eracclists@bellsouth.net> On Thursday 01 April 2004 13:57 Rick Tanner wrote: > This was pointed out to me today on crossfire.metalforge.net > server. [...] > > There you see: > - healing potion (98304145). > - woodfloor (98057997). > > arch potion_heal > name healing potion > name_pl healing potions > face potionhea.111 > x 8 > y 5 > nrof 1 > level 1 > type 5 > material 4 > materialname glass > value 5200 > weight 1800 > client_type 651 > identified 1 > been_applied 1 > expiration sometime before today > end > Oh, I see the problem. It was past the expiration date. :-P Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 21:47:37 up 33 days, 16:42, 10 users, load average: 0.09, 0.05, 0.38 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Apr 2 06:24:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Warning: broken map crashing server Message-ID: <406D5B66.4050404@laposte.net> Hello. It seems one of my commits on Scorn's outdoor maps broke stuff. Apparently the file size is 0. I didn't pay attention to this when committing (I *think* the java editor couldn't save the map due to outta memory conditions, and thus put a zero-byte file). Apparently this is responsible for cf.mf.net being crashy today. I'll fix it tonite if no one does. My modification was to change a hangar on the port side to put a buildable storage guild house. Sorry for that. Nicolas 'Ryo' 'Kaori' _______________________________________________ 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 Apr 2 10:15:42 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Amethyst images and arch In-Reply-To: <4067CDE5.50204@sonic.net> References: <200403261923.55166.d.delbecq@laposte.net> <1080345148.665.29.camel@oberon.kameria> <4067CDE5.50204@sonic.net> Message-ID: <406D91AE.3060601@cox.net> I have attempted a recolor of the jewel to create an amethyst, which I know we lack... Enjoy the fruits my test of the new GIMP 2.0 and I hope it becomes a useful gem A hint on recipies using it: a -methyst means anti-alcohol Since I cannot send zips as SF has blocked them, I will send the link: http://emperorbma.tripod.com/amethyst.zip _______________________________________________ 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 Apr 2 11:06:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Potions and dragon clothes In-Reply-To: <406D91AE.3060601@cox.net> Message-ID: Healing potions AND magic power potions are not working!!! These are very important potions, plesae repair them asap! I know a certain thing that causes crash, and maybe there's more in it than what Ryo wrote, but dunno, so I tell ya: Whenever a new player appears in Scorn, the crash happens _almost_ immedietly. Another thing: Why are dragons so ugly? Why do they wear aprons 'n' stuff? Couldn't they be one-color ones? At least couldn't they chose to be one-color? Xenon _______________________________________________ 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 Apr 2 15:32:06 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_Potions_and_dragon_clothes?= Message-ID: > Healing potions AND magic power potions are not working!!! These are very > important potions, plesae repair them asap! > > I know a certain thing that causes crash, and maybe there's more in it > than what Ryo wrote, but dunno, so I tell ya: > Whenever a new player appears in Scorn, the crash happens _almost_ > immedietly. > > Another thing: Why are dragons so ugly? Why do they wear aprons 'n' stuff? > Couldn't they be one-color ones? At least couldn't they chose to be > one-color? > Dragon players should be red until they get their new colour based on the path they take by eating elemental residues, they don't/shouldn't have any clothes unless someone made a change to the faces that are called. I think the initial colour change for PC dragons called the wrong faces but I fixed this in the arches quite a while ago. tHe proper faces and images for PC dragons is in the player directory naturally. NPC dragons can wear clothing if they like. Unlike a kangaroo, dragons do not have a built in pouch so find a smock useful and others are more modest then some about letting it all hang out. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Fri Apr 2 16:40:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Potions and dragon clothes In-Reply-To: References: Message-ID: <406DEBF0.6090305@cox.net> Todd Mitchell wrote: >NPC dragons can wear clothing if they like. Unlike a kangaroo, dragons do not have a built in pouch so find a smock useful and others are more modest then some about letting it all hang out. > > The fire dragon looks like it is wearing a dress, and the other dragons clothing except the hatchling (none) and green one (none) look silly. In that vein we could say it is better not to lake them look silly... :P _______________________________________________ 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 Apr 3 01:48:20 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Amethyst images and arch In-Reply-To: <406D91AE.3060601@cox.net> References: <200403261923.55166.d.delbecq@laposte.net> <1080345148.665.29.camel@oberon.kameria> <4067CDE5.50204@sonic.net> <406D91AE.3060601@cox.net> Message-ID: <406E6C44.4050208@sonic.net> Brian Angeletti wrote: > I have attempted a recolor of the jewel to create an amethyst, which I > know we lack... > > Enjoy the fruits my test of the new GIMP 2.0 and I hope it becomes a > useful gem > > A hint on recipies using it: a -methyst means anti-alcohol > > Since I cannot send zips as SF has blocked them, I will send the link: > http://emperorbma.tripod.com/amethyst.zip As a note, it is generally more convenient to just attach small files like that unzipped or otherwise unprocessed - makes viewing the data easier. That said, taking a quick look at the images and the arch, it seems fine. But at some point, I do wonder how many different varieties of gems we really need (do we start adding aquamarine? black pearls? topaz, etc?) Looking at the current gems in the game, we have ranges from 50 (1 platinum coin) to 400 (diamond). This ignores the 'of flawless beauty' and the like gems. So that said, I'd think before we start adding every gem we can think of, there should be some compelling reason - recipes, quests, etc. Otherwise, I'd think that at some point, if too many gems are in the game, it would start to become a detriment. _______________________________________________ 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 Apr 3 18:30:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Broken healing potions? In-Reply-To: References: Message-ID: On Thu, 1 Apr 2004, Rick Tanner wrote: > > This was pointed out to me today on crossfire.metalforge.net server. > > Healing potions (maybe others, haven't tested..), purchased from regular > stores, are broken. > > Looks like the one potion is missing the associate > spell of heal. > That is the problem indeed. In fact no potion of healing or magic power generated by a treasurelist (monsterdrop chests etc.) does work. Those two are the only potions using the old method where sp = spell to cast. The map loader (loader.l) parses these values, but the treasure generation in treasure.c does not. So we can either: a.) add the transformation to treasure.c, b.) join these two with the other generic potions. (these are made with artifact code setting the spell in "other arch") This is s possible as there is no treasure list containing only one kind of potion. It does not need any code change either. But in addition to the resource files, about 30 map files need to be changed. or c.) set "other arch" accordingly in the archetypes and get item generator to parse that. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Apr 4 04:32:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:18 2005 Subject: [CF-Devel] Potions and dragon clothes In-Reply-To: <406DEBF0.6090305@cox.net> References: <406DEBF0.6090305@cox.net> Message-ID: <1081071130.592.38.camel@oberon.kameria> On Fri, 2004-04-02 at 22:40, Brian Angeletti wrote: > Todd Mitchell wrote: > > >NPC dragons can wear clothing if they like. Unlike a kangaroo, dragons do not have a built in pouch so find a smock useful and others are more modest then some about letting it all hang out. > > > > > The fire dragon looks like it is wearing a dress, and the other dragons > clothing except the hatchling (none) and green one (none) look silly. > In that vein we could say it is better not to lake them look silly... :P I agree the PC dragons should not have clothing and I made graphics for them accordingly (I think I fixed this in CVS a while ago but it has maybe not made it out to the servers yet) NPC dragons will not have clothing unless the map maker wants to use NPC dragons with clothes - they are different arches. _______________________________________________ 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 Apr 4 04:50:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:19 2005 Subject: [CF-Devel] client compile warnings Message-ID: <1081072233.595.59.camel@oberon.kameria> it's been a while since I built the client (gtk) but when I do (gcc version 3.3.3 (Debian 20040320)) I get a few warnings but it doesn't seem to be a problem. Just thought I'd let folks know about them. png.c: In function `rgba_to_xpixmap': png.c:783: warning: `cmask' might be used uninitialized in this function png.c:783: warning: `lastcolor' might be used uninitialized in this function gcc -g -O2 -DOSS_SOUND -Wall -I/usr/X11R6/include -I.. -I../common -I. -c sound.c gcc -g -O2 -DOSS_SOUND -Wall -I/usr/X11R6/include -I.. -I../common -I. -c x11.c x11.c: In function `get_root_display': x11.c:2092: warning: passing arg 1 of `XSetErrorHandler' from incompatible pointer type gcc -g -O2 -DOSS_SOUND -Wall -I/usr/X11R6/include -I.. -I../common -I. -c xutil.c xutil.c: In function `insert_key': xutil.c:247: warning: comparison is always false due to limited range of data type gcc -o cfclient png.o sound.o x11.o xutil.o -lpng -lz -lm -L/usr/X11R6/lib -lX11 -lXext ../common/libcfclient.a _______________________________________________ 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 Apr 4 05:31:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:19 2005 Subject: [CF-Devel] graphic errors (large images) Message-ID: <1081074696.595.63.camel@oberon.kameria> Here is the primary issue I am seeing with large images - they aren't getting cleaned up properly it appears. See the screen shots: -------------- next part -------------- A non-text attachment was scrubbed... Name: gryphon.png Type: image/png Size: 47772 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040404/e2b77d10/gryphon.png -------------- next part -------------- A non-text attachment was scrubbed... Name: worm.png Type: image/png Size: 31900 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040404/e2b77d10/worm.png -------------- 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 Apr 4 06:28:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:19 2005 Subject: [CF-Devel] image bug #2 (large images) Message-ID: <1081078105.592.80.camel@oberon.kameria> Here is the other bug I discovered with large images. Large images are placed behind other objects. This really looks odd and destroys the game illusion. I am not sure how two large images should interact properly but objects should be placed behind creatures anyway. If a large monster image crosses a large building image I think if the head is not crossed it renders properly. -------------- next part -------------- A non-text attachment was scrubbed... Name: cyclops.png Type: image/png Size: 23884 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040404/45cd8a3a/cyclops.png -------------- next part -------------- A non-text attachment was scrubbed... Name: cyclops2.png Type: image/png Size: 19448 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040404/45cd8a3a/cyclops2.png -------------- next part -------------- A non-text attachment was scrubbed... Name: cyclops3.png Type: image/png Size: 28660 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040404/45cd8a3a/cyclops3.png -------------- 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 Apr 4 07:33:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:19 2005 Subject: [CF-Devel] server segfault Message-ID: <1081081980.592.89.camel@oberon.kameria> Been getting this crash a bit when abusing my DM status to test large image monsters (summon some baddies then charm some and make them fight it out in interesting places...) SIGSEGV, segfault: 0x0807ef2f in follow_owner (ob=0x814cdb8, owner=0x81475ac) at pets.c:293 insert_ob_in_map(ob, tmp->map, NULL,0) using server CVS as of 04/04/2004 _______________________________________________ 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 Apr 4 21:37:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:19 2005 Subject: [CF-Devel] Pets crash (and bugfix) Message-ID: <000e01c41ab6$e6716e20$0100000a@archaios> Re: the bug report just filed in SF, A 'fix' applied to pets.c within the last 48 hours broke the pets' map transition entirely. Case in point: insert_ob_in_map(ob, tmp->map, NULL,0); However, the tmp pointer is NULL at the termination of the loop above. Thus, it should read: insert_ob_in_map(ob, ob->map, NULL,0); As ob->map is changed as needed in the above code. Patch attached. -archaios -------------- next part -------------- A non-text attachment was scrubbed... Name: pets.c.diff Type: application/octet-stream Size: 301 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040405/d65aa699/pets.c.obj -------------- 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 Apr 4 22:02:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:19 2005 Subject: [CF-Devel] server segfault References: <1081081980.592.89.camel@oberon.kameria> Message-ID: <006601c41aba$6a25adf0$0100000a@archaios> Fixed. See latest e-mail re: pets. -archaios ----- Original Message ----- From: "Todd Mitchell" To: "crossfire dev" Sent: Sunday, April 04, 2004 10:33 PM Subject: [CF-Devel] server segfault > > > Been getting this crash a bit when abusing my DM status to test large > image monsters (summon some baddies then charm some and make them fight > it out in interesting places...) > > SIGSEGV, segfault: > > 0x0807ef2f in follow_owner (ob=0x814cdb8, owner=0x81475ac) at pets.c:293 > > insert_ob_in_map(ob, tmp->map, NULL,0) > > using server CVS as of 04/04/2004 > > > _______________________________________________ > 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 Mon Apr 5 04:21:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] Mice reproduction, &c. Message-ID: <024001c41aef$6bc97fd0$0100000a@archaios> The issue of mice (and similiar creatures) reproducing when charmed has led to numerous server crashes, not to mention the nuisance that ensues when this occur. The patch attached ensures that this does not happen. -archaios -------------- next part -------------- A non-text attachment was scrubbed... Name: mice.etc.generator.diff Type: application/octet-stream Size: 326 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040405/32036a8d/mice.etc.generator.obj -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 5 16:07:44 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] Fear Message-ID: Fear became too poerful, it's almost as dangerous as confusion or even paralysis. Low-mid lvl characters may end up dead fast when facing monsters with fear-attack. Due to the fact that most monsters can use their spell-like abilities continously, I think the fear-effect in it's current state should be revised. (Geting +100 fear is much harder or using it is much uneconomical than para and conf res.) Gaea's followers with this have a way too strong drawback as well. -100 fear means they can only get 0 fear res with any effort. I suggest considering giving it's followers from -30 to -10 fear res, comparing to Monstrai's -10 conf. it sounds reasonable, now that fear is almost as dangerous as conf. or para. (Even such things happened to me: I attacked a dragon next to a non-magical room. With his fear he made me run into that room, and I had no way to left that room, 'cause portal, word of recall, scrolls, rods etc. didn't work and I couldn't get rid off the dragon, for he continously used his fear attack - seemed to be a deadlock. - There are too much monsters anyway which can use fear attack and some cone-type damaging spell - this combo what makes fear lethal- I was lucky that there was a troll as well, and wandering around I could "make" the troll stand in front of the dragon so it stopped using fear attack, and could kill a troll, step in his place and cast a dimension door.) Please consider! Xenon _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 5 19:24:12 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] bugfix: triggers and firewalls Message-ID: This patch will fix two timing bugs: 1. Firewalls always cast their spell once every second tic. Casting time is supposed to be defined by "speed". 2. Triggers ignore their reset delay time. -------------- next part -------------- Index: common/button.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/common/button.c,v retrieving revision 1.23 diff -c -r1.23 button.c *** common/button.c 27 Oct 2003 03:44:33 -0000 1.23 --- common/button.c 5 Apr 2004 23:06:36 -0000 *************** *** 332,338 **** op->stats.wc = state; if (state) { use_trigger(op); ! op->speed = 1.0 / op->arch->clone.stats.exp; update_ob_speed(op); op->speed_left = -1; } else { --- 332,341 ---- op->stats.wc = state; if (state) { use_trigger(op); ! if (op->stats.exp > 0) /* check sanity */ ! op->speed = 1.0 / op->stats.exp; ! else ! op->speed = 1.0; update_ob_speed(op); op->speed_left = -1; } else { Index: server/spell_util.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/spell_util.c,v retrieving revision 1.85 diff -c -r1.85 spell_util.c *** server/spell_util.c 23 Mar 2004 07:52:32 -0000 1.85 --- server/spell_util.c 5 Apr 2004 23:11:20 -0000 *************** *** 1089,1097 **** * take two ticks. Things that cast spells on the players * behalf (eg, altars, and whatever else) shouldn't cost * the player any time. ! * */ ! if (caster == op) { op->speed_left -= spell_ob->casting_time*PATH_TIME_MULT(op,spell_ob) * FABS(op->speed); /* Other portions of the code may also decrement the speed of the player, so * put a lower limit so that the player isn't stuck here too long --- 1089,1097 ---- * take two ticks. Things that cast spells on the players * behalf (eg, altars, and whatever else) shouldn't cost * the player any time. ! * Ignore casting time for firewalls */ ! if (caster == op && caster->type != FIREWALL) { op->speed_left -= spell_ob->casting_time*PATH_TIME_MULT(op,spell_ob) * FABS(op->speed); /* Other portions of the code may also decrement the speed of the player, so * put a lower limit so that the player isn't stuck here too long -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 5 22:29:11 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] Fear In-Reply-To: References: Message-ID: <200404052229.12070.eracclists@bellsouth.net> On Monday 05 April 2004 16:07 Palfy Tamas wrote: > Fear became too poerful, it's almost as dangerous as confusion or even > paralysis. Low-mid lvl characters may end up dead fast when facing monsters > with fear-attack. Due to the fact that most monsters can use their > spell-like abilities continously, I think the fear-effect in it's current > state should be revised. (Geting +100 fear is much harder or using it is > much uneconomical than para and conf res.) > Gaea's followers with this have a way too strong drawback as well. > -100 fear means they can only get 0 fear res with any effort. I > suggest considering giving it's followers from -30 to -10 fear res, > comparing to Monstrai's -10 conf. it sounds reasonable, now that > fear is almost as dangerous as conf. or para. [...] AFAIK, this is how fear always worked before it was broken. If you don't like not being able to battle dragons or other creatures due to fear then do not follow Gaea. :-P Oh yeah, always carry one of these: amulet of the Shielded Mind * (item_power +24)(resist confusion +100)(resist paralyzation +100) (resist fear +100). Wear with other items as appropriate. :-) Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 22:21:49 up 37 days, 16:17, 10 users, load average: 0.02, 0.03, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Apr 6 00:55:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] Fear In-Reply-To: <200404052229.12070.eracclists@bellsouth.net> References: <200404052229.12070.eracclists@bellsouth.net> Message-ID: <40724649.2050400@sonic.net> Just some clarification on how fear works. The only effect the resistance/vulnerability has in fear is the adjustment on saving throw. Fear -100 means you have a -10 on your saving throw. The saving throw is also adjusted based on level. So if you had no bonus/penalty to your resist fear, if you are more than 20 levels higher than whatever is casting fear, you'd also be immune. IF you have resist fear -100, then if you are 30 levels above, you are basically immune. I personally agree with Eracc here - I don't think every class/race/god combo should be entitled to kill every creature with equal ease. That said, a -100 resist fear may be a bit steep, but fear also operates a bit different - it lasts until you can't run any further (so, if you were backed in a corner, you'd basically be immune) - in comparison, confusion can often last quite a while. Maybe a -50 resist fear is mroe reasonable, but really hard to say, since as said, it only really effects level. Dragon's are level 18 - any level 18 character could have troubles with fear against dragons. _______________________________________________ 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 Apr 6 02:16:39 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] stat potions: patch/question In-Reply-To: References: Message-ID: <40725957.7050101@sonic.net> Bernd Edler wrote: > > On Tue, 9 Mar 2004, Bernd Edler wrote: > > >>I noticed a bug: >>If a natural stat gets below 1, one can no longer >>raise it with stat potions. >> >>It is possible to get to 0, if you drink too many >>cursed stat potions. >>You can even have a negative natural starting stat due to >>negative class modificators. >>Example: start int 9 -> quez,int 9-8 = 1 -> barbarian, int 1-6 = -5. >> >>With this patch one can now raise these stats with potions. >>Furthermore cursed potions no longer drain you below 1. >> >>Now for the question: >> >>In the original code tmp->stats.sp (the potions spellpoints) >>is used in the if condition,then set to 0 if a stat is changed. >> >>As i do not understand the intention for /* Fix it up for super potions */ >>, i can not emulate the desired behavior. >> >>I do know, that this stuff has no relevance to normal stat potions,as >>their sp is 0 anyway. >> >>So if somebody can explain that, i can finish this patch. >> > > After checking the archetypes, artifacts and all map files, > i think that potions with stat boni and sp!=0 > do not exist in the game. > Thus, i am positive, this new patch will fix the bug > without breaking anything else. Patch is now in CVS - I changed it around a little bit, but it is effectively the same. _______________________________________________ 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 Apr 6 04:08:57 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] stat potions: patch/question In-Reply-To: <40725957.7050101@sonic.net> References: <40725957.7050101@sonic.net> Message-ID: On Tue, 6 Apr 2004, Mark Wedel wrote: > > Patch is now in CVS - I changed it around a little bit, but it is effectively > the same. > Just one nitpick: You enabled the miracle cure for negative stats: If you have -5 int and drink an int potion you get -4, this is ok. If you drink a cursed int potion you get to 1. :-P _______________________________________________ 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 Apr 6 04:27:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] healing and magic power potions In-Reply-To: Message-ID: When do we should expect these potions to be repaired? _______________________________________________ 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 Apr 6 16:22:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] 'type', stuff like that Message-ID: <40731F7B.3000002@laposte.net> I was thinking of tweaking server code to be able to write 'type KEY' in archetypes, to make it easier to remember stuff (could be expanded to other things, too). But then I found another idea: instead of tweaking the server code, what about changing the 'collect.pl' script to do the substitution when collecting archs? Instead of dumbly merging files, it could substitute 'type KEY' to 'type whatever the value>'. This could be expanded to other types, hard to remember without checking code. Only thing I see is, editor collects archs too, my idea would require tweaking it too, probably... Comments? 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 Wed Apr 7 01:15:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] stat potions: patch/question In-Reply-To: References: <40725957.7050101@sonic.net> Message-ID: <40739C8A.3060004@sonic.net> Bernd Edler wrote: > > On Tue, 6 Apr 2004, Mark Wedel wrote: > > >> Patch is now in CVS - I changed it around a little bit, but it is effectively >>the same. >> > > > Just one nitpick: > You enabled the miracle cure for negative stats: > If you have -5 int and drink an int potion you get -4, this is ok. > If you drink a cursed int potion you get to 1. :-P I don't think it's that big a deal, since the player should really never have gotten a stat below 0 in the first place. _______________________________________________ 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 Apr 7 01:52:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] 'type', stuff like that In-Reply-To: <40731F7B.3000002@laposte.net> References: <40731F7B.3000002@laposte.net> Message-ID: <4073A52E.2080008@sonic.net> Nicolas Weeger wrote: > I was thinking of tweaking server code to be able to write 'type KEY' in > archetypes, to make it easier to remember stuff (could be expanded to > other things, too). > > But then I found another idea: instead of tweaking the server code, what > about changing the 'collect.pl' script to do the substitution when > collecting archs? Instead of dumbly merging files, it could substitute > 'type KEY' to 'type whatever the value>'. > This could be expanded to other types, hard to remember without checking > code. > > Only thing I see is, editor collects archs too, my idea would require > tweaking it too, probably... And the editor would have to write out the archetypes in number form also, and not string form. Personally, if I were to do this, I'd do something like: static char *type_names[LAST_ITEM_TYPE] = { NULL, "player", NULL, "rod", "treasure", .... } And then have some simple code in the loader - at the ^type check, do a simple check to see if the type is numeric, if so, simple assignment, if not, just a simple for loop to look through the type_names. The nice thing is that this makes it really easy to save the values - for times you want the type names saved, it is just a simple line like: fprintf(outfile,"type %s\n", type_names[op->type]); Or the like. But as said before, the type names in archetypes never seems like that big a deal to me - pretty much, just based on the directory the archetype is in, or other context, you can pretty much know the context. And even if it was confusiong, you could do something like: # type 38 is a gravestone type 38 ... As said before, the ones I find really confusing are any of the bitmasks in which the bitmask is already calculated (attacktypes and spell paths). And for those, certainly having the collect script parse those could make sense. Not positive, but many not cause as many problems with the java editor either, because it would see something like: attacktype fire|magic And just leave that data alone - it would be opaque. In comparison, the editor would have to know how to parse the actual things like 'type rod', because it needs that info to know what template to bring up when setting the object attributes. One problem with it being in the collect script is also potential confusion - eg, player adds a new type, and now has to know/fix the collect script for his archetypes to work. This might be a little confusing, vs the type names actually being defined in the code. At least for myself, I'd expect the load processing/conversion to be handled by the loader code, and thus would go there to look and make changes. _______________________________________________ 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 Apr 7 02:25:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] 'type', stuff like that In-Reply-To: <4073A52E.2080008@sonic.net> References: <40731F7B.3000002@laposte.net> <4073A52E.2080008@sonic.net> Message-ID: <4073ACF4.2090606@laposte.net> > And the editor would have to write out the archetypes in number form > also, and not string form. Editor would just need to know how to load strings, but would save number. Note that editor already has some idea of item's type, it displays the numerical & string type in the status bar. > Personally, if I were to do this, I'd do something like: > > static char *type_names[LAST_ITEM_TYPE] = { > NULL, > "player", > NULL, > "rod", > "treasure", > .... > > } > > And then have some simple code in the loader - at the ^type check, do a > simple check to see if the type is numeric, if so, simple assignment, if > not, just a simple for loop to look through the type_names. Yep, pretty easy. Though my idea of letting the collect script do it was to not impact (wouldn't prolly matter, in any case) server loading time. Also wouldn't require server change at all, since conversion would be handled by collect.pl > The nice thing is that this makes it really easy to save the values - > for times you want the type names saved, it is just a simple line like: > > fprintf(outfile,"type %s\n", type_names[op->type]); > > Or the like. I don't know what would be the point of saving the values in string, though, at least as far as game is concerned. But yes, that'd make it easy. I'd just add a check to print a warning if NULL type :) > But as said before, the type names in archetypes never seems like that > big a deal to me - pretty much, just based on the directory the > archetype is in, or other context, you can pretty much know the > context. And even if it was confusiong, you could do something like: > > # type 38 is a gravestone > type 38 > ... True, but first you'd have to know the actual type. If someone were to parse archetypes to find something, s/he'd need to remember or check the type's meaning. And it's neatier to see 'type GRAVESTONE' instead of '# type 38 is gravestone - type 38' everywhere ^_- > As said before, the ones I find really confusing are any of the > bitmasks in which the bitmask is already calculated (attacktypes and > spell paths). And for those, certainly having the collect script parse > those could make sense. Not positive, but many not cause as many > problems with the java editor either, because it would see something like: > > attacktype fire|magic > > And just leave that data alone - it would be opaque. In comparison, > the editor would have to know how to parse the actual things like 'type > rod', because it needs that info to know what template to bring up when > setting the object attributes. That's also why I was thinking of modifying the collect scipt. Since it's in perl, pretty easy to handle strings - that's what perl was designed for, I guess :) > One problem with it being in the collect script is also potential > confusion - eg, player adds a new type, and now has to know/fix the > collect script for his archetypes to work. This might be a little > confusing, vs the type names actually being defined in the code. Given the format of the define.h file, and others which contain some defines, I don't think it would be that hard to add a small parsing from collect to gather values/number pairs - but it would make collect.pl more than a simple & dumb collect tool. > At least for myself, I'd expect the load processing/conversion to be > handled by the loader code, and thus would go there to look and make > changes. I'll just add a small comment in define.h to say stuff will be parsed :) I guess it basically depends on what we think is best, or more natural. And my proposal extends to attacktypes, of course, and other numerical fields which could be hard to understand. Nicolas 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 Wed Apr 7 09:05:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:20 2005 Subject: [CF-Devel] stuff In-Reply-To: <4073ACF4.2090606@laposte.net> Message-ID: Please repair healing and magic power potions, they still do _not_ work :-( _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Thu Apr 8 02:05:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] Broken healing potions? In-Reply-To: References: Message-ID: <4074F9AC.8050307@sonic.net> Bernd Edler wrote: > > Those two are the only potions using the old method > where sp = spell to cast. > The map loader (loader.l) parses these values, but > the treasure generation in treasure.c does not. Which gives the interesting issue - if you logged out, and then logged back in, these would be fixed. > So we can either: > > a.) add the transformation to treasure.c, This is the approach I took (now in CVS) > > b.) join these two with the other generic potions. > (these are made with artifact code setting the spell in "other arch") > This is s possible as there is no treasure list containing only one > kind of potion. It does not need any code change either. > But in addition to the resource files, > about 30 map files need to be changed. Yeah - unfortunately, there is no way to currently have arch's start with an inventory. The one problem with the above change is that that could mess up value some (I don't know if any maps have actually changed the potion object). I'd think it should otherwise work, because I believe the loader code is smart enough to generate the spell treasures for any objects on the map that need it (otherwise, all maps that just had a spellbook sitting there would be broken). > > or > > c.) set "other arch" accordingly in the archetypes > and get item generator to parse that. > > > _______________________________________________ > 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 Thu Apr 8 02:15:08 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] 'type', stuff like that In-Reply-To: <4073ACF4.2090606@laposte.net> References: <40731F7B.3000002@laposte.net> <4073A52E.2080008@sonic.net> <4073ACF4.2090606@laposte.net> Message-ID: <4074FBFC.2050402@sonic.net> Nicolas Weeger wrote: > > > Yep, pretty easy. Though my idea of letting the collect script do it was > to not impact (wouldn't prolly matter, in any case) server loading time. > Also wouldn't require server change at all, since conversion would be > handled by collect.pl Yeah, the time difference is likely very trivial. On each object, it would be some overhead. However, most objects on maps don't change the type field, so it'd only really be a bigger hit on the archetype processing. My one concern about it being the collect script is that developers would need to know to updated it. > > I don't know what would be the point of saving the values in string, > though, at least as far as game is concerned. But yes, that'd make it > easy. I'd just add a check to print a warning if NULL type :) In most cases, not much. But for player save files, or perhaps unique maps, it could be very handy to have a more readable form of what is actually saved than seeing something is 'type 27', and then having to look up what type 27 is. But as said, object type tends not to get changed too often, so probably not that big an issue. The other advantage of having an array of the type->name mapping is that it would be useful for debugging. Eg, one might dump the object structure in the debugger and see it is type 18. Now instead of having to look at what object 18 is, I could do something like 'print type_names[18]' and get my answer more immediately. > True, but first you'd have to know the actual type. If someone were to > parse archetypes to find something, s/he'd need to remember or check the > type's meaning. > And it's neatier to see 'type GRAVESTONE' instead of '# type 38 is > gravestone - type 38' everywhere ^_- certainly true. But not positive how big an issue it is. If personally not found it much an issue, but I'm just one person. > I guess it basically depends on what we think is best, or more natural. > And my proposal extends to attacktypes, of course, and other numerical > fields which could be hard to understand. I'd certainly prefer for it to be in the actual C code - that seems more logical, and also provides a way to save it - for things like spellpaths and attacktypes, it could be very handy to look at those values in the save file/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 Thu Apr 8 02:31:39 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] Loader.c issue Message-ID: <4074FFDB.5060800@laposte.net> It seems there are different flex and/or parameters used on loader.l to generate loader.c Unfortunately some settings cause issues with Windows, which doesn't have 'unistd.h'. On some versions of loader.c, it's enclosed by '#ifndef YY_NO_UNISTD_H', on others no. Since the first version (with #ifndef YY_NO_UNISTD_H) is better (avoids me the pain of adding some windows-specific #ifdef), any way to ensure this is always the case? 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 Thu Apr 8 09:01:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_Broken_healing_potions=3F?= Message-ID: > Yeah - unfortunately, there is no way to currently have arch's start with an > inventory. I am having problems with this - *especially* for times when you want to use the create command to make spell books or scrolls or similar things which are basically an arch with an object in it's inventory. Using inventory this way is really good IMHO we just need to fix up a lot of commands and things to harnes this. We need a better way to add inventory items (even multiple items) to arches to make the new skill/spell system work smoother - especially for realtime DM stuff. This would be good for creating monsters with special skills too... _______________________________________________ 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 Apr 9 19:39:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] fear again In-Reply-To: Message-ID: I'm a 89 lvl dragon with 0 fear resistance (in fact, it's -100 (Gaea) +100 (Amulet of Shielded Mind) = 0). Regular dragons' fears still affect me. (Can't determine the rate, but seems far more than 50%...) Xenon _______________________________________________ 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 Apr 9 17:07:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] treasure list question Message-ID: <1081548471.575.2.camel@oberon.kameria> I am moving the god treasure lists out to the arches and came across this - I believe that the two skill related lists do not belong with Valriel in particular and should be left in the treeasures file for now but am looking for confirmation on this: ######################################################### # Valriel - Lord of Angels, Duke of the Heavens, Healer and Protector # # This is basically given to monsters that might get spellbooks or use # wands/rods/etc. This is mostly necessary so that if they become # the pets of players, the player will get exp awarded to the correct # skill. treasure skill_use_magic_item arch skill_use_magic_item end # treasure all_spell_skills arch skill_use_magic_item more arch skill_evocation more arch skill_praying more arch skill_pyromancy more arch skill_sorcery more arch skill_summoning end # treasure Valriel arch valriel_avatar_info more _______________________________________________ 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 Apr 10 01:58:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] treasure list question In-Reply-To: <1081548471.575.2.camel@oberon.kameria> References: <1081548471.575.2.camel@oberon.kameria> Message-ID: <40779B13.9040108@sonic.net> Todd Mitchell wrote: > I am moving the god treasure lists out to the arches and came across > this - I believe that the two skill related lists do not belong with > Valriel in particular and should be left in the treeasures file for now > but am looking for confirmation on this: You are correct it doesn't belong to valriel. I meant to put it at the top of the treasures files, but wasn't paying enough attention to the comments (which at some level, aren't really clear, as there is no break between the header comments for the file, and the comments for the actual gods treasure lists. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Apr 10 02:15:14 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] Loader.c issue In-Reply-To: <4074FFDB.5060800@laposte.net> References: <4074FFDB.5060800@laposte.net> Message-ID: <40779F02.3080000@sonic.net> Nicolas Weeger wrote: > It seems there are different flex and/or parameters used on loader.l to > generate loader.c > Unfortunately some settings cause issues with Windows, which doesn't > have 'unistd.h'. On some versions of loader.c, it's enclosed by '#ifndef > YY_NO_UNISTD_H', on others no. > Since the first version (with #ifndef YY_NO_UNISTD_H) is better (avoids > me the pain of adding some windows-specific #ifdef), any way to ensure > this is always the case? It appears this is a combination of the version of flex as well as options used. I'm not sure, as I have flex 2.5.4 on my systems, which doesn't support that behaviour, but it appears that they (flex folks) have added some new stuff to that - at least I see it in the 2.5.31 version. I suppose we should make up a list (for developers) or the release of different products (automake, aclocal, flex, etc) required for development. _______________________________________________ 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 Apr 10 02:18:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] Broken healing potions? In-Reply-To: References: Message-ID: <40779FC1.9000103@sonic.net> Todd Mitchell wrote: > >> Yeah - unfortunately, there is no way to currently have arch's start with >> an inventory. > > > I am having problems with this - *especially* for times when you want to use > the create command to make spell books or scrolls or similar things which are > basically an arch with an object in it's inventory. > > Using inventory this way is really good IMHO we just need to fix up a lot of > commands and things to harnes this. > > We need a better way to add inventory items (even multiple items) to arches > to make the new skill/spell system work smoother - especially for realtime DM > stuff. This would be good for creating monsters with special skills too... Arguably, this is really just a matter of DM commands. For example, the create command already understands the 'of' syntax. But for some objects, like perhaps spellbooks, scrolls, potions, etc, in addition for it looking for 'of' items as being artifacts, it should see if the 'of' portion represents a spell. Thus, something like 'create wand of large fireball', would all work. But the DM commands have never been really well done/supported (there are many ways for a dm to crash a server unintentionally with dm commands). _______________________________________________ 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 Apr 10 02:28:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] fear again In-Reply-To: References: Message-ID: <4077A21A.3040701@sonic.net> Palfy Tamas wrote: > I'm a 89 lvl dragon with 0 fear resistance (in fact, it's -100 (Gaea) > +100 (Amulet of Shielded Mind) = 0). > Regular dragons' fears still affect me. (Can't determine the rate, but > seems far more than 50%...) (If you are starting a new subject, please don't reply to existing posts. Smart mail readers that do threading get confused by this, and put your message (and possible thread) jumbled up with the other threads). In any case, back to the subject on hand - I'd guess this might be related to the way players get hit by the same spell more than once EG, if you cast fear (or slow, or paralyze, etc), you get a case of the spell actually being several spaces 'deep' as it moves accross the map. Thus, even though only one spell has been cast, you may get hit by several spell effects from the same spell. there has been talk about how to resolve this in the past - it gets tricky, in that you can't really keep track of all the spell effects the player has been hit with recently to know if this is a new one or not. For cone spells, this is especiall tricky, as what happens is that as the spell progress, each space behind puts the spell in 3 spaces, left, center, right. The effect of this is that the center of the cone spell now effectively have more effects happening, and thus more damage. This perhaps make sense for damaging spells, less so for effects spells. However, I just had the thought - there are two ways this could be dealt with: 1) Make the spell effect only 1 space deep. Thus, for a fear, confusion, whatever spell, you'll only be hit by it once (unless you decide to run along with it). This reduces some of the display effect, but maybe not that big a deal. 2) Make only the leading edge do the actual effect, and the trailing bits are just for visual purposes. The only disadvantage with this method is there is the odd effect that a player from the side could step into the tailing portion of the spell, and since that is only for visual purposes, not get effected. However, none of these deal with the fact that the center of the cone has more effects overlapping. So one possibility is that for effect spells, don't overlap that center area with more effects. _______________________________________________ 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 Apr 10 02:51:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] patch: max level In-Reply-To: References: Message-ID: <4077A785.7040504@sonic.net> Bernd Edler wrote: > With this little change, we can allow players to gain exp > in their skills even if maxed out overall. > We just restrict the maxexp check in change_exp to monsters, as > add_exp checks everything correctly for players already. > > Then it is no more harmful to gain experience in "useless" skills. This is now applied to CVS. > > Speaking of that, it seems to me like fireborn do fire damage with > punching and karate. > While this has a certain logic, it also renders their natural > flame touch useless. This should now be fixed. The 'problem' is that if the player had a 0 attacktype, they got the attacktype of their archetype. And punching and karate had no attacktype set, so it pulled the attacktype for the archetype, which was physical & fire. I've just added attacktype to those skills. Arguably, this may break things if something was really trying for the behaviour. But that would seem to break in any others. Eg, if you cast confusion on yourself and tried to use karate, you wouldn't kill anything, because your only attacktype would be confusion. If certain attacking skills are suppose to gain attacktypes from the parent arch, a better method is needed. EmperorBMA@cox.net wrote: > The same can be said for dragons and clawing... Claw should take precedence. That is easy enough to change - the ordering right now is in include/skills.h - the order is currently karate, clawing, flame touch, and punching. Probably the best way would be for this to be setable by each player, as I don't know if there is univeral agreement on what is the best and so 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 Sat Apr 10 09:59:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] Bigworld map quest hints + Container dropping In-Reply-To: <4077A21A.3040701@sonic.net> Message-ID: I thought I just bring this on (many other cases may be occurent, I think it won't harm if I told you): In Scorn in the tavern there's an elf who mentions the Valley of the 3 Sisters, and tells that it's located east from Brest in the southern mountains. It was true before, but now this hint is absolutely false. The other thing: On mf.rt.com right-clicking on readied container resulted in dropping all items from that container. This was an excelent idea, for this way you could carry and drop items that otherwise would have stacked with other locked items. (Not to mention you could separate temporal treasures from non-locked long-term items.) I wonder if we could use containers this way again. Xenon _______________________________________________ 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 Apr 10 16:10:44 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] Bigworld map quest hints + Container dropping In-Reply-To: References: Message-ID: <200404101610.44692.eracclists@bellsouth.net> On Saturday 10 April 2004 09:59 Palfy Tamas wrote: > The other thing: On mf.rt.com right-clicking on readied container > resulted in dropping all items from that container. This was an > excelent idea, for this way you could carry and drop items that > otherwise would have stacked with other locked items. (Not to > mention you could separate temporal treasures from non-locked > long-term items.) I wonder if we could use containers this way > again. Still works. Don't "lock" the container, ready it, right click, the items are dropped. Will not work with a locked container. AFAIAC this is a Good Idea because I like being able to lock containers so I do not accidentally drop their contents in a store with a missed mouse click on the wrong container. Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 16:07:18 up 42 days, 10:02, 10 users, load average: 0.00, 0.03, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Apr 10 16:04:14 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] fear again In-Reply-To: References: Message-ID: <200404101604.14101.eracclists@bellsouth.net> On Friday 09 April 2004 19:39 Palfy Tamas wrote: > I'm a 89 lvl dragon with 0 fear resistance (in fact, it's -100 > (Gaea) +100 (Amulet of Shielded Mind) = 0). > Regular dragons' fears still affect me. (Can't determine the rate, > but seems far more than 50%...) > > Xenon My character, poof, is a level 73 dragon following Sorig. With the amulet he gets a +100 resistance (which I understand really only modifies the saving throw(?)) and is completely unaffected by fear. So, your problem is with being a follower of Gaea. IMNSHO, Gaea sucks. :-P Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 15:59:17 up 42 days, 9:54, 10 users, load average: 0.08, 0.03, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Apr 11 15:53:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] broken map? (Port Joseph pier, /world/world_101_114) Message-ID: This was discovered on cf.mf.net On map /world/world_101_114 (the pier of Port Joseph), players can't walk on the pier for some reason. They are "stuck" their, unable to move at all. Any ideas on why this is happening or what is causing this? -- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Apr 11 22:02:19 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] broken map? (Port Joseph pier, /world/world_101_114) In-Reply-To: References: Message-ID: <1081738939.578.6.camel@oberon.kameria> fixed in CVS my fault probably from resculpting the coast - the water was not passable under the pier. On Sun, 2004-04-11 at 20:53, Rick Tanner wrote: > This was discovered on cf.mf.net > > On map /world/world_101_114 (the pier of Port Joseph), players can't walk > on the pier for some reason. They are "stuck" their, unable to move at > all. > > Any ideas on why this is happening or what is causing this? > _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Apr 11 13:34:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:21 2005 Subject: [CF-Devel] big world - big problems In-Reply-To: <4077A21A.3040701@sonic.net> Message-ID: I can't help not telling this: This bigworld map idea missed it's point. On the small world maps peepo felt like doing some discovery. Now, even _familiar_ (from non-bigworld servers) areas are extremely hard to find. Not to mention, some quest sites have been moved to different locations. I speak of experience: now players don't have a clue where they should go or where they can find quest locations. Even previously notorious locations are considerd secrets 'n' stuff. And what does this whole thing gives in return? Well, nothing. Exploring has no point. We have to admit: there are _no_ interesting new locations, only painfully boring wastelands which are sooo random (!!) you don't have a chance to know where you are - the map is visually unmemorizable. (And this is one of the biggest problem. It's too easy to get lost.) I know devs don't like being criticised for they do their job for free and they want for the best, I appreciate this. But please, honestly think about this, and try to ask the question: Why bigworld map? Maybe it has lots of opportunities, but in it's current state it's not even half ready to consider it worthy to use. I really don't want to scold the work of the devs with this mail, I just want you to think about it as impartial as possible. Xenon _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 12 12:38:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_big_world_-_big_problems?= Message-ID: Maybe it has > lots of opportunities, but in it's current state it's not even half ready > to consider it worthy to use. Well that's the point isn't it. It is still in development. The old maps are still available and being maintained (although not much is changing on them) and while this happens people who like to play on develpment servers are getting to use/playtest bigworld. I think the real point you allude to is the misconception that crossfire.metalforge.net is a Crossfire stable server - it isn't. It is the primary development/play test server from what I understand. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 12 12:57:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] lost ring In-Reply-To: <40457769.8080706@sonic.net> References: <1078160159.5118.11.camel@d5110227.lss.emc.com> <40436B74.1050407@laposte.net> <1078161319.5117.16.camel@d5110227.lss.emc.com> <40443469.2010108@sonic.net> <1078240137.4511.0.camel@d5110227.lss.emc.com> <40457769.8080706@sonic.net> Message-ID: <20040412145726.020dc49c.kstenger@montevideo.com.uy> hi, I found something about this wrong merging rings problem, but i dont know how to fix it, so i drop it here for those who know the code better. i was playing with a pile of rings of pow+2 and another of int+2 and it happened once and again, that no matter what the order was, the rings would always merge together into ones of the same kind, so i went to look at the CAN_MERGE function and found out that it only checks for the type of the rings, which as you can see below are exactly the same in this case. No wonder that it will keep merging. I just dont know what is wrong, is it the item type?, is it that the CAN_MERGE should check for other things also to compare the items? well... here are the items dumped: arch ring name ring name_pl rings face ring.116 animation ring is_animated 0 Pow 2 x 13 y 5 nrof 5 type 70 material 2 materialname iron value 2000 weight 20 client_type 391 item_power 1 identified 1 been_applied 1 body_finger -1 end arch ring name ring name_pl rings face ring.114 animation ring is_animated 0 Int 2 x 13 y 6 nrof 7 type 70 material 2 materialname iron value 2000 weight 20 client_type 391 item_power 1 identified 1 been_applied 1 body_finger -1 end hope someone know how to handle it, cause this could also be happening to other items, but i couldnt tellfor sure. At least now I can explain myself why so many times players said to have lost some ring and we blamed them about them dropping it "accidentally" :/ *shrugs* -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 12 13:33:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] big world - big problems In-Reply-To: References: Message-ID: <200404121333.17449.eracclists@bellsouth.net> On Sunday 11 April 2004 13:34 Palfy Tamas wrote: [...] > point. We have to admit: there are _no_ interesting new locations, > only painfully boring wastelands which are sooo random (!!) you > don't have a chance to know where you are - the map is visually > unmemorizable. (And this is one of the biggest problem. It's too > easy to get lost.) > [...] Putting aside the fact that crossfire.metalforge.net is basically a test server I wish to disagree with this point. I find that the more I look around on the "wasteland" the more I come to recognize certain landmark features. I have managed to notice MEMORIZABLE features that I now use to get to several locations with 100% accuracy. The maps are not "random", they are static. Look at them in the map editor if you want to see that they are not all just alike and do have features one can recognize. Just don't go trying to explore the big world when it is dark. :-) That said, I do agree the big world is rather empty. If it bothers you this badly then pick a big map square out in the wilderness and put something interesting on it with the map editor. Then submit it for review. The map editor runs with Java and is not difficult to use at all. I use it all the time to examine how some maps are put together. Gene (aka poof, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 13:20:04 up 44 days, 7:15, 10 users, load average: 0.12, 0.04, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 12 13:13:25 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] lost ring In-Reply-To: <20040412145726.020dc49c.kstenger@montevideo.com.uy> References: <1078160159.5118.11.camel@d5110227.lss.emc.com> <40436B74.1050407@laposte.net> <1078161319.5117.16.camel@d5110227.lss.emc.com> <40443469.2010108@sonic.net> <1078240137.4511.0.camel@d5110227.lss.emc.com> <40457769.8080706@sonic.net> <20040412145726.020dc49c.kstenger@montevideo.com.uy> Message-ID: <20040412151325.2238ee53.kstenger@montevideo.com.uy> > and found out that it only checks for the type of the rings, er... correcting myself, yes it does other checks, but are you sure it checks for each of the stats? on the same topic but slightly different, seems like the animation check for merging items is what is not allowing diamonds (and other gems) to merge sometimes -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ 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 Apr 13 12:32:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] Some bug fixes In-Reply-To: <404BFDAB.4040903@sonic.net> References: <20040301074409.GA3468@idefix2.dvlp.in-medias-res.com> <40443199.9010508@sonic.net> <20040307102227.GA6214@idefix2.dvlp.in-medias-res.com> <404BFDAB.4040903@sonic.net> Message-ID: <20040413173249.GA6533@idefix2.dvlp.in-medias-res.com> Here is a new patch that attempts to find a keymaster: it tries harder to find a keymaster. After that it tries to find a free spot. If this too fails, it drops the key in a random place (i.e. wall). I did some more checks with the random_map program. It found a keymaster in over 95% of all tries. In the remaining cases it found a free spot. The fall back case to drop the key in a wall (freeindex == -1 after the second loop) did never occur. Concerning the other change in patch-4.diff to drop a chest if no free spot could be found, I think this behavior is acceptable: all callers of place_chest() check for (or ignore) a NULL result. So it is better to drop the chest than to place it in a arbitrary/invalid (i.e. "x+freearr_x[-1]") location. -------------- next part -------------- Index: random_maps/treasure.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/random_maps/treasure.c,v retrieving revision 1.19 diff -u -w -r1.19 treasure.c --- random_maps/treasure.c 8 Jan 2003 08:39:18 -0000 1.19 +++ random_maps/treasure.c 13 Apr 2004 17:24:05 -0000 @@ -296,7 +297,7 @@ if(door_flag==PASS_DOORS) { int tries=0; the_keymaster=NULL; - while(tries<5&&the_keymaster==NULL) { + while(tries<15&&the_keymaster==NULL) { i = (RANDOM()%(RP->Xsize-2))+1; j = (RANDOM()%(RP->Ysize-2))+1; tries++; @@ -304,9 +305,18 @@ } /* if we don't find a good keymaster, drop the key on the ground. */ if(the_keymaster==NULL) { - int freeindex = find_first_free_spot(the_key->arch,map,i,j); - kx = i + freearr_x[freeindex]; - ky = j + freearr_y[freeindex]; + int freeindex; + + freeindex = -1; + for(tries = 0; tries < 15 && freeindex == -1; tries++) { + kx = (RANDOM()%(RP->Xsize-2))+1; + ky = (RANDOM()%(RP->Ysize-2))+1; + freeindex = find_first_free_spot(the_key->arch,map,kx,ky); + } + if(freeindex != -1) { + kx += freearr_x[freeindex]; + ky += freearr_y[freeindex]; + } } } else { /* NO_PASS_DOORS --we have to work harder.*/ -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Apr 14 01:36:24 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] Some bug fixes In-Reply-To: <20040413173249.GA6533@idefix2.dvlp.in-medias-res.com> References: <20040301074409.GA3468@idefix2.dvlp.in-medias-res.com> <40443199.9010508@sonic.net> <20040307102227.GA6214@idefix2.dvlp.in-medias-res.com> <404BFDAB.4040903@sonic.net> <20040413173249.GA6533@idefix2.dvlp.in-medias-res.com> Message-ID: <407CDBE8.8080105@sonic.net> Andreas Kirschbaum wrote: > Here is a new patch that attempts to find a keymaster: it tries harder > to find a keymaster. After that it tries to find a free spot. If this > too fails, it drops the key in a random place (i.e. wall). > > I did some more checks with the random_map program. It found a keymaster > in over 95% of all tries. In the remaining cases it found a free spot. > The fall back case to drop the key in a wall (freeindex == -1 after the > second loop) did never occur. Patch looks fine. I'll apply it to CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Apr 14 01:54:48 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] lost ring In-Reply-To: <20040412145726.020dc49c.kstenger@montevideo.com.uy> References: <1078160159.5118.11.camel@d5110227.lss.emc.com> <40436B74.1050407@laposte.net> <1078161319.5117.16.camel@d5110227.lss.emc.com> <40443469.2010108@sonic.net> <1078240137.4511.0.camel@d5110227.lss.emc.com> <40457769.8080706@sonic.net> <20040412145726.020dc49c.kstenger@montevideo.com.uy> Message-ID: <407CE038.20108@sonic.net> Karla Stenger wrote: > hi, > I found something about this wrong merging rings problem, but i dont know how to > fix it, so i drop it here for those who know the code better. > > i was playing with a pile of rings of pow+2 and another of int+2 and it happened > once and again, that no matter what the order was, the rings would always merge > together into ones of the same kind, so i went to look at the CAN_MERGE function > and found out that it only checks for the type of the rings, which as you can > see below are exactly the same in this case. No wonder that it will keep > merging. I just dont know what is wrong, is it the item type?, is it that the > CAN_MERGE should check for other things also to compare the items? CAN_MERGE wasn't checking to see if the stats of the two rings are the same. While less likely, this could actually be a problem with all objects. Eg, if there was a nice DM that took just a normal sword and gave it +3 Str, it could merge with other normal swords, either losing that +3 Str, or giving it to the entire group. This is probably less likely with most other objects, because the value wouldn't be the same (eg, a Str +1 sword would cost more than a sword without that Str +1 in most cases). And stat bonus don't show up in most other object, so less likely to be problems elsewhere. In any case, the fix appears to be to just put a memcmp for the stats structures, just like is already done for the resist structures. > on the same topic but slightly different, seems like the animation check for > merging items is what is not allowing diamonds (and other gems) to merge > sometimes I've not seen it - the animation checks shouldn't cause a problem, because the check is actually to be making sure it is using the same animation sequence, and not so much the same frame is being animated. If there are cases where this can be documented and the two objects fully examined to make sure that nothing else is in fact different. _______________________________________________ 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 Apr 14 02:15:21 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] big world - big problems In-Reply-To: References: Message-ID: <407CE509.6050201@sonic.net> Palfy Tamas wrote: > I can't help not telling this: > > This bigworld map idea missed it's point. On the small world maps peepo > felt like doing some discovery. Now, even _familiar_ (from non-bigworld > servers) areas are extremely hard to find. Not to mention, some quest > sites have been moved to different locations. > I speak of experience: now players don't have a clue where they should go > or where they can find quest locations. Even previously notorious > locations are considerd secrets 'n' stuff. And what does this whole thing > gives in return? Well, nothing. Exploring has no point. We have to > admit: there are _no_ interesting new locations, only painfully boring > wastelands which are sooo random (!!) you don't have a chance to know > where you are - the map is visually unmemorizable. (And this is one of > the biggest problem. It's too easy to get lost.) > I know devs don't like being criticised for they do their job for free and > they want for the best, I appreciate this. But please, honestly think > about this, and try to ask the question: Why bigworld map? Maybe it has > lots of opportunities, but in it's current state it's not even half ready > to consider it worthy to use. > I really don't want to scold the work of the devs with this mail, I just > want you to think about it as impartial as possible. A few notes in addition to what others have said. The perception of the bigworld map can vary greatly depending on the size of hte map window you are using (a 25x25 map window will have a different perception compared to using an 11x11 map window). The bigworld map is certainly work in progress. But one of the main reasons we went to a large map scale was crowding on the old maps. Whenever it came time to put a new quest or whatever on the old maps, it was pretty difficult placing the new maps more than about 10-15 spaces from another quest already on the maps. It was really overly crowded. Now it may certainly be the case that the current maps are a little sparse, but that is a good thing - if they were so built up that we were looking at redoing them or starting another new continent because of that, only a year or so after making those maps, I'd say we're doing something wrong. That said, most stuff in general stayed in the same relative locations. If there are quests or NPC or messages/whatever that are giving wrong information about quests (saying go east when you need to go south or whatever) please post specific examples and we can get them fixed. If the issue is that some things are in different locations than they used to be, yet the NPC's and whatnot have the correct info, I'd say tough luck. Trying to appease that basically amounts to never making any change what so ever that may change the game (one could start to then complain about changes made to archetyps, or most any other change). The real solution there is to just set up or play on a server that is running some snapshot and never plans to update. _______________________________________________ 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 Apr 14 02:36:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] Rings bug ... In-Reply-To: <200403150205.52621.eracclists@bellsouth.net> References: <200403142226.33943.eracclists@bellsouth.net> <200403150205.52621.eracclists@bellsouth.net> Message-ID: <407CE9F7.5050504@sonic.net> ERACC wrote: > On Sunday 14 March 2004 22:26 > ERACC wrote: > > >>Greetings, >> >>crossfire.metalforge.net: >> >>Character, poof, has several rings in apt to give to newbie >>players. Picked up a Wis +2, then a Pow +2 and the Pow +2 MERGED >>with the Wis +2! When I dropped them they became FOUR rings of Wis >>+2. Then picked up a Pow +2 FIRST then a Wis +2 which THEN merged >>with the Pow +2 and I had two more Pow +2 which I then dropped and >>they became FOUR Pow +2. As far as I know right now I can repeat >>this behavior at will. Did not try other combinations. >> >>Caveat: The becoming four rings MAY be my mind misremembering as >>this happened several hours ago. But the merging I DO remember. >> >>Gene (aka poof, aka eracc) > > > After further testing it appears the rings were also merging with > other rings when I dropped them. That is why I thought they were > doubling when I dropped them. All the +2 rings I had are now just > Pow and Wis rings. Looks like something has hosed the merge code at > least for these +2 rings. :-/ > This is now fixed in CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Apr 14 04:24:56 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] Sound proposal Message-ID: <407D0368.6040603@laposte.net> Hello. There has been some discussion about sound support. If no one works on it, i'll fix it, and try to improve. Here's how I see the stuff: * add a new line for archetypes, 'sound , , ' with something like 'cast, die, move', you get the clue * put .raw files with archetypes * assign generic sounds to archetypes. Ex: goblin archetype gets a 'sound die, goblin_horrible_death' line * change collect.pl to copy .raw files to crossfire/share/sounds (or wherever we want) and generate a /share/arch_sounds file containing a simple list with filenames * server will then read this file, give a unique identifier to each sound. When loading archetypes, link sound_event to that identifier * client can request arch_sounds file, then individual sound files (like 1024 bytes by 1024 bytes) * when a sound event needs to occur, server just sends the unique sound identifier Client can then have a sound cache, based on filename. An extension which could be nice: allow map-specific sounds. Like a special sound when your mega-monster dies :) I'd see this this way: * add sounds in same directory as map file, or in a sound subdir (whatever). This way, we know which sounds go with which maps. Also, give a unique sound to the file - like _.raw * at some point, collect the sounds, and copy'em to the same directory as other sounds from archetypes * override sound event on object from archetype, as any other field The only thing which I don't like with this is that it requires 2 passes: collect sounds from archetypes, collect sounds from maps. Comments or brilliant ideas? Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 12 19:59:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: =?iso-8859-1?Q?Re:_[CF-Devel]_big_world_-_big_problems?= In-Reply-To: Message-ID: *sigh* I'm starting to feel there's no 1 person here who's trying to _understand_ me instead of trying to prove why I'm _not_right_. I said I'm not the type who crabs others selfless works, and it's true! But it really pisses me off when peepo treat me so disdainfully and tell me platitudes as explanation. Allow me to try again. I'll be as understandable as possible. The problem is the bigworld maps imperspicuity. Fact that peepo _do_ have problems with orientation - maybe except poof aka ERACC who has a wonderful, but naiv soul who likes everything as they are. ( Sorry, ERACC, but telling such thing like "the more I look around on the "wasteland" the more I come to recognize certain landmark features. I have managed to notice MEMORIZABLE features that I now use to get to several locations with 100% accuracy. The maps are not "random", they are static." I can't help but call it naiv. Maybe there are some locations that are recognizable, but they are few in number. I know what I'm talking about, I have done exploring for hours - I'm not writing this all thing just because I'm an angry child -, and I don't have a bad sense of locality. But hours were not enough to have even a clue about the regularity of the landmarks. Ok, maybe I'm too stupid for this, but then most of the players are too stupid for this as well. Look on the whole bigworld map, put your hand on your hart at tell me "Ah, yeah, I know the whole thing, most of it at least, just tell me a location, put me anyhere and I'll be there in no time without watching the coordianates." Maybe you know 5, maybe 10% of the bigworld map, but the nonbigworld map was almost 100% perspicuous to anyone.) I heard the explanation "it is a test server", well, ok, that's what I hear all the time when something's wrong. Would it be really that hard not to treat us, players as enemies or children? You really would tell such an explanation to your friends for example? How do I mean it? I'll explain. I'm a working man, I'm working on projects, I know what means responsability, and I know what "test" means. Whenever we reach a state that's worth testing, we know it's _almost_ finished. We don't even bother with testing unless we know it's ready. Is this bigworld map really ready? That's what I asked in my previous mail, just think about it impartially. I don't like reciting "facts", but it's true even _known_ locations are hard to find (I personally make notes of coordinates - but how do I know coordinates...? How can one get such an information?). One thought slipped into my mind: players cannot point out mistakes of devs. Devs are implicitly cannot be mistaken. That's the attitude I feel. Well let me tell you one thing. I'm not doing this because I'm a helpless looser in the game and have no other idea but to complain to the devs. I know lotsa things about this game, and can do almost anything there I want to. I can get xp, items, anything in no time, I have the experience. And now I even know almost every location I consider worthy. _I'm_not_doing_this_for_myself!_ I'm an experienced player, I can see not only what's good for myself, but what's good for the players in general. I just want this game to be as good as possible. I hope... I hope I'm not alone. _______________________________________________ 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 Apr 14 16:37:51 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] big world - big problems In-Reply-To: References: Message-ID: <407DAF2F.3090405@laposte.net> There has been talk about compass / stuff like that to let players know approximately their location. Seems no one yet took the time to implement that, though. 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 Wed Apr 14 17:11:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] Rings bug ... References: <200403142226.33943.eracclists@bellsouth.net><200403150205.52621.eracclists@bellsouth.net> <407CE9F7.5050504@sonic.net> Message-ID: <001c01c4226d$749ecb80$0100000a@archaios> This was reported long ago by Shiran on cf.mf I believe... -archaios ----- Original Message ----- From: "Mark Wedel" To: Sent: Wednesday, April 14, 2004 5:36 PM Subject: Re: [CF-Devel] Rings bug ... > ERACC wrote: > > On Sunday 14 March 2004 22:26 > > ERACC wrote: > > > > > >>Greetings, > >> > >>crossfire.metalforge.net: > >> > >>Character, poof, has several rings in apt to give to newbie > >>players. Picked up a Wis +2, then a Pow +2 and the Pow +2 MERGED > >>with the Wis +2! When I dropped them they became FOUR rings of Wis > >>+2. Then picked up a Pow +2 FIRST then a Wis +2 which THEN merged > >>with the Pow +2 and I had two more Pow +2 which I then dropped and > >>they became FOUR Pow +2. As far as I know right now I can repeat > >>this behavior at will. Did not try other combinations. > >> > >>Caveat: The becoming four rings MAY be my mind misremembering as > >>this happened several hours ago. But the merging I DO remember. > >> > >>Gene (aka poof, aka eracc) > > > > > > After further testing it appears the rings were also merging with > > other rings when I dropped them. That is why I thought they were > > doubling when I dropped them. All the +2 rings I had are now just > > Pow and Wis rings. Looks like something has hosed the merge code at > > least for these +2 rings. :-/ > > > > This is now fixed in CVS. > > > _______________________________________________ > 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 Apr 14 19:17:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:22 2005 Subject: [CF-Devel] broken map? (Port Joseph pier, /world/world_101_114) In-Reply-To: <1081738939.578.6.camel@oberon.kameria> References: <1081738939.578.6.camel@oberon.kameria> Message-ID: Thank you for fixing this. Just tested on cf.mf.net Players can now walk on the pier. However, they can't re-enter the boat. The water under the boat is: no_pass 1 On Mon, 12 Apr 2004, Todd Mitchell wrote: > fixed in CVS > my fault probably from resculpting the coast - the water was not > passable under the pier. > > On Sun, 2004-04-11 at 20:53, Rick Tanner wrote: > > This was discovered on cf.mf.net > > > > On map /world/world_101_114 (the pier of Port Joseph), players can't walk > > on the pier for some reason. They are "stuck" their, unable to move at > > all. _______________________________________________ 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 Apr 15 14:28:32 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Possible item price bug Message-ID: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> I think there is a bug in the function query_cost() for high priced items: the graph of the adjusted price is not a continuous function (see red function in attached image). I.e. you will get the "real" price for items up to 25000; for higher priced items you will get about 11000 only. What is the "right" fix for this problem? 1. Decrease the limit from 25000 to 10000 (green function in image). (Maybe this was the case some time ago because this makes the existing adjustment function continuous and the comment for query_cost() mentions "10000".) 2. Modify the adjustment function (blue function in image). 3. Leave it as is (red function in image). -------------- next part -------------- A non-text attachment was scrubbed... Name: adjusted_price.png Type: image/png Size: 5317 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040415/ff9e7232/adjusted_price.png -------------- 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 Fri Apr 16 00:07:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Sound proposal In-Reply-To: <407D0368.6040603@laposte.net> References: <407D0368.6040603@laposte.net> Message-ID: <407F6A29.5070407@sonic.net> Nicolas Weeger wrote: > Hello. > > There has been some discussion about sound support. > If no one works on it, i'll fix it, and try to improve. > > Here's how I see the stuff: > > * add a new line for archetypes, 'sound , , > ' > with something like 'cast, die, move', you get the clue Do you intend to have support for more than one sound file for the same logical event (eg, two different deaths sounds, and when one is required, it chooses randomly)? If so, what is the syntax for that. Also, unless the commas are needed for something, I'd just assume to leave them out - extra punctuation probably only really adds confusion. In addition, I think that an english text description is needed, that denotes what the sound sounds like. Thus, in the case of a death sound, it may be 'horrible cry'. Thus, if the client doesn't have sound, or the user is deaf, the client could display something like 'You hear a horrible cry'. > > * put .raw files with archetypes > > * assign generic sounds to archetypes. Ex: goblin archetype gets a > 'sound die, goblin_horrible_death' line > > * change collect.pl to copy .raw files to crossfire/share/sounds (or > wherever we want) and generate a /share/arch_sounds file containing a > simple list with filenames > > * server will then read this file, give a unique identifier to each > sound. When loading archetypes, link sound_event to that identifier Presumably, a lot of that would follow the same general logic as the image type code? Note that for the images, it is part of the collect process that assigns numbers to each image. > > * client can request arch_sounds file, then individual sound files (like > 1024 bytes by 1024 bytes) > > * when a sound event needs to occur, server just sends the unique sound > identifier > > Client can then have a sound cache, based on filename. All looks OK. > > An extension which could be nice: allow map-specific sounds. Like a > special sound when your mega-monster dies :) > > I'd see this this way: > * add sounds in same directory as map file, or in a sound subdir > (whatever). This way, we know which sounds go with which maps. Also, > give a unique sound to the file - like _.raw > > * at some point, collect the sounds, and copy'em to the same directory > as other sounds from archetypes > > * override sound event on object from archetype, as any other field I'd just assume not do this - it creates a lot of work - if you really want something like that done, it should be outside the server code, and instead part of the collect script (eg, it could examine the maps directory looking for sounds). However, I'd think that this would generally not be especially popular, given it is sure to increase the amount of time it takes to collect the various bits. I also wonder how likely it is that new sounds will show up that just can't get plopped into the arch directory. I just can't see new sounds showing up so often that putting them in the arch directory and running collect would be much an issue. If someone is running their own server, they could just manually collect the sounds if they have added some custom ones (the collect script, btw, should deal with sounds liek it deals with images - it doesn't care that they are referenced, it just looks for suffix. Eg, the collect script considers anything that ends with %d%d%d.png as an image file. Similarly, anything that ends in .raw should be considered a sound file. Thus, you could have a directory in the arch area just called 'sounds', to toss in these sounds from maps, or other generic sounds that you still want collected (ideally, there shouldn't be many hard coded events, but there is likely to be a few of them). Thus, may also want something like .snd files that describe sound events, eg, something like: So that you can specify the login event, logout event, etc. Now personally, I don't really see much reason for the server to store the sound files and serve them - as said above, I can't see sound files changing that much. What would make more sense to me is that the sound files (and description) are in the arch directory as described. When collect runs, it finds all the sounds files and generates a soundlist file, which has 'unique_id sound_file' type syntax (see bmaps). However, it does not collect the sound files itself. Instead, the client collects the sound files, and the collected sound files are shipped with the client (perhaps even in CVS, although it would seem odd to have two copies of the same file in CVS). The client requests that sound_list at startup - if it has a sound file, great, if it doesn't, probably not a horrible loss (and the user could grab it if they wanted to). I say that in that I just don't see new sounds showing up that often, and that it is not likely that missing a sound will be a critical event (like missing an image could be). It'd seem that not having the server do the sound stuff simplifies it, and saves bandwidth and other resources on the server. _______________________________________________ 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 Apr 16 00:24:59 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] big world - big problems In-Reply-To: References: Message-ID: <407F6E2B.3030608@sonic.net> As a developer, let me make some comments. The developers make no money on crossfire. IF I was getting paid for the work, and probably true of other developers, we'd tend to be more responsive - simply on the basis that to get paid, we'd have to sell the project. But as part of that, it'd probalby mean we'd have to do things that we don't want to do (stupid idea, boring to do, etc). And as part of that, development model of crossfire does not match commercial development very much (we'd have a paid QA department we could send the code to, dedicated playtesters, etc). Since we don't have those, it is much easier to make something a test server,and let the players find the bugs. Unfair to players? Perhaps. But no one is forcing you to play on a particular server. I'll note that those people that run servers are really spending some amount of money in the process - power, bandwidth, hardware, etc So that said, pretty much all features added to crossfire are features the developers think are good. Most undergo discussion on the mailing list (including the change to bigworld) and if they do not gain popular support, are not added. Most undergo some level of testing. What that means is that if someone says 'XYZ is really stupid', you are pretty much insulting the feature that some developer added. And the natural reaction from the developer will be 'XYZ is not stupid, and here's why'. That said, there are certainly areas for improvement. What I'd say is to include some positive ideas of what to change. If a message (as I perceive it) seems to be 'XYZ is broken, why did you ever do it, change it back', there isn't much a response I can make. If you instead say 'XYZ has some issues. Here are some ideas to make it better/fix it', you're much more likely to get some positive responses, and likewise some action (those ideas may be instituted) _______________________________________________ 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 Apr 16 00:34:45 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Possible item price bug In-Reply-To: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> References: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> Message-ID: <407F7075.2010906@sonic.net> Andreas Kirschbaum wrote: > I think there is a bug in the function query_cost() for high priced > items: the graph of the adjusted price is not a continuous function (see > red function in attached image). I.e. you will get the "real" price for > items up to 25000; for higher priced items you will get about 11000 > only. > > What is the "right" fix for this problem? > > 1. Decrease the limit from 25000 to 10000 (green function in image). > (Maybe this was the case some time ago because this makes the > existing adjustment function continuous and the comment for > query_cost() mentions "10000".) That is probably the right approach - there is already too much money in the game anyways, so cutting down a little bit more probably isn't a bad idea. _______________________________________________ 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 Apr 16 08:42:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_Sound_proposal?= Message-ID: I think the way the images are handled is pretty smart and sound should follow the same sort of system. This makes it really easy to customize at the server or the client level but allows for server admins to just ignore it and use the precollected packages too. One thing sound should have 'sets' like graphics have sets so that the client can choose which set to play with. This would let you have small sound files collection for the modem users and large soundfiles for people who want them - or even a creepy or a zany set of sounds. IMHO anyway. _______________________________________________ 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 Apr 16 11:34:04 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Re: Possible item price bug In-Reply-To: <407F7075.2010906@sonic.net> References: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> <407F7075.2010906@sonic.net> Message-ID: <20040416163404.GA12072@idefix2.dvlp.in-medias-res.com> Mark Wedel wrote: > Andreas Kirschbaum wrote: > >I think there is a bug in the function query_cost() for high priced > >items: the graph of the adjusted price is not a continuous function (see > >red function in attached image). I.e. you will get the "real" price for > >items up to 25000; for higher priced items you will get about 11000 > >only. > > > >What is the "right" fix for this problem? > > > > 1. Decrease the limit from 25000 to 10000 (green function in image). > > (Maybe this was the case some time ago because this makes the > > existing adjustment function continuous and the comment for > > query_cost() mentions "10000".) > > That is probably the right approach - there is already too much money in > the game anyways, so cutting down a little bit more probably isn't a bad > idea. OK, applied to CVS. (After some more checking I realized that the numbers 10000/25000 are "internal units" used in query_cost(). They correspond to 800pp/2000pp. So this change has an effect to items in the 800..2000pp range only.) _______________________________________________ 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 Apr 16 16:14:13 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Client release? Message-ID: <40804CA5.40201@laposte.net> I was wondering whether it wouldn't be nice to release client v 1.6.2. Win32 had scripting & sound fixed (need to convert raw to wav, but not that a big deal), which are pretty big fixes... 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 Apr 16 18:33:52 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Possible item price bug In-Reply-To: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> References: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> Message-ID: On Thu, 15 Apr 2004, Andreas Kirschbaum wrote: > I think there is a bug in the function query_cost() for high priced > items: the graph of the adjusted price is not a continuous function (see > red function in attached image). I.e. you will get the "real" price for > items up to 25000; for higher priced items you will get about 11000 > only. > > What is the "right" fix for this problem? > > 1. Decrease the limit from 25000 to 10000 (green function in image). > (Maybe this was the case some time ago because this makes the > existing adjustment function continuous and the comment for > query_cost() mentions "10000".) > > 2. Modify the adjustment function (blue function in image). > > 3. Leave it as is (red function in image). > Indeed, this is a bug. server/shop.c 148: /* Limit amount of money you can get for really great items. */ if (flag==F_TRUE || flag==F_SELL) { if (val/number>25000) { val=8000+isqrt((int)val/number)*20; val *= number; } } My suggestion: /* Limit amount of money you can get for really great items. */ if (flag==F_TRUE || flag==F_SELL) { if (val/number>PRICE_LIMIT) { val=isqrt((int)val/number)*2*isqrt(PRICE_LIMIT)-PRICE_LIMIT; val *= number; } } One can define PRICE_LIMIT here or even in the config.h if desired. These functions are not only continuous but even more important here, monotonic increasing. They are also differentiable, meaning they bend away smoothly from the linear function. On choosing PRICE_LIMIT : 10,000 : linear until 800 pt 2,000 pt -> 1728 pt 4,000 pt -> 2776 pt 20,000 pt -> 7,200 pt 40,000 pt -> 10,512 pt 25,000 : linear until 2000 pt 4,000 pt -> 3,656 pt 20,000 pt -> 10,640 pt 40,000 pt -> 15,872 pt 10,000 silver are 200 pt. ,but all prices are multiplied by 4. _______________________________________________ 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 Apr 16 22:43:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Divine shock, et al. Message-ID: <003d01c4242e$16f33670$0100000a@archaios> It has come to my attention that divine shock is a pitifully weak spell. At level 15, I am virtually unable to kill even basic creatures, such as skeletons, with it. Despite the fact it is a "level 1" praying spell, level 12-13 (approx.) is required to obtain it from Sorig. By comparison, banishment, which is denied to Sorig followers, is far more powerful. Given that god-given spells are meant to be more powerful -- due to their rarity -- irrespective of level, the wc -30 it has been assigned on poof's request is still too low. Moreover, it was once far more powerful again; the reduction in power has been severe and quite noticable. The sparseness of spells given by Sorig is another contributing factor; thus, I propose a change of the wc of the archetype for divine_shock to -45. Attached is a patch. Banishment's wc is -40. Suggestions, input requested -- perhaps a change in the spell's level, or the GR consumed is warranted in addition? At the moment, the spell is near-useless for low level characters. -archaios -------------- next part -------------- A non-text attachment was scrubbed... Name: archetypes.diff Type: application/octet-stream Size: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040417/022eb348/archetypes.obj -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Apr 17 02:00:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Sound proposal In-Reply-To: References: Message-ID: <4080D622.6010408@sonic.net> Todd Mitchell wrote: > I think the way the images are handled is pretty smart and sound should > follow the same sort of system. This makes it really easy to customize at > the server or the client level but allows for server admins to just ignore it > and use the precollected packages too. One thing sound should have 'sets' > like graphics have sets so that the client can choose which set to play with. > This would let you have small sound files collection for the modem users and > large soundfiles for people who want them - or even a creepy or a zany set of > sounds. Note that ideally, the sound files shouldn't change very often, and thus the size of them should be less an issue (download once and not again). I do wonder if having different sets is a good idea - it would seem to dilute effort - now granted, I'm not sure how the new sounds show up (people composing them, people gathering them, whatever). But I'd also make the case the alternate sounds can be handled much easier than alternate images - as I've said before, if you are missing a few sounds, its hardly the end of the world. Thus, you could just as easily have a different directories for the different sounds, and the client user just says which one to use (sounds-standard, sounds-eerie, 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 Sat Apr 17 02:11:17 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Divine shock, et al. In-Reply-To: <003d01c4242e$16f33670$0100000a@archaios> References: <003d01c4242e$16f33670$0100000a@archaios> Message-ID: <4080D895.5010600@sonic.net> David McIlwraith wrote: > It has come to my attention that divine shock is a pitifully weak spell. At > level 15, I am virtually unable to kill even basic creatures, such as > skeletons, with it. Despite the fact it is a "level 1" praying spell, level > 12-13 (approx.) is required to obtain it from Sorig. By comparison, > banishment, which is denied to Sorig followers, is far more powerful. Given > that god-given spells are meant to be more powerful -- due to their > rarity -- irrespective of level, the wc -30 it has been assigned on poof's > request is still too low. Moreover, it was once far more powerful again; the > reduction in power has been severe and quite noticable. The sparseness of > spells given by Sorig is another contributing factor; thus, I propose a > change of the wc of the archetype for divine_shock to -45. Attached is a > patch. Banishment's wc is -40. wc is only relevant for it actually hitting the target. Is that so much the problem, vs it not doing enough damage/lasting long enough/etc? It may very well be that the change to make is to increase the dam, or decrease teh dam_modifier value so that damage goes up faster. At least at low levels, I can't see a wc of -30 vs -40 being all significant (creatures that low aren't going to have that low an ac anyays). So I think changing the wc isn't likely to make any signficant improvement for the spell. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sat Apr 17 03:08:49 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] Divine shock, et al. References: <003d01c4242e$16f33670$0100000a@archaios> <4080D895.5010600@sonic.net> Message-ID: <013e01c42453$371d9e70$0100000a@archaios> Agreed, though I had issues with it hitting monsters as well (sorry if I wasn't explicit enough). The wc, as-is, is not low enough IMHO. -archaios _______________________________________________ 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 Apr 17 20:42:15 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:23 2005 Subject: [CF-Devel] some spells weirdness Message-ID: <20040417224215.4910c257.kstenger@montevideo.com.uy> hi all, i'm just posting some weird things players have made me notice today: -the movement of objects caused by spells is also able to move an earth wall from it's place, not sure if this one effect is intended, but my logic tells me it shouldnt, maybe making the walls weigh more or do a check for the object not beeing a wal before pulling it would be nice. -the create bomb spell seems to be less powerful than before, a player with level 33 in pyromancy told me to have great problems to kill a cyclops with them. -the charm monsters spell shouldnt give xp in the moment you charm a monster too instead of just turning the monsters your pets and wait for them to kill a monster to give you some xp? i think it should at least give a fraction of the total monster's xp, but that's just my thought abput it :) 'til next time. Katia. -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ 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 Apr 18 01:16:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <20040417224215.4910c257.kstenger@montevideo.com.uy> References: <20040417224215.4910c257.kstenger@montevideo.com.uy> Message-ID: <40821D46.6070507@sonic.net> Karla Stenger wrote: > hi all, > i'm just posting some weird things players have made me notice today: > > -the movement of objects caused by spells is also able to move an earth wall > from it's place, not sure if this one effect is intended, but my logic tells me > it shouldnt, maybe making the walls weigh more or do a check for the object not > beeing a wal before pulling it would be nice. Well, earthwalls are not walls per se. Something that is a wall is basically impeneterable and industractable. Earthwalls actually more closely resemble monsters, in that they have hp, and can be killed. However, I agree that there should be a check to see if the type is an earthwall, and if so, don't move it along. > > -the create bomb spell seems to be less powerful than before, a player with > level 33 in pyromancy told me to have great problems to kill a cyclops with > them. Probably true - many spells got changed in power when redone - this is simply due to the way damage and so forth is calculated. However, the more relevant question is whether the spell is not out of whack with respect to other spells. that is to say, having something less powerful than before isn't necessarily a bug (I'd hate for that to be the case, because it'd mean nothing could ever get weakened). Perhaps an alternative is to add something like a 'greater bomb spell' - at some level, it is difficult to make an individual spell completely balanced for the complete range of levels. For example, if (or maybe it already is) burning hands turned out not to be all that useful after about level 20, I'd have no issue with that - after all, burning hands is a first level spell - one could make the case that it shouldn't be useful against a level 50 monster. > > -the charm monsters spell shouldnt give xp in the moment you charm a monster > too instead of just turning the monsters your pets and wait for them to kill a > monster to give you some xp? i think it should at least give a fraction of the > total monster's xp, but that's just my thought abput it :) I take it you mean to say that the charm monster spell should give xp the moment the monster is charmed? This could be done, but is a bit different in that the model for most all spells is you get exp when it causes death. Eg, we don't give exp for successfully casting a cure wounds spell for example. One problem I see with giving some amount of monster exp when spell is cast is abusiveness - Probably much easier/faster to charm a bunch of monsters and not have them kill anything vs having to charm them and then finding them something to kill (eg, go into room full of monsters, cast a bunch of charms, get exp, and just leave) _______________________________________________ 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 Apr 18 01:42:45 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] God-given prayers In-Reply-To: <404E4E4E.1080801@laposte.net> References: <404E4E4E.1080801@laposte.net> Message-ID: <40822365.80604@sonic.net> Nicolas Weeger wrote: > Hello. > > On cf.mf.net, a player has 2 times 'wall of thorns', one spell, one force. > From the code & such, it seems the force used to be special prayer marker. > A change from Mark (2003-11-09) changed that force to use 'startequip'. > > But still find_special_prayer_mark (apply.c) and check_special_prayers > (gods.c) use the force, with 'slaying == special prayer', to check those > prayers. > > So I guess the force for the player can be removed, and probably the > code should be fixed? :) Yeah - I don't know why I left that original marking code there - perhaps for backwards compatbility. It was certainly broken, in that learning a special prayer no longer put a marker into the player. This would basically mean that if you switched gods, you probably weren't losing any special spells you had either. I've fixed up the code now. _______________________________________________ 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 Apr 18 01:55:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] Item bugs. In-Reply-To: <20040322183911.GT15455@laranja.org> References: <20040322072826.GP15455@laranja.org> <20040322183911.GT15455@laranja.org> Message-ID: <40822667.1010000@sonic.net> Lalo Martins wrote: > I checked the source again and I'm 111% sure it's behaving > exactly as intended - cumulative bonuses and never on str. > > If I understand it correctly, however, and comparing it with the > Weapons of Occidental Mages, the catch is that the "bonus" > should be able to be negative to, so if you get +30 you're > *really* very lucky. The version of the script attached does > just this. > I've applied your patch for the rings. But looking at the weapon, it seems to have a similar problem - it is twice as likely to get a positive bonus (dam +10) as a negative bonus. Thus, in the long run, you'd likely end up with a weapon with a very high positive damage. I was going to modify it so that it increased/decreased the magic of the weapon, but it doesn't seem that there is the plugin glue currently in place to adjust the magic value of an item. _______________________________________________ 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 Apr 18 02:13:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] Item bugs. In-Reply-To: References: Message-ID: <40822AB1.3060500@sonic.net> Palfy Tamas wrote: > > Second, once I found 10 cursed Cloaks of Acid Proofing in the shop. I > uncursed one and am keepingthe rest, here is their stats: > > That is cloak of Acid Proofing * (Int-2)(item_power +3)(resist acid +130) > It is made of: astolare. > The resist acid +130 is obviously a problem. I'm not 100% how this happened. But I see that cloaks of acid proofing normally have resist_acid 65. So my guess is that a clever player took some cloaks of acid proofing, and then did the same transformation again, basically doubling the bonus (65 * 2 = 130). This actually is a bit of a problem - the artifact code itself doesn't do any bounds checking (hence, resist +130). But even if we put in bounds checking for that, imagine abuse in terms of other recipes (eg, an artifact that increases a stat, just keep making that item over and over on itself, and now its a +30 stat item). The artifact grant code is basically presuming that it will only be called once for any item, and that the values set in the artifact file itself are sane. I'm not positive the fix - one thing would certainly be to change the artifact code so that item_power is cumulative (so those cloaks would have an item_power of 6). However, the may still not fix the problem. Another idea is to do additional checks on the starter item, eg, don't allow something that is already an artifact to be the object that is improved further. This may reduce the fun of alchemy some, but is probably the safest approach. _______________________________________________ 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 Apr 18 02:28:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] Green Chaos wyverns = bad In-Reply-To: <405E7C31.3070409@cox.net> References: <40565B17.4050307@cox.net> <40576EFC.6030407@cox.net> <405E7C31.3070409@cox.net> Message-ID: <40822E1A.2080802@sonic.net> Brian Angeletti wrote: > Brian Angeletti wrote: > >> The chaos quest maps in the Lake Country feature several wyverns of >> chaos that are stunningly GREEN! This is not preferred since we >> already have a wyvern of chaos arch now that is a black wyvern. If we >> replace them, we don't have to manually graft in the chaos spells >> since they already are built into the wyvern of chaos arch, > > > > Possible patch: http://emperorbma.tripod.com/snakepit_3.diff > > Please test and verify that it doesn't break the area. Did a cursory look - it seems fine, so I applied it. _______________________________________________ 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 Apr 18 02:31:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] bugfix: triggers and firewalls In-Reply-To: References: Message-ID: <40822EE9.6070906@sonic.net> Bernd Edler wrote: > This patch will fix two timing bugs: > > 1. Firewalls always cast their spell once every second tic. > Casting time is supposed to be defined by "speed". > > 2. Triggers ignore their reset delay time. Looks good - applied to CVS. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Apr 18 02:51:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] image bug #2 (large images) In-Reply-To: <1081078105.592.80.camel@oberon.kameria> References: <1081078105.592.80.camel@oberon.kameria> Message-ID: <40823365.4040606@sonic.net> Todd Mitchell wrote: > Here is the other bug I discovered with large images. > Large images are placed behind other objects. > This really looks odd and destroys the game illusion. I am not sure how > two large images should interact properly but objects should be placed > behind creatures anyway. If a large monster image crosses a large > building image I think if the head is not crossed it renders properly. This is much more difficult to deal with. The basic problem is that there is a limited number of map layers to deal with. At some point, I basically need to redo the map layering logic. The bigimage stuff made life much more complicated. The reason this is so is because only the 'head' of the bigimage object is set. So if on that space, it is something like 'sand, big monster', the big monster is in the middle layer. But if in the middle of the creature, you have something like 'sand, chair, dagger', the dagger is at a higher level, so is drawn on top of the creature. That one is hard to fix, other than to say not draw the dagger. Two bigimages interfact properly if on the same space - this is because the order may be something like 'sand, shop, cyclops', and so cyclops is not on the proper layer. What I probably need to do on the server side is basically same as on the client - add more layers - have 3 for the big images, and 3 for normal objects - thus, the processing and interaction is much easier. Along with that, probably redo the protocol to be able to send those layers as they are, eg, layers 1-6, so that the client has it easier also. But that is a little further off. _______________________________________________ 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 Apr 18 03:40:46 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] New protocol command: map2 Message-ID: <40823F0E.1020503@sonic.net> As per mail sent earlier this evening about map layering, I quickly wrote up the idea for a map2 command, which is much more extensible and should clean up some of the existing code nicely (basically does away with the need for the mapextended command): S->C: map2 ... This is an update of the map1 commands above. It is meant to be extensible. It is also meant to incorporate the ideas of the extended map info command. All data is in standard binary form. The coord value is 16 bites. the coord values are length + x + y values. The data represented looks like this: first 5 bits: The x coordinate (0-31) next 5 bits: the y coordinate (0-31) last 6 bits: the number of type/data pairs to follow (0-63). While a limit of 63 data encodings is hard coded, I can't forsee reaching that limit anytime soon - remember, this is the number of type/data pairs that are sent for this space - there could be cases where there are 300 things on the space, but if we are only sending 63 of them this is also fine. This is a single byte of data. This describes the data that is to follow. The top 3 bits (len) denote the number of bytes that follow - it is possible that this is zero, to denote all the relevant information is included in the type. If this is 7 (all bits set) then the following byte is an additive length value. The bottom 5 bits is the type of data - this allows for 31 different types of data (0-31/0x0-0x1f). The meaning of the data itself depends on what the type is. List of various types: 0x0: Denotes this space should be cleared. Length in this case should also be zero, as there is no data that follows. 0x1: Darkness information - typically a single byte follows that denotes how dark the square is. 0x2: Sound? 0x10-0x17: Image information - 2 or 3 bytes follow, which is the image for the particular layer. Layer 0x10 is the lowest, 0x17 is the highest. If 3 bytes follow, the first byte is smoothing information, followed by 2 bytes for the face. If only 2 bytes follow, then this is only the face. The number of bytes that follow is determined by the len field above. Some notes: Coordinates outside the viewable may (as requested by the client) may be sent. In these cases, it means that a big image that extends onto the viewable map is on that space. For big images, only the bottom right coordinate is sent - this is why it may be off the viewable coordinates. For such spaces, only the actual big image itself will be sent for that space. Note that unless the 0x0 code to clear the space is sent, all operations are considered updates to the space (eg, new image, new light level, etc) Relative to the map1/map1a commands, this is more bandwidth intensive - basically, an additional byte is needed for each piece of data sent. Thus, on a 25x25 map, if we presume 1.5 objects/space, this is an extra 940 bytes to send. OTOH, typically the entire map is not being sent - only those bits that change, so this may not be as costly as that. If the player is using smoothing, this may actually save bytes, as the redundant coordinates and type/length information does not need to be sent. With the map2 command, the mapextend command is deprecated and is not used. -- I put Sound is as a question mark, as if sound is added enough, it could make sense to include that on the map instead of explicity using protocol commands. The other thought is that this can also get extended - one of the ideas I've long had is that instead of sending darkness for each space, we send brigtness (eg, that space has a 3 glow radius, that has a 6 glow radius, etc), and thus the client can more easily do the shading. With that logic, one could even extend the lighting to have different color light sources (eg, 4 radius, red, 2 radius green, etc). The main point being that there are still bunches of types available - it would seem hard to use up the remaining 20 or so types. However, my other ideas was to remove the len, and instead have the full 8 bits for types. The number of data bytes to follow would be based on the type itself. This does mean that the client and server have to be on the same page for that type of thing (eg, if the server sent a type the client didn't understand, there would be issues). However, that doesn't seem like much a stretch - if the client doesn't understand a type, it probably doesn't want the wasted bandwidth receiving that data. _______________________________________________ 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 Apr 18 08:50:16 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <40821D46.6070507@sonic.net> References: <20040417224215.4910c257.kstenger@montevideo.com.uy> <40821D46.6070507@sonic.net> Message-ID: <1082296216.972.2.camel@hawk> > > -the charm monsters spell shouldnt give xp in the moment you charm a monster > > too instead of just turning the monsters your pets and wait for them to kill a > > monster to give you some xp? i think it should at least give a fraction of the > > total monster's xp, but that's just my thought abput it :) > > I take it you mean to say that the charm monster spell should give xp the > moment the monster is charmed? > > This could be done, but is a bit different in that the model for most all > spells is you get exp when it causes death. Eg, we don't give exp for > successfully casting a cure wounds spell for example. > > One problem I see with giving some amount of monster exp when spell is cast is > abusiveness - Probably much easier/faster to charm a bunch of monsters and not > have them kill anything vs having to charm them and then finding them something > to kill (eg, go into room full of monsters, cast a bunch of charms, get exp, and > just leave) I would expect charm monster to be the spell equivalent of oratory, which, last I checked, does give xp when you charm the monster. Unless it really is a problem, it would be nice to keep that parallel. --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 Sun Apr 18 12:25:37 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <> References: <20040417224215.4910c257.kstenger@montevideo.com.uy> <200404181312.40633.Avion <>> Message-ID: <200404181325.37923.Avion <>> Just by way of further explanation - one reason I think adding weight to the wall object is the proper way to do this is that different wall spells could be of different weights so you would have more options. You could have a wall of smoke that is quite easy to blow away with a windstorm, or a wall of stone which is pretty much immobile (well maybe a level 90 wave of water would move it?). Naturally you could have a heavy wall of a light object by customizing the arch (say for a fire wall you want to be very strong) as well. It seems more flexable this way but of course it would be easy to do an additional check for a wall flag and abort the knockback effects if that is the consensus. _______________________________________________ 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 Apr 18 12:12:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <20040417224215.4910c257.kstenger@montevideo.com.uy> References: <20040417224215.4910c257.kstenger@montevideo.com.uy> Message-ID: <200404181312.40633.Avion <>> On April 17, 2004 09:42 pm, Karla Stenger wrote: > hi all, > i'm just posting some weird things players have made me notice today: > > -the movement of objects caused by spells is also able to move an earth > wall from it's place, not sure if this one effect is intended, but my logic > tells me it shouldnt, maybe making the walls weigh more or do a check for > the object not beeing a wal before pulling it would be nice. > This is my fault and cone spell knockback changes may be causing effects I didn't anticipate like this. I think making the wall weigh more is the proper thing to do as a very powerful spell should IMHO be able to push an earth wall. If this seems reasonable I'll set walls at the same weight as heavy bolders. _______________________________________________ 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 Apr 18 17:36:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <40821D46.6070507@sonic.net> References: <20040417224215.4910c257.kstenger@montevideo.com.uy> <40821D46.6070507@sonic.net> Message-ID: <20040418193623.0a426725.kstenger@montevideo.com.uy> > I take it you mean to say that the charm monster spell should give xp the > moment the monster is charmed? right > This could be done, but is a bit different in that the model for most all > spells is you get exp when it causes death. Eg, we don't give exp for > successfully casting a cure wounds spell for example. > > One problem I see with giving some amount of monster exp when spell is cast > is > abusiveness - Probably much easier/faster to charm a bunch of monsters and not > have them kill anything vs having to charm them and then finding them > something to kill (eg, go into room full of monsters, cast a bunch of charms, > get exp, and just leave) just as a matter of comparison, the prayer peace comes to my mind as a spell able to do exactly what you say... but my point is that the "real work" of the summoner is done while charming a monster, and it would sound fair to me that the experience is given by doing that work... and maybe doing so will give summoners an easier way to go. right now if you run into a room full of monsters those monsters usually have pretty similar protections and spells, so waiting for your charmed pets to kill such similar monsters might get you a long while. Since your charmed pets can kill other monsters for you after charmed i said to give just a part of the xp when the monster is charmed, and so you would also like to wait and see if your pet can kill another monster and get some more xp. just my point of view anyway :) -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ 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 Apr 18 23:28:34 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <20040418193623.0a426725.kstenger@montevideo.com.uy> References: <20040417224215.4910c257.kstenger@montevideo.com.uy> <40821D46.6070507@sonic.net> <20040418193623.0a426725.kstenger@montevideo.com.uy> Message-ID: <40835572.1050309@sonic.net> Karla Stenger wrote: > just as a matter of comparison, the prayer peace comes to my mind as a spell > able to do exactly what you say... but my point is that the "real work" of the > summoner is done while charming a monster, and it would sound fair to me that > the experience is given by doing that work... and maybe doing so will give > summoners an easier way to go. right now if you run into a room full of monsters > those monsters usually have pretty similar protections and spells, so waiting > for your charmed pets to kill such similar monsters might get you a long while. > Since your charmed pets can kill other monsters for you after charmed i said to > give just a part of the xp when the monster is charmed, and so you would also > like to wait and see if your pet can kill another monster and get some more xp. > > just my point of view anyway :) Ok. It seems that people think that you should get exp. So the next question is - does this hold true for all spells that change the creatures mood (turn undead, siren call, pacify, conflict, etc), or just charm monsters in particular? And should the player get full monster exp, or just some portion of it? _______________________________________________ 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 Apr 18 23:35:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <>> References: <20040417224215.4910c257.kstenger@montevideo.com.uy> <200404181312.40633.Avion <>> Message-ID: <408356FE.2070200@sonic.net> Avion wrote: > On April 17, 2004 09:42 pm, Karla Stenger wrote: > >>hi all, >> i'm just posting some weird things players have made me notice today: >> >> -the movement of objects caused by spells is also able to move an earth >>wall from it's place, not sure if this one effect is intended, but my logic >>tells me it shouldnt, maybe making the walls weigh more or do a check for >>the object not beeing a wal before pulling it would be nice. >> > > This is my fault and cone spell knockback changes may be causing effects I > didn't anticipate like this. > I think making the wall weigh more is the proper thing to do as a very > powerful spell should IMHO be able to push an earth wall. If this seems > reasonable I'll set walls at the same weight as heavy bolders. My concern here is things like weak walls, which are basically same as earthwalls - it doesn't make sense for them to be pushed back (it wouldn't look right) - if anything, if there is so much force in the spell, it should end up destroying the object. Think of those walls you hack through - you start with something like: --+-- (+ being the weak portion). So you are south of that wall, and cast the spell, and get something like + -- -- which would be pretty bizarre looking, and doesn't make a lot of sense (as the weak wall itself would still have the crisp lines where it is supposed to meet up with the actual wall. I suppose for those walls, you could set an incredibly high weight. But it would just seem that if there is something powerful enough to be moving a wall back, the wall would get destroyed in teh process (individual bricks broken out, or hunks or earth, etc). So having it destroy earthwalls (or damage them) probably makes more sense. Just a note - setting a heavy weight on all the earthwalls may create issues with some maps - if any maps currently have earthwalls on top of buttons, on the basis the earthwall doesn't way much, and thus the button isn't activated, setting a heavy weight for the earthwall will change it- the button would start activated. I don't know if there are any maps like this, but just a consideration. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 19 00:04:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:24 2005 Subject: [CF-Devel] client compile warnings In-Reply-To: <1081072233.595.59.camel@oberon.kameria> References: <1081072233.595.59.camel@oberon.kameria> Message-ID: <40835DD2.60502@sonic.net> Todd Mitchell wrote: > it's been a while since I built the client (gtk) but when I do (gcc > version 3.3.3 (Debian 20040320)) I get a few warnings but it doesn't > seem to be a problem. Just thought I'd let folks know about them. > > > > png.c: In function `rgba_to_xpixmap': > png.c:783: warning: `cmask' might be used uninitialized in this function > png.c:783: warning: `lastcolor' might be used uninitialized in this > function I don't think there were any actual errors here - other conditions have to be true before cmask and lastcolor might be referenced, and for those conditions to be true, I believe it would result in those fields being set by that time. That said, easy change to initialize those values anyways - just good practice. > gcc -g -O2 -DOSS_SOUND -Wall -I/usr/X11R6/include -I.. -I../common > -I. -c sound.c > gcc -g -O2 -DOSS_SOUND -Wall -I/usr/X11R6/include -I.. -I../common > -I. -c x11.c > x11.c: In function `get_root_display': > x11.c:2092: warning: passing arg 1 of `XSetErrorHandler' from > incompatible pointer type I've fixed this - thought I tried to fix it before, but had problems. Looking at the docs, only change that I had to make was the return type for the error handler. > gcc -g -O2 -DOSS_SOUND -Wall -I/usr/X11R6/include -I.. -I../common > -I. -c xutil.c > xutil.c: In function `insert_key': > xutil.c:247: warning: comparison is always false due to limited range of > data type That is harmless - there is code there that checks that the keycode is valid. It appears that the size of the type basically enforces that. I don't know if in the past, or some different systems, have a different sized data for the keycode, so it might be true on some systems. Or it could just be code leftover from long ago. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 19 02:04:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] map/image layers Message-ID: <40837A03.9040309@sonic.net> As part of my message about redoing the protocol, and fixing up other areas, I thought I'd share my thought about redoing the image/layering information. One problem with the current method is that objects move between layers, depending what other information is on the map. As an example, consider monster - would normally be in the middle layer, but if he stops on a space that has another object on it, he moves to the top layer, and then moves to the middle layer again. This is more acute when it comes to spells - spells generally are the top layer - which means that if a spell is cast on monsters, which are also on the top layer (because of extra items beneath them), they get moved down a layer. This causes extra problems with the big images, as there may be a singular object in the middle of the big object that then floats above the big image. So the thought is to have more layers defined - this is what I came up with, starting from the bottom: layer 1: Floor objects. layer 2: items - chairs, food, chests, etc. layer 3: Same as above, if more than 1 is present on a space. layer 4: creatures (monsters & players) layer 5: flying objects (Arrows, spells, or if a creature is flying, the creature itself) This adds some bandwidth - there are now 5 layers instead of 3. However, it would be uncommon for all 5 layers to be in use for any given space - most spaces will be as they are now - only a few images on it (floor, creature, maybe an item). The change here is that each layer has a defined meaning, so for example, the layers monsters are on won't change based on the map, spell effects, etc - they are always on layer 4. I include 2 layers for objects simply so nicer presentation is allowed, eg, the bottle on top of the table will be displayed properly (if there was only 1 layer for for images, then only the bottle would be displayed). Any thoughts? Would people see the need for more layers than this (at some level, you get diminishin returns, as objects will obscure other objects). _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 19 02:46:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] map/image layers In-Reply-To: <40837A03.9040309@sonic.net> References: <40837A03.9040309@sonic.net> Message-ID: <408383E7.50107@laposte.net> > Any thoughts? Would people see the need for more layers than this (at > some level, you get diminishin returns, as objects will obscure other > objects). Hum, the proposal sounds nice. I have only one concern, it's that it prevents having monsters under items. This means that you couldn't put an ant under a table (which would be their logical position, unless they climb the table). I know the code doesn't support that right now, but it's been talked about - redoing with 5 layers as you suggest would make it harder to tweak later... So my turn to suggest, but it may be a bigger change :) New fields 'altitude' and 'height' and 'max size to be under'. Usually we'll have 'altitude' == 'max size' (case of arrows for instance). A table will be (arbitrary units) 'altitude' = 0, 'max size' = 1, 'height' = 1.2 An ant with 'height' = .1 will go under the table. A troll with height = 2 will go over, thus altitude becomes 1.2 (climb on table; would be fun to have max weight resist table => table crumbles => monster gets hit :pp). That'll let us also have fun with walls - altitude = 0, max size under = 0, height = 3. A player with max_climb (another new field?) = .5 & height = 2 couldn't reach the top of the wall & thus couldn't go on the other side. Using current 3 layer approach, we'll be able to know what items to display - the three ones with higher altitude + height Not sure that'll solve all issues, but well. Just my 2 cents of ? :) Nicolas _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 19 09:54:41 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: =?iso-8859-1?Q?Re:_Re:_[CF-Devel]_map/image_layers?= Message-ID: I am not sure about a height value per se, but I did have a wish that we could do some sort of trickery with the y axis of the map and the graphic sizes so that objects and creatures would be obscured by the portion of an object that projects into the tile above. This means that an object moving into the tile above an objects 'footprint' would be obscured. Something like: YY tY t <- t is a tree Y is a behemoth t t <- t is a tree Y is an orc wwwY WWW <- W is full wall, w is half wall, Y is my PC, you have to imagine the effect when he walks behind the wall This would be pretty low cost I think (not needing extra layers) and add a lot of *look* to the game IMHO. _______________________________________________ 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 Apr 20 02:23:03 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] map/image layers In-Reply-To: <408383E7.50107@laposte.net> References: <40837A03.9040309@sonic.net> <408383E7.50107@laposte.net> Message-ID: <4084CFD7.2070401@sonic.net> Nicolas Weeger wrote: >> Any thoughts? Would people see the need for more layers than this >> (at some level, you get diminishin returns, as objects will obscure >> other objects). > > > Hum, the proposal sounds nice. > I have only one concern, it's that it prevents having monsters under items. > This means that you couldn't put an ant under a table (which would be > their logical position, unless they climb the table). I know the code > doesn't support that right now, but it's been talked about - redoing > with 5 layers as you suggest would make it harder to tweak later... > > So my turn to suggest, but it may be a bigger change :) > New fields 'altitude' and 'height' and 'max size to be under'. Usually > we'll have 'altitude' == 'max size' (case of arrows for instance). > A table will be (arbitrary units) 'altitude' = 0, 'max size' = 1, > 'height' = 1.2 > An ant with 'height' = .1 will go under the table. A troll with height = > 2 will go over, thus altitude becomes 1.2 (climb on table; would be fun > to have max weight resist table => table crumbles => monster gets hit :pp). > > That'll let us also have fun with walls - altitude = 0, max size under = > 0, height = 3. A player with max_climb (another new field?) = .5 & > height = 2 couldn't reach the top of the wall & thus couldn't go on the > other side. > > Using current 3 layer approach, we'll be able to know what items to > display - the three ones with higher altitude + height > > Not sure that'll solve all issues, but well. Just my 2 cents of ? :) Well, having a height/altitude for climbing, potential line of sight, flying over, etc, all makes sense, and in no way impacts the layer idea I mentioned. The problem I have with the height idea as you mention is that it seems it could make things fairly indeterminate. For example, you have a table of height 36". You have a dagger of height 2". Under the idea above, the dagger would always go under the table, since it is shorter. In many cases, that probably isn't what you want. So in that case, at best, the height information is only a hint. And now take the next case - have that table on a space, and the player drops a dagger. Does he drop it on the table, or on the ground (under the table). I'll admit I have no good solution to that problem - in terms of dropping stuff, there is probably no good solution. However, it seems to me the simpler approach is easier to deal. Now there is already a field called 'visibility', which is used in same cases. I'd have no issue saying that level 1 has visiblility <30, layer 2 has 31-60, layer 3 has 61+, or whatever. What needs to be avoided is and object changing the layer it is on based on other items on the map. This causes signicant problems right now with big images/multi part archetypes. Imagine a 2x2 monster, like: AB CD there are real problems right now where part A may be on layer 1, and part B on layer 2 (due to other objects). Since only part D is sent, do we say it is layer 1, layer 2, or whatever layer part D happens to be? In pretty much all cases, this resultings in drawing issues - if you say layer 2, it may now obscure things that should be on top of it. If you say layer 1, there may now be things on top of it that shouldn't be. If we can say the entire object will always be on layer X, this makes things work out much better. > > 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 Tue Apr 20 02:32:07 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] map/image layers In-Reply-To: References: Message-ID: <4084D1F7.10606@sonic.net> Todd Mitchell wrote: > I am not sure about a height value per se, but I did have a wish that we > could do some sort of trickery with the y axis of the map and the graphic > sizes so that objects and creatures would be obscured by the portion of an > object that projects into the tile above. This means that an object moving > into the tile above an objects 'footprint' would be obscured. Something like: What you describe should work if the drawing code wasn't broken. The drawing code is broken because of some of hte layering issues. The reason a tree won't obscure the monster behind it is because it may be on the wrong logical layer (eg, it is on layer 1, the monster 'behind' it is on layer 2, so is drawn on top of the tree instead of behind it). However, more I think about it, I'm not sure if there is a foolproof solution. The ideal drawing method is that you draw left to right, top to bottom, and draw each space completely before moving into the next. And when it comes to big images, you just make one draw operation, at the space it shows up, which results it being drawn over the spaces to its left and above it (properly obscuring them). This would actually work fine. The problem now is that such a system makes it impossible to ever draw a small object on top of a big object (for example, spell effects) - when the big image is drawn, it would obscure the spell effect already drawn. This may actually be more proper in terms of perspective (eg, the torso of a tall monster would seem to be above the spell effect). And it certainly would have the effect of things like tall walls obscuring the creature behind it. _______________________________________________ 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 Apr 20 18:13:14 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] Player enhanced weapon problem? Message-ID: <200404201813.14851.eracclists@bellsouth.net> Greetings developers, On crossfire.metalforge.net I have created a new character, Galahad. He is Human/Paladin/Lythander. He is now level 18 in "two handed weapon" skill. He is supposed to be able to "...handle 10 weapon improvements." Galahad used Prepare Weapon and 100 diamonds to prepare a "Bonecrusher +3" for 10 Enhancements. He then gave the Bonecrusher these stats: That is Galahad's Bonecrusher +4 (Str+3)(Dex+2)(Con+1)(dam+50) (improved 9/10)(item_power +13)(weapon speed 13)(slay skeleton) (Attacks: physical) It is made of: granite. It goes on your arm (2) It weighs 96.000 kg. The order was Str-Str-Str, Dex-Dex, Con, Enchant Weapon, Lower Weapon Weight, Lower Weapon Weight. If Galahad strips naked and types 'skills he sees: ... You can handle 10 weapon improvements. You worship Lythander. Your equipped item power is 0 out of 25 If he then tried to equip the enhanced Bonecrusher he sees: That weapon is too powerful for you to use. It would consume your soul!. By my calculations he *should* be able to equip that weapon. Someone who can understand the code please take a look at it and tell me what I did wrong, if anything. Or see if the code is borked and repair it in CVS (I don't yet have the C skill for this). TIA, Gene (aka poof|Galahad, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 17:55:35 up 52 days, 11:51, 11 users, load average: 0.00, 0.00, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Apr 20 18:27:45 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] Player enhanced weapon problem? In-Reply-To: <200404201813.14851.eracclists@bellsouth.net> References: <200404201813.14851.eracclists@bellsouth.net> Message-ID: Further information on the Bonecrusher in question: arch bonecrusher name Galahad's Bonecrusher name_pl Galahad's Bonecrusher slaying skeleton skill two handed weapons face bonecrush.111 Str 3 Dex 2 Con 1 dam 50 x 6 y 6 level 10 type 15 attacktype 1 material 64 materialname granite value 70000 weight 96000 magic 4 last_sp 15 last_eat 9 weapontype 7 client_type 100 item_power 13 identified 1 been_applied 1 body_arm -2 end On Tue, 20 Apr 2004, ERACC wrote: > That is Galahad's Bonecrusher +4 (Str+3)(Dex+2)(Con+1)(dam+50) > (improved 9/10)(item_power +13)(weapon speed 13)(slay skeleton) > (Attacks: physical) > It is made of: granite. > It goes on your arm (2) > It weighs 96.000 kg. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Tue Apr 20 19:12:09 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] map/image layers In-Reply-To: References: Message-ID: <200404202012.09812.aashenfe@plaind.com> Just some thoughts on this. Maybe the easiest way would be to put objects in discreate viewing layers based on archetype. For instance, the layers would be layed out as follows from top to bottom. 9. Overhead items --------(Forest Canopy, roofs,clouds, etc) 8. In front -------(Tall Walls Tops, Tall Mob Tops, Tall anything tops as described by Todd Mitchell) 7. Spell Affects 6. Missils. 5. Players/Monsters ----- ( Normal/low parts of mobs/players) 4. Items. 3. Furniture 2. Walls/doors 1. Floors 0. Things that should never be seen. Each layer holds multiple item, so items will never stack up into a higher layer. Also these layers are for viewing only, and don't affect the actual stacking order of the square. This might cause some maps to be broken visualy. Map designers would be able to override the visual layering by setting a view-axis location parameter to fix broken maps. Plus extra layers can be used for future features: Flying creatures, hiding (Under furniture), etc Just some ideas Adam Ashenfelter On Mon April 19 2004 10:54 am, Todd Mitchell wrote: > I am not sure about a height value per se, but I did have a wish that we > could do some sort of trickery with the y axis of the map and the graphic > sizes so that objects and creatures would be obscured by the portion of an > object that projects into the tile above. This means that an object moving > into the tile above an objects 'footprint' would be obscured. Something > like: > > _______________________________________________ > 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 Apr 21 01:39:38 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] Player enhanced weapon problem? In-Reply-To: <200404201813.14851.eracclists@bellsouth.net> References: <200404201813.14851.eracclists@bellsouth.net> Message-ID: <4086172A.5010401@sonic.net> ERACC wrote: > Greetings developers, > > On crossfire.metalforge.net I have created a new character, Galahad. > He is Human/Paladin/Lythander. He is now level 18 in "two handed > weapon" skill. He is supposed to be able to "...handle 10 weapon > improvements." I'll fix this up. The code that reports the number of enchanchments is correct - the code that is checking/enforcing that is broken, in that it is still going to the skills to find out how many is allowed. It really shouldn't - it should just be the overall level / 5 + 5 logic. _______________________________________________ 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 Apr 21 08:48:23 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] Hunting hardcoded values Message-ID: <40867BA7.50505@laposte.net> Hello. On IRC someone asked how to change max enchantment for armors. Checking the code, that's a hardcoded value, which is imo a Bad Thing (tm). I'll make a setting for that, just wondering which file would be the best? Probably 'settings'? Or maybe make a file like 'items_settings' for this kind of things, and let 'settings' be a more general file? 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 Wed Apr 21 10:58:18 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] Re: Possible item price bug In-Reply-To: References: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> Message-ID: <20040421155818.GA32337@idefix2.dvlp.in-medias-res.com> Bernd Edler wrote: [...] > One can define PRICE_LIMIT here or even in the config.h if desired. I considered this (to define a constant for the limit) but did not introduce it because it would add complexity through another configurable parameter. On the other hand, having a configurable parameter may prevent a future bug when someone changes the limit again. > These functions are not only continuous but even more important here, > monotonic increasing. They are also differentiable, meaning they bend > away smoothly from the linear function. I have seen this "problem" (the existing function is monotonic increasing but not differentiable) but dismissed it because I considered it as not relevant (and did not find a simple new function): While playing, you can easily compare (absolute) item prices and notice that you will get more for more expensive items. But normally you do not compare the differential prices. I have another concern about the new function: The price adjustment should tone down expensive items to limit the money one can get by selling items. The existing function is very "aggressive" in this regard but the new function gives much more money (see functions titled "new function (limit ...)") in attached image). To sum up, even if I prefer a differentiable function, I would keep the existing function because it has no "practical" problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: adjusted_price_new.png Type: image/png Size: 6441 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20040421/5082b48e/adjusted_price_new.png -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Apr 21 11:34:05 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] Hunting hardcoded values In-Reply-To: <40867BA7.50505@laposte.net> References: <40867BA7.50505@laposte.net> Message-ID: I believe the hardcoded value for Enchant Armour is intential, as described in these threads: http://archives.real-time.com/pipermail/crossfire-devel/2001-May/001984.html http://archives.real-time.com/pipermail/crossfire-devel/2002-June/003190.html Players were able to obtain Armour of 99 and AC's of -40some with relative ease under the older system. Monsters with physical attack (only) wouldn't stand a chance against these players (and that's probably why so many monsters still have physical + some other attack type). On Wed, 21 Apr 2004, Nicolas Weeger wrote: > > On IRC someone asked how to change max enchantment for armors. Checking > the code, that's a hardcoded value, which is imo a Bad Thing (tm). > _______________________________________________ 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 Apr 21 14:24:37 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] Player enhanced weapon problem? In-Reply-To: <4086172A.5010401@sonic.net> References: <200404201813.14851.eracclists@bellsouth.net> <4086172A.5010401@sonic.net> Message-ID: <200404211424.37865.eracclists@bellsouth.net> On Wednesday 21 April 2004 01:39 Mark Wedel wrote: > ERACC wrote: > > Greetings developers, > > > > On crossfire.metalforge.net I have created a new character, > > Galahad. He is Human/Paladin/Lythander. He is now level 18 in > > "two handed weapon" skill. He is supposed to be able to > > "...handle 10 weapon improvements." > > I'll fix this up. [...] Thank you! Gene (aka poof|Galahad, aka eracc) -- Linux era4.eracc.UUCP 2.4.22-28mdkenterprise i686 14:23:34 up 53 days, 8:19, 11 users, load average: 0.07, 0.04, 0.01 ERA Computer Consulting - http://www.eracc.com/ eCS, OS/2, Mandrake GNU/Linux, OpenServer & UnixWare resellers _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Apr 21 18:23:33 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:25 2005 Subject: [CF-Devel] Re: Possible item price bug In-Reply-To: <20040421155818.GA32337@idefix2.dvlp.in-medias-res.com> References: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> <20040421155818.GA32337@idefix2.dvlp.in-medias-res.com> Message-ID: <1082589813.8843.22.camel@oberon.kameria> > I have another concern about the new function: The price adjustment > should tone down expensive items to limit the money one can get by > selling items. The existing function is very "aggressive" in this regard > but the new function gives much more money (see functions titled "new > function (limit ...)") in attached image). > Using value alone to determine selling price is not necessarily good as it makes it harder to charge more and pay less which would improve the economy. On the other hand value is a big part of a dynamic accounting system which would be hard to replace. One thing that was brought up in the past was some sort of store modifier that would limit or otherwise impact the amount given for sold items in conjunction with the item value. If I recall, thoughts that have been brought up were along the lines of: -store 'level' - where the higher level stores (floors actually) can pay more for higher value items much like they produce higher value items, -citizen ship - where players can accquire/purchase a citezship and will get a price penalty when dealing with stores not affiliated with their home city/area, -special shops - or converters actually which give more for high value items allowing shops in general to give less, - an modifier system which could be set by either ingame or configuration files. Maybe even something that adjusts by game calendar or with a dm command. Me I like the idea of handing out / selling citizenship to places (using the arches and player inventory naturally) there are other fun things that could later be tied off this - especially NPC stuff. Maybe we could even do a combination of some of the above. _______________________________________________ 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 Apr 22 00:07:43 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] Re: Possible item price bug In-Reply-To: <1082589813.8843.22.camel@oberon.kameria> References: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> <20040421155818.GA32337@idefix2.dvlp.in-medias-res.com> <1082589813.8843.22.camel@oberon.kameria> Message-ID: <4087531F.80108@sonic.net> Todd Mitchell wrote: >>I have another concern about the new function: The price adjustment >>should tone down expensive items to limit the money one can get by >>selling items. The existing function is very "aggressive" in this regard >>but the new function gives much more money (see functions titled "new >>function (limit ...)") in attached image). >> > > > Using value alone to determine selling price is not necessarily good as > it makes it harder to charge more and pay less which would improve the > economy. On the other hand value is a big part of a dynamic accounting > system which would be hard to replace. Note that the price cap, and curve, only comes in to play when selling items. This has been in the code a long time - basically, it means you can't get 50,000 pp for something, but something could still easily cost that much. Now if you buy such an item, you get a major drop in resale price, but probably not a big deal. > One thing that was brought up in the past was some sort of store > modifier that would limit or otherwise impact the amount given for sold > items in conjunction with the item value. If I recall, thoughts that > have been brought up were along the lines of: > -store 'level' - where the higher level stores (floors actually) can pay > more for higher value items much like they produce higher value items, > > -citizen ship - where players can accquire/purchase a citezship and > will get a price penalty when dealing with stores not affiliated with > their home city/area, > > -special shops - or converters actually which give more for high value > items allowing shops in general to give less, > > - an modifier system which could be set by either ingame or > configuration files. Maybe even something that adjusts by game calendar > or with a dm command. All those are good ideas, but I think go beyond the question at hand - how much should one get for really expensive item - how much does it increase for really expensive items. _______________________________________________ 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 Apr 22 00:15:50 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] Re: Possible item price bug In-Reply-To: <20040421155818.GA32337@idefix2.dvlp.in-medias-res.com> References: <20040415192832.GA27496@idefix2.dvlp.in-medias-res.com> <20040421155818.GA32337@idefix2.dvlp.in-medias-res.com> Message-ID: <40875506.60108@sonic.net> Andreas Kirschbaum wrote: > Bernd Edler wrote: > [...] > >>One can define PRICE_LIMIT here or even in the config.h if desired. > > > I considered this (to define a constant for the limit) but did not > introduce it because it would add complexity through another > configurable parameter. On the other hand, having a configurable > parameter may prevent a future bug when someone changes the limit again. Well, at least having a #define at the top of shop.c isn't a bad idea instead of it just being harcoded in the code itself. > I have another concern about the new function: The price adjustment > should tone down expensive items to limit the money one can get by > selling items. The existing function is very "aggressive" in this regard > but the new function gives much more money (see functions titled "new > function (limit ...)") in attached image). Looking at the graph you provided, I share that concern - the price doesn't seem to decrease all that much. The real idea of the function was to limit money players would get for really expensive items that a are periodically generated - sometimes, combination of abilities is created that result in incredibly value items (hundreds of thousands of platinum). If the current function doesn't do that, that should get fixed up. _______________________________________________ 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 Apr 22 00:18:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] Hunting hardcoded values In-Reply-To: References: <40867BA7.50505@laposte.net> Message-ID: <408755A6.8050108@sonic.net> Rick Tanner wrote: > I believe the hardcoded value for Enchant Armour is intential, as > described in these threads: > > http://archives.real-time.com/pipermail/crossfire-devel/2001-May/001984.html > http://archives.real-time.com/pipermail/crossfire-devel/2002-June/003190.html > > Players were able to obtain Armour of 99 and AC's of -40some with relative > ease under the older system. Monsters with physical attack (only) > wouldn't stand a chance against these players (and that's probably why so > many monsters still have physical + some other attack type). Well, I would suggest changing the default values. But if we want to make it so that it is easier for server admins to change, no big objection on that. The correct place for any configuration stuff is really the settings file. I think having multiple configuration files is a bad idea - it just creates more confusion. If the current settings files gets so large it becomes unmanagagble, I think at that time, we'd have to look at all the settings we allow, and clean some of them up. I also think that if the item_power code is used/enforced (and the enchant item does increase it), removing the cap probably isn't as much a problem - a player might be able to make a -40 ac with 99 armor, but if they can't use it, not that big a deal. _______________________________________________ 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 Apr 23 07:21:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] Suspicious code in server/skills.c Message-ID: <20040423122135.GA7717@idefix2.dvlp.in-medias-res.com> In server/skills.c is a suspicious calculation: throw_ob->stats.wc = 25-dex_bonus[op->stats.Dex?dex_bonus[op->stats.Dex]:0]-thaco_bonus[eff_str]-skill->level; Essentially it calculates: dex_bonus[dex_bonus[Dex]] This can't be correct because 1. dex_bonus[] contains some negative values so it may access dex_bonus[-1] 2. dex_bonus[1] == -3 so "Dex ? dex_bonus[Dex] : 0" is not a sensible (monotonic increasing) function 3. dex_bonus maps "Dex" into "Wc" so "dex_bonus[Wc]" is incorrect A possible solution could be throw_ob->stats.wc = 25-dex_bonus[op->stats.Dex]-thaco_bonus[eff_str]-skill->level; Is this the intended behavior? _______________________________________________ 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 Apr 17 12:36:01 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] server 1.6.0? In-Reply-To: <4067CDE5.50204@sonic.net> References: <200403261923.55166.d.delbecq@laposte.net> <1080345148.665.29.camel@oberon.kameria> <4067CDE5.50204@sonic.net> Message-ID: <20040418033601.44a48d78.won_fang@yahoo.com.au> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Apr 25 01:18:56 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] Suspicious code in server/skills.c In-Reply-To: <20040423122135.GA7717@idefix2.dvlp.in-medias-res.com> References: <20040423122135.GA7717@idefix2.dvlp.in-medias-res.com> Message-ID: <408B5850.4060208@sonic.net> Andreas Kirschbaum wrote: > In server/skills.c is a suspicious calculation: > > throw_ob->stats.wc = 25-dex_bonus[op->stats.Dex?dex_bonus[op->stats.Dex]:0]-thaco_bonus[eff_str]-skill->level; > > Essentially it calculates: > > dex_bonus[dex_bonus[Dex]] > > This can't be correct because > > 1. dex_bonus[] contains some negative values so it may access > dex_bonus[-1] > > 2. dex_bonus[1] == -3 so "Dex ? dex_bonus[Dex] : 0" is not a > sensible (monotonic increasing) function > > 3. dex_bonus maps "Dex" into "Wc" so "dex_bonus[Wc]" is incorrect > > > A possible solution could be > > throw_ob->stats.wc = 25-dex_bonus[op->stats.Dex]-thaco_bonus[eff_str]-skill->level; > > Is this the intended behavior? I've made the change you suggested - I think that is the proper behaviour - I'm not sure what the intention of the original code was. Often times, there will be syntax like op->stats.dex?op->stats.dex:1, but the above mentioned code wasn't doing that. And the 0 values for are the stat bonus arrays is properly intialized, so no harm using a 0 stat of dex. _______________________________________________ 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 Apr 25 02:23:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] server 1.6.0? In-Reply-To: <20040418033601.44a48d78.won_fang@yahoo.com.au> References: <200403261923.55166.d.delbecq@laposte.net> <1080345148.665.29.camel@oberon.kameria> <4067CDE5.50204@sonic.net> <20040418033601.44a48d78.won_fang@yahoo.com.au> Message-ID: <408B678A.2040604@sonic.net> David Seikel wrote: > > During my big bug fixing effort at the beginning of the year, I closed a > large number of the sourceforge listed bugs. Would that have qualified as a > relatively low bug count? A lot depends on the nature of the bugs. For example, some number of bugs may be nuisances or odd behaviours, but don't really break anything - while not ideal to have those, a large number of those isn't that big a deal. OTOH, some bugs may be very rare/esoteric, but cause potentially major problems (abuse of some form) - if players are aware of them, those are major bugs, and a relatively low number is desired for those. The best indicator I use is the crash frequency of crossfire.metalforge.net - if crash frequency is a couple times a week, I find that acceptable. OTOH, a last minute bug can get reported to make life confusing. > > I would like to see more docs about the new skill/spell system before it hits > the streets. Mostly coz I don't grok it yet. Can you pose specific questions? the skills and spells files in the doc/Developer directory should explain most all the fields in the relevant object, as well as background. So without some specific areas that need better documentation, hard for me to help out. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Sun Apr 25 17:04:59 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] Client & maps release Message-ID: <408C360B.9000903@laposte.net> In case some people missed it :) Official Crossfire client 1.7.0 was released (Linux a few weeks ago, Windows today), with bugfixes & such. Bigworld maps have been released, version 1.6.0. 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 Apr 25 09:33:36 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <40835572.1050309@sonic.net> References: <20040417224215.4910c257.kstenger@montevideo.com.uy> <40821D46.6070507@sonic.net> <20040418193623.0a426725.kstenger@montevideo.com.uy> <40835572.1050309@sonic.net> Message-ID: <20040425113337.7d0d38b8.kstenger@montevideo.com.uy> > Karla Stenger wrote: > > > just as a matter of comparison, the prayer peace comes to my mind as a spell > > able to do exactly what you say... but my point is that the "real work" of > > the summoner is done while charming a monster, and it would sound fair to me > > that the experience is given by doing that work... and maybe doing so will > > give summoners an easier way to go. right now if you run into a room full of > > monsters those monsters usually have pretty similar protections and spells, > > so waiting for your charmed pets to kill such similar monsters might get you > > a long while. Since your charmed pets can kill other monsters for you after > > charmed i said to give just a part of the xp when the monster is charmed, > > and so you would also like to wait and see if your pet can kill another > > monster and get some more xp. > > > > just my point of view anyway :) > > Ok. It seems that people think that you should get exp. > > So the next question is - does this hold true for all spells that change the > > creatures mood (turn undead, siren call, pacify, conflict, etc), or just charm > monsters in particular? > > And should the player get full monster exp, or just some portion of it? > i have added a poll about this in the forum, thought it would be good, hope it helps :) http://www.metalforge.net/cfmb/viewtopic.php?t=352 -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ 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 Apr 25 11:24:02 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] skill-giving items' names Message-ID: <20040425132402.42972b96.kstenger@montevideo.com.uy> As some players made me notice items like holy symbols and talismans (and probably others of the same kind) do not show anymore their stats in the name nor in their desciption. That is, if a special talisman gives wis+1 or a special attunement it wont be shown in the item itself, even when the item works properly. Any idea on why this is happening? -- +-----------------------------+ | Karla M? Stenger S?bat | | Pando . Canelones . Uruguay | | kstenger@montevideo.com.uy | +-----------------------------+ _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 26 00:07:40 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] skill-giving items' names In-Reply-To: <20040425132402.42972b96.kstenger@montevideo.com.uy> References: <20040425132402.42972b96.kstenger@montevideo.com.uy> Message-ID: <408C991C.9020106@sonic.net> Karla Stenger wrote: > As some players made me notice items like holy symbols and talismans > (and probably others of the same kind) do not show anymore their stats in the > name nor in their desciption. That is, if a special talisman gives wis+1 or a > special attunement it wont be shown in the item itself, even when the item > works properly. > > Any idea on why this is happening? Now fixed. The description code just wasn't handling the skill tool objects. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Mon Apr 26 07:39:35 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] some spells weirdness In-Reply-To: <20040425113337.7d0d38b8.kstenger@montevideo.com.uy> Message-ID: On Sun, 25 Apr 2004, Karla Stenger wrote: > > Karla Stenger wrote: > > > > > just as a matter of comparison, the prayer peace comes to my mind as a spell > > > able to do exactly what you say... but my point is that the "real work" of > > > the summoner is done while charming a monster, and it would sound fair to me > > > that the experience is given by doing that work... and maybe doing so will > > > give summoners an easier way to go. right now if you run into a room full of Summoning is hard to train anyway, and the logic seems correct - you charm the monster = you defeat it. (And it would be a bad propaganda teaching players that violent means are more rewarded than peaceful solutions.) "Peace" spell however assures that noone gets more than 1 xp by _killing_ the peaceful monsters. Getting full xp by changing a mood of a monster could mean infinite source of xp. (The effect of such spells - as far as I know - are not permanent - except charm itself, tho I can bring them to a hostile zone and charm them again.) I suggest each succesfull casting of such a spell should cut in half the _actual_ xp the particular monster can give, and gives the other half to the caster. It may not sound logic when one considers that a once-charmed dragon is just as hard to defeat by _another_ character, I think it's still the best solution. (It's not likely anyway that two players share killing the same monster.) Or maybe the best idea could be that charm gives full xp, other mood-changing spells work as I told above. Xenon > > > monsters those monsters usually have pretty similar protections and spells, > > > so waiting for your charmed pets to kill such similar monsters might get you > > > a long while. Since your charmed pets can kill other monsters for you after > > > charmed i said to give just a part of the xp when the monster is charmed, > > > and so you would also like to wait and see if your pet can kill another > > > monster and get some more xp. > > > > > > just my point of view anyway :) > > > > Ok. It seems that people think that you should get exp. > > > > So the next question is - does this hold true for all spells that change the > > > > creatures mood (turn undead, siren call, pacify, conflict, etc), or just charm > > monsters in particular? > > > > And should the player get full monster exp, or just some portion of it? > > > > i have added a poll about this in the forum, thought it would be good, hope it > helps :) > > http://www.metalforge.net/cfmb/viewtopic.php?t=352 > > -- > +-----------------------------+ > | Karla M? Stenger S?bat | > | Pando . Canelones . Uruguay | > | kstenger@montevideo.com.uy | > +-----------------------------+ > > _______________________________________________ > 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 Apr 27 16:34:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:26 2005 Subject: [CF-Devel] Patch: Win32 fixes Message-ID: <408ED1E3.2010502@laposte.net> Just a small patch for 1.6.0 release, I don't think it changes anything to Linux, but just to be on the safe side, i submit it here :) Just need 3 explicit casts from 'float' to 'unsigned float', because messing uint64 & float isn't great apparently (error message). Since the 3 are in shops or money-related, and the value is a uint64, the cast seems harmless. Nicolas 'Ryo' -------------- next part -------------- Index: server/shop.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/shop.c,v retrieving revision 1.28 diff -u -r1.28 shop.c --- server/shop.c 25 Apr 2004 07:17:40 -0000 1.28 +++ server/shop.c 27 Apr 2004 21:33:13 -0000 @@ -189,9 +189,9 @@ * reflect values (potion charisma list for 1250 gold) */ if(flag==F_BUY) - val=(4.0*(float)val*(1.0+diff)); + val=((unsigned float)4.0*val*(unsigned float)(1.0+diff)); else if (flag==F_SELL) - val=(4.0*(float)val*(1.0-diff)); + val=((unsigned float)4.0*val*(unsigned float)(1.0-diff)); else val *=4; } Index: server/spell_effect.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/spell_effect.c,v retrieving revision 1.117 diff -u -r1.117 spell_effect.c --- server/spell_effect.c 25 Apr 2004 07:17:40 -0000 1.117 +++ server/spell_effect.c 27 Apr 2004 21:33:19 -0000 @@ -1648,7 +1648,7 @@ else if (obj->type==MONEY || obj->type==GEM) value /=3; else - value *= 0.9; + value *= ( unsigned float )0.9f; if ((obj->value>0) && rndm(0, 29)) { int count; -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Apr 28 10:41:26 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:27 2005 Subject: [CF-Devel] Re: Patch: Win32 fixes In-Reply-To: <408ED1E3.2010502@laposte.net> References: <408ED1E3.2010502@laposte.net> Message-ID: <20040428154126.GA14748@idefix2.dvlp.in-medias-res.com> Nicolas Weeger wrote: > Just a small patch for 1.6.0 release, I don't think it changes > anything to Linux, but just to be on the safe side, i submit it here > :) It does not work with Linux and gcc 3.3.2 :-( > Just need 3 explicit casts from 'float' to 'unsigned float', because > messing uint64 & float isn't great apparently (error message). Since > the 3 are in shops or money-related, and the value is a uint64, the > cast seems harmless. The README file states that an "Ansi C compiler" is a requirement to compile the game. Ansi C (C99) does not define the type "unsigned float" but allows casts between "float" and "[unsigned] [long] long". Therefore this *should* work. I think we should use Ansi C constructs in the common (i.e. all non-WIN32) parts to remain portable. Therefore we should not introduce the type "unsigned float" even if we can make it work with gcc. One solution to keep all compilers happy may be to avoid the casts (see attached diff): - Both casts in "shop.c" (explicit cast from "float" to "long" and implicit cast from "long" to "uint64") should cause no problems. (Note: I don't know if the accuracy of three digits is sufficient.) - The calculation in "spell_effect.c" does no type conversion anymore. (Note: I have no WIN32 compiler. Therefore I could not check if it actually works with this compiler.) -------------- next part -------------- Index: server/shop.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/shop.c,v retrieving revision 1.28 diff -u -w -r1.28 shop.c --- server/shop.c 25 Apr 2004 07:17:40 -0000 1.28 +++ server/shop.c 28 Apr 2004 15:11:31 -0000 @@ -189,9 +189,9 @@ * reflect values (potion charisma list for 1250 gold) */ if(flag==F_BUY) - val=(4.0*(float)val*(1.0+diff)); + val=(4*val*(long)(1000*(1+diff)))/1000; else if (flag==F_SELL) - val=(4.0*(float)val*(1.0-diff)); + val=(4*val*(long)(1000*(1-diff)))/1000; else val *=4; } Index: server/spell_effect.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/server/spell_effect.c,v retrieving revision 1.117 diff -u -w -r1.117 spell_effect.c --- server/spell_effect.c 25 Apr 2004 07:17:40 -0000 1.117 +++ server/spell_effect.c 28 Apr 2004 15:11:31 -0000 @@ -1648,7 +1648,7 @@ else if (obj->type==MONEY || obj->type==GEM) value /=3; else - value *= 0.9; + value = (value*9)/10; if ((obj->value>0) && rndm(0, 29)) { int count; -------------- next part -------------- _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel From crossfire-devel at archives.real-time.com Wed Apr 28 14:54:27 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:27 2005 Subject: [CF-Devel] Server 1.6.0 release Message-ID: <40900BF3.7000503@laposte.net> Crossfire server 1.6.0 has been released, with associated archetypes and documentation and whatelse. Server is available for Linux ( http://sourceforge.net/project/showfiles.php?group_id=13833&package_id=15919&release_id=234186 ) and Windows ( http://sourceforge.net/project/showfiles.php?group_id=13833&package_id=99312&release_id=233728 ,self-installer). Archetypes & documentation are in .tar.(gz|bz2), from http://sourceforge.net/project/showfiles.php?group_id=13833 Bug fix list hidden somewhere in changelog :) Or simply http://sourceforge.net/project/shownotes.php?release_id=234186 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 Wed Apr 28 15:36:10 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:27 2005 Subject: [CF-Devel] Sounds, continued Message-ID: <409015BA.1040507@laposte.net> Been thinking again about sounds, here's what I'm gonna do. Put .snd files with archetypes, format: sound goblin_death file goblin_death_1 <- .raw omitted voluntarily volume 'normal' volume text a goblin die <- client could display 'you hear ' endsound .raw files will just stay where they are (in the future maybe client could request a sound, but let's first make the big part, improve sound support :)). Those .snd will get collected by collect.pl, and make a sounds_arch file. This file get parsed by server at startup, assigning a unique identifier to each unique name (thus ignoring duplicate names) and trashing the rest. Add sound lines to archetypes: Object goblin .... sound death goblin_death .... Server at loading links the sound with event ('death', 'apply', ...) and makes sure sound actually is defined. Of course, 'sound' could get 'overriden' in artifacts, like other fields. Maybe simply be an array of values, mapping event => sound number. Now this sounds_arch file is parsed by client too, merging info from the sounds with same name. When server sends a sound, giving identifier and volume, client finds the group of sounds with that name, and uses one randomly. Each sound has its 'nominal' volume, to adjust it correctly. The choice of putting all info (client and server) into .snd is to have only one sounds_arch file shared between client & server. Also, it wouldn't be hard to have a 'sounds_maps' file, with info from special sounds in maps (text to congratulate a player on defeating a big bad boss?), and parse it too at client/server startup. The only link between client & server is the 'sound name'. Server has no idea of different sounds for one event. This could also be used for 'server' events like 'player login/logout', and why not background music (special event 'sound background'?) I'm starting to implement that, but of course if you have better ideas just fork'em :) 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 Wed Apr 28 16:57:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:27 2005 Subject: [CF-Devel] Re: Patch: Win32 fixes In-Reply-To: <20040428154126.GA14748@idefix2.dvlp.in-medias-res.com> References: <408ED1E3.2010502@laposte.net> <20040428154126.GA14748@idefix2.dvlp.in-medias-res.com> Message-ID: <409028DB.6020409@laposte.net> > It does not work with Linux and gcc 3.3.2 :-( Actually, just saw that Windows complains, too (but will compile nontheless). Guess your patch will do it :) 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 Wed Apr 28 22:10:59 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:27 2005 Subject: [CF-Devel] skill tools Message-ID: <40907243.4060805@earthlink.net> I just downloaded the latest server code from the CVS repository, and I believe I've found the bug which prevents the descriptions of skill items like the 'talisman of missiles'. However I don't have the tools to test the fix myself, so I don't dare make the changes. In the file crossfire/common/item.c (CVS version 1.43): Change every instance of : SKILL to: SKILL_TOOL except in the functions: describe_monster need_identify and remove lines 837-838 The needed changes are on lines: 340, 363, 415, 531, 613, 837, 838, 868, 911 I apologize for not providing a diff. I'm stuck on a windows box until I can raise the money to fix my linux box.. Neil Reynolds _______________________________________________ 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 Apr 29 02:08:54 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:27 2005 Subject: [CF-Devel] skill tools In-Reply-To: <40907243.4060805@earthlink.net> References: <40907243.4060805@earthlink.net> Message-ID: <4090AA06.1000702@laposte.net> > I apologize for not providing a diff. I'm stuck on a windows box until I > can raise the money to fix my linux box.. Hey, you *can* do diffs under Windows! :) I'm using it, and happily developing for CF. > Neil Reynolds 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 Thu Apr 29 02:27:47 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:28 2005 Subject: [CF-Devel] Sounds, continued In-Reply-To: <409015BA.1040507@laposte.net> References: <409015BA.1040507@laposte.net> Message-ID: <4090AE73.7000307@sonic.net> Nicolas Weeger wrote: > Been thinking again about sounds, here's what I'm gonna do. > > Put .snd files with archetypes, format: > sound goblin_death > file goblin_death_1 <- .raw omitted voluntarily > volume 'normal' volume > text a goblin die <- client could display 'you hear ' > > endsound Looks good. I'd document that you probably want to have more generic names, unless there are going to be that many sound files (eg, should you use goblin_death with orcs? It would seem confusing if you do) > > .raw files will just stay where they are (in the future maybe client > could request a sound, but let's first make the big part, improve sound > support :)). The sound files should really get moved into the client CVS area, vs being their own checkout, but thats not a major deal. > > Those .snd will get collected by collect.pl, and make a sounds_arch file. > This file get parsed by server at startup, assigning a unique identifier > to each unique name (thus ignoring duplicate names) and trashing the rest. In practice, the collect should deal with removing duplicate names, like it does faces, and complain if two different files use the same sound name but are different. Otherwise, I'm sure someone will run into the case of adding a new sound and it not working as expected, because he chose a duplicate name of another sound. > > Add sound lines to archetypes: > Object goblin > .... > sound death goblin_death > .... > > Server at loading links the sound with event ('death', 'apply', ...) and > makes sure sound actually is defined. > Of course, 'sound' could get 'overriden' in artifacts, like other fields. > Maybe simply be an array of values, mapping event => sound number. I'm not sure what you mean by that last sentence of event->sound number. Pretty much it is almost aways better to use english/words in the files than just numbers. I'd also note that you should be able to define more than one sound element to an event, eg, something like: sound death goblin_death1 ... sound death goblin_death2 ... sound death goblin_death3 ... > > Now this sounds_arch file is parsed by client too, merging info from the > sounds with same name. > > When server sends a sound, giving identifier and volume, client finds > the group of sounds with that name, and uses one randomly. Each sound > has its 'nominal' volume, to adjust it correctly. I take it this is to cover the case above - you might have three different goblin_death definitions? I'm not sure I like it - it means it that it is more likely that you'll need to set up more sound info lists for objects. Eg, lets say the goblin does have 3 death sounds. Lets say that I want to use one and only one of those for the orc, plus a couple others that may get shared (maybe one from the ogre also or something). this may mean that the number of .snd files could easily be many times the actual number of sounds. It also means it is harder to use already defined sound files for map customizations. But the other case is this oddity - since the client would choose which sound to play, if there are multiple sounds associated, two players on the same map could get different sounds even though they are hearing the same event. This would seem particularly odd if those two players are in the same physical room, and thus hear the sound from the others computer. I think it'd make more sense for the server to choose the sound to play, so that everyone gets the same sound. If you do that, it also means that as part of the optional parameters for the sounds, you could have different weightings. Eg, something like: soundinfo death goblin_death1 30 death goblin_death2 10 death goblin_death3 40 endsoundinfo Thus, goblin_death2 is played only 10% of the time, compared to 30 and 40 for the other ones (and perhaps if the totals are less than 100, then have that remainder 20% have nothing played? EG, I could certainly see cases where you want the sound played some of the time, but not all the time the event happens. I also changed the way the sound events are listed - put it in a soundinfo/endsoundinfo block - I think this would make it easier on the editor - I'm not sure how the editor deals with fields that start with the same apparant name - it might strip some of those out. > > > The choice of putting all info (client and server) into .snd is to have > only one sounds_arch file shared between client & server. seems reasonable. > > Also, it wouldn't be hard to have a 'sounds_maps' file, with info from > special sounds in maps (text to congratulate a player on defeating a big > bad boss?), and parse it too at client/server startup. The problem here is that at startup, the server needs to know it has has that sound it needs to associate. I personally don't think there is any need for this - to add a congratulate player event, you're going to have to add the sound to the list of available sounds, and if you've already done that, making up a .snd file should be trivial. > > The only link between client & server is the 'sound name'. Server has no > idea of different sounds for one event. Which as said above, I don't quite think is correct, as it would mean different players would here different sounds even though they should here the same thing. And I think at some point, it'll be found that the server will want to customize the sound based on other events. For example, right now, when you hit something when attacking, different sound it played based on the amount of damage - I'd probably say you don't want to have 5-6 different hit sound lists - rather, it'd be nice to have just one 'hit' event, and through some mechanism, the server can choose which one to play based on damage. > > This could also be used for 'server' events like 'player login/logout', > and why not background music (special event 'sound background'?) Certainly a list of sound events that the server players, or perhaps have event_type tag in the the sound information itself. Thus, you could hve something like: #define SOUND_PLAYER_LOGIN 1 #define SOUND_PLAYER LOGOUT 2 #define SOUND_PLAYER_DIE 3 ... and then sound player_die type 3 .... endsound (player die could be used for something else). But I'd rather have some form of mapping like that, vs the code specially looking for sounds by name. Although, I suppose you could do something like: #define SOUND_PLAYER_DIE "player_die" or whatever. _______________________________________________ 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 Apr 29 02:30:30 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:28 2005 Subject: [CF-Devel] skill tools In-Reply-To: <40907243.4060805@earthlink.net> References: <40907243.4060805@earthlink.net> Message-ID: <4090AF16.6070108@sonic.net> Neil Reynolds wrote: > I just downloaded the latest server code from the CVS repository, and I > believe I've found the bug which prevents the descriptions of skill > items like the 'talisman of missiles'. Well, I made a patch for this a couple days ago which seemed to fix things up - at least after I made the change, it was properly showing the Wis +1 or the like for skill tools. So I'm not sure if this is still a bug. _______________________________________________ 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 Apr 29 02:58:53 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:28 2005 Subject: [CF-Devel] Sounds, continued In-Reply-To: <4090AE73.7000307@sonic.net> References: <409015BA.1040507@laposte.net> <4090AE73.7000307@sonic.net> Message-ID: <4090B5BD.6060303@laposte.net> Mark Wedel wrote: > Looks good. > > I'd document that you probably want to have more generic names, unless > there are going to be that many sound files (eg, should you use > goblin_death with orcs? It would seem confusing if you do) The idea is to let people make as many sounds as they want. IE if i want to use 'small_monster_death' as sound for all monsters, i can. But fi i want a sound per race, i can too :) > The sound files should really get moved into the client CVS area, vs > being their own checkout, but thats not a major deal. yep & yep. > In practice, the collect should deal with removing duplicate names, > like it does faces, and complain if two different files use the same > sound name but are different. Otherwise, I'm sure someone will run into > the case of adding a new sound and it not working as expected, because > he chose a duplicate name of another sound. Hum, that's what i was using names like goblin_death <- to avoid confusing with orc_death sound, for instance. > I'm not sure what you mean by that last sentence of event->sound > number. Pretty much it is almost aways better to use english/words in > the files than just numbers. I meant, if there are 10 sound event types, objects have a int sound_event[ 10 ] field. So just map event to sound number. > I'd also note that you should be able to define more than one sound > element to an event, eg, something like: My proposal is to do that on the client - let the client handle the different sound possibilities. > I take it this is to cover the case above - you might have three > different goblin_death definitions? Yes, sorry if i wasn't clear enough. > I'm not sure I like it - it means it that it is more likely that you'll > need to set up more sound info lists for objects. Eg, lets say the > goblin does have 3 death sounds. Lets say that I want to use one and > only one of those for the orc, plus a couple others that may get shared > (maybe one from the ogre also or something). this may mean that the > number of .snd files could easily be many times the actual number of > sounds. It also means it is harder to use already defined sound files > for map customizations. Well, make one .snd file with 3 'sound goblin_death' blocks. Server picks the first one only, client will ready 3. But yes, if you want to use one for both orc & goblin, you'll need to add 'sound orc_death' somewhere. > But the other case is this oddity - since the client would choose which > sound to play, if there are multiple sounds associated, two players on > the same map could get different sounds even though they are hearing the > same event. This would seem particularly odd if those two players are > in the same physical room, and thus hear the sound from the others > computer. I think it'd make more sense for the server to choose the > sound to play, so that everyone gets the same sound. Hum, got a point there. My idea for multiple sounds was to let client handle all that. Server just sends a sound name, client takes care of the case when multiple sounds match and plays one randomly. This also lets easily a player customize a sound - tweak .snd file to add or remove customized sounds, without needing server access. > If you do that, it also means that as part of the optional parameters > for the sounds, you could have different weightings. Eg, something like: > Thus, goblin_death2 is played only 10% of the time, compared to 30 and > 40 for the other ones (and perhaps if the totals are less than 100, then > have that remainder 20% have nothing played? EG, I could certainly see > cases where you want the sound played some of the time, but not all the > time the event happens. Could be done adding a 'weight' line to .snd - again, client would take care of those weights. > I also changed the way the sound events are listed - put it in a > soundinfo/endsoundinfo block - I think this would make it easier on the > editor - I'm not sure how the editor deals with fields that start with > the same apparant name - it might strip some of those out. Since my proposal was just to add 'sound xxx' to archetypes, editor would (unless i'm wrong) handle that just right. Your block idea is nice too, though. > The problem here is that at startup, the server needs to know it has > has that sound it needs to associate. That's why server could read two files: sound_arch & sound_maps. > I personally don't think there is any need for this - to add a > congratulate player event, you're going to have to add the sound to the > list of available sounds, and if you've already done that, making up a > .snd file should be trivial. Right, but then you'd need to actually tweak archetypes, rebuilt files and so on just to add your sound. If with a 'sound_maps', your don't need archetypes - just maps. (and in both cases, for now, player needs to manually download sound files) > Which as said above, I don't quite think is correct, as it would mean > different players would here different sounds even though they should > here the same thing. And I think at some point, it'll be found that the > server will want to customize the sound based on other events. > > > For example, right now, when you hit something when attacking, > different sound it played based on the amount of damage - I'd probably > say you don't want to have 5-6 different hit sound lists - rather, it'd > be nice to have just one 'hit' event, and through some mechanism, the > server can choose which one to play based on damage. Could be nice, indeed. Gah this is starting to get complicated :) > Certainly a list of sound events that the server players, or perhaps > have event_type tag in the the sound information itself. Thus, you > could hve something like: I was more thinking of something like: #define SOUND_EVENT_LOGIN "player_login" #define SOUND_EVENT_LOGOUT "player_logout" <- sound names but #define SOUND_EVENT_CAST_SPELL 1 #define SOUND_EVENT_APPLY 2 <- number used on 'sound xxx' lines in archetypes ... but yes, maybe wouldn't be that nice... I think basically we both have our ideas about sounds, and they both have advantages & disadvantages :) 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 Apr 30 01:54:22 2004 From: crossfire-devel at archives.real-time.com (crossfire-devel@archives.real-time.com) Date: Thu Jan 13 17:56:28 2005 Subject: [CF-Devel] Sounds, continued In-Reply-To: <4090B5BD.6060303@laposte.net> References: <409015BA.1040507@laposte.net> <4090AE73.7000307@sonic.net> <4090B5BD.6060303@laposte.net> Message-ID: <4091F81E.60709@sonic.net> Nicolas Weeger wrote: > > > Hum, that's what i was using names like goblin_death <- to avoid > confusing with orc_death sound, for instance. But you could have a case for example like 'apply_armor' or something, which could be abit confusing. Also be aware that the more sound definitions you have, the larger the sounds file, which then means more time it takes for the client to download it. So ideally you want some level or commonality for the sounds, so that each archetype doesn't need its own sound definition. > > I meant, if there are 10 sound event types, objects have a int > sound_event[ 10 ] field. So just map event to sound number. Don't want to do that - it doesn't scale very well. Suppose there are 30 distinct sound events. If you say each soudn event is 10 bytes (pointer to the sound, pointer to optional parameters, and perhaps a couple bytes for volume), that starts to really add up in the space. Especially since in probably 99% of the cases, an archetype will have at most a couple sounds - most in fact probably won't have any sounds. Your much better off using a linked list, like the python events. If performance is an issue, you could have a bitmasks which denotes which events are actually being set, eg, if (op->sound_event & (1< > Well, make one .snd file with 3 'sound goblin_death' blocks. Server > picks the first one only, client will ready 3. > But yes, if you want to use one for both orc & goblin, you'll need to > add 'sound orc_death' somewhere. Well, I don't like the idea of three pieces of data having the same name - I think that just opens things up to confusion. And logically, the code someplace is going to have to collapse those into the same data area (eg, the client sees three different ones, and has to know to associated them with each other). So if that's the case, it probably makes more sense to collapse all the sound info into one area, eg: sound goblin_death file goblin_death1 20 file generic_death 10 file goblin_death2 20 text die's a horrible death endsound That is probably easier to parse on the client. Means you no longer have duplicate names, or if there are, it is a real error. It also is likely to make it easier on the developers - don't have to worry about hunting down all the possible 'goblin_death' sounds in the arch tree either. I'd note that for all purposes, the server cares less about the data between the sound and endsound line - it's only the client that uses it. But I'd personally think the above syntax is easier to process for the client - it gets all the information related to a sound in one block, and doesn't have to hunt its data for other info, make linked lists, whatever else. > Hum, got a point there. > My idea for multiple sounds was to let client handle all that. Server > just sends a sound name, client takes care of the case when multiple > sounds match and plays one randomly. > This also lets easily a player customize a sound - tweak .snd file to > add or remove customized sounds, without needing server access. True, but how is the soundinfo file getting downloaded? You'd need to add some logic like a sounds directory private to the player that means it always uses the sound definition in that file vs the one the server tells the client about. I'd also think the above syntax would be clearer for that. EG, if I know I want to change the goblin_death sound, I just need that one entry - I don't have to hunt them all down, figure out which ones I want, and don't have worry about weird issues of how to deal with multiple entries. > > > Since my proposal was just to add 'sound xxx' to archetypes, editor > would (unless i'm wrong) handle that just right. > Your block idea is nice too, though. I'm pretty sure the editor considers each settable variable as something with a space. So I'm not sure if it saw something like: sound death ... sound death ... If it wouldn't collapse those into one thing or not. > > Right, but then you'd need to actually tweak archetypes, rebuilt files > and so on just to add your sound. If with a 'sound_maps', your don't > need archetypes - just maps. > (and in both cases, for now, player needs to manually download sound files) No you don't. If there is a sound_maps, you could do something like 'cat sound_maps >> sounds' or whatever - there is no requirement to do a full rebuild to add a sound event - you could just modify the file directly. OTOH, you may really want to do something like the the treasures file - there is a basic version in lib, and the collect process collects the ones it finds and basically makes a treasures.bld - takes the lib/treasures and adds on all the ones it finds in the collect process. Such a format is probably useful for those cases where there really isn't any good location within the arch directory for a sound (system sounds for example). > > I was more thinking of something like: > #define SOUND_EVENT_LOGIN "player_login" > #define SOUND_EVENT_LOGOUT "player_logout" <- sound names > > but > > #define SOUND_EVENT_CAST_SPELL 1 > #define SOUND_EVENT_APPLY 2 <- number used on 'sound xxx' lines in > archetypes > ... > > but yes, maybe wouldn't be that nice... > > I think basically we both have our ideas about sounds, and they both > have advantages & disadvantages :) Using text is probably fine. Perhaps the advantage of having numbers is you could fill the table at initial load (eg, system_sounds[]) and thus save time in the future (play_sound(system_sound[SOUND_EVENT_DIE])) or the like, where as if it is text, there isn't any quite as efficient startup mechanism (you could store the text strings in an array, and associate the sound info with it, and then when it comes time to play a sound, it only has to look through that more limited array vs all the sounds). OTOH, for most of those 'global' event sounds, probably not played so often that efficiency is that important anyways. _______________________________________________ crossfire-devel mailing list crossfire-devel@lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel